Talking tech with non-technical stakeholders in practice

Talking tech with non-technical stakeholders

You've built something solid. The architecture is clean, the deployment pipeline is automated, and you've squashed three bugs before breakfast. Then a stakeholder asks you to explain why the feature is taking "so long," and suddenly you're drowning in jargon while they're checking their phone. Talking tech with non-technical stakeholders is a leadership skill nobody puts in the job description—yet it's one of the highest-leverage abilities you can develop as an engineer.

I learned this the hard way. Early in my career, I'd spent weeks optimizing a database query, reducing response times from 2 seconds to 200ms. I walked into a product meeting expecting applause and got blank stares. Nobody cared about the query optimization; they cared whether customers would see results faster. Once I reframed it in those terms, suddenly the work mattered. That gap between what we build and what anyone else understands is where miscommunication breeds delays, frustration, and poor decisions.

Lead with outcomes — Start with what changes for users or the business

The first instinct when explaining a technical decision is to start with the technical details. Resist it. Your stakeholder's mental model doesn't have a place for "asynchronous processing" or "eventual consistency." What it does have is space for outcomes: faster checkouts, happier customers, lower churn, or lower infrastructure cost.

Let's say you're proposing a caching layer for a ride-hailing platform. A technical explanation might go: "We'll implement Redis with a two-tier cache strategy using write-through invalidation on the service layer." A stakeholder-first explanation sounds like this:

"Right now, when a driver opens the app, it takes three seconds to load their ride history. We lose drivers at that moment—they switch apps and take rides elsewhere. If we add caching, that drops to 500 milliseconds. Our data shows that in our market, every 100ms of latency costs us about 2% of driver retention. Over a year, that's roughly 15 drivers we don't lose per 1,000."

See the difference? One is architecture, the other is business. The second one makes the decision obvious.

Start every proposal with the outcome. Make it specific. "Faster" is vague; "reduces page load from 3s to 500ms" is concrete. "Cheaper" doesn't land; "saves $8,000 per month in database costs" does. If the outcome is risk mitigation, frame it the same way: "This reduces the chance of data loss during a crash from 1 in 500 to 1 in 100,000."

In my experience at a travel platform, when I proposed rebuilding our booking service in NestJS instead of maintaining a aging monolith, I didn't lead with "better separation of concerns." I led with: "This unblocks our ability to scale bookings independently from search. During peak times, search requests currently queue for 40 seconds behind booking writes. This change separates them, reducing user-visible latency by 60%." Suddenly the three-month effort made sense.

Options with prices — Present choices with time, cost and risk for each

Rarely is there only one way to solve a problem. But presenting five equally valid options paralyzes decision-making. Instead, present three: a fast-and-expensive option, a slow-and-cheap option, and a middle-ground option. For each, attach a price: time, money, and risk.

Here's a practical scenario. You're running out of PostgreSQL disk space on your production database. Three paths forward:

Option	Time	Cost	Risk
Option A: Upgrade now Move to larger instance class, expand storage	2 days implementation, 30 min downtime	$2,500/month increase in AWS spend	Low. Proven path. Solves problem for 18 months.
Option B: Archive + compress (middle ground) Move data older than 1 year to cold storage, add compression	3 weeks implementation, zero downtime	$400/month increase (cheaper storage tier)	Medium. Buys us 8 months. Requires querying logic changes for historical data.
Option C: Do nothing yet Wait until we hit 100% capacity	0 weeks now, emergency response later	$0 now, likely $5,000+ emergency cost	Very high. If we hit capacity mid-transaction, database locks and we lose customer data.

Now a non-technical stakeholder can make a real decision. They see trade-offs. They understand that Option B costs money but buys time to plan; Option C saves money today but risks customer trust tomorrow.

Present this format every time you're proposing work that blocks product progress:

• Option A (Fast path): Do it right, takes X weeks, costs Y, risk is Z.
• Option B (Middle path): Do it good-enough, takes X weeks, costs Y, risk is Z.
• Option C (Delay): Defer decision, takes 0 weeks now, consequences are Z.

I learned this at a CRM platform where we needed to migrate email data across regions for compliance. I presented three options: parallel-run new system for safety (8 weeks, expensive), direct migration with rollback plan (4 weeks, medium risk), and staged rollout by customer (6 weeks, lowest risk). The product lead immediately chose staged rollout. It wasn't the fastest, but they understood the risk-reward and owned the decision.

Avoid jargon — 'The system will be unavailable for five minutes' instead of 'a rolling restart'

Jargon is a compression format. To you, "rolling restart" is instantly clear: the infrastructure updates one pod at a time while others stay live, so traffic never stops. To a non-technical person, it's noise. They hear "rolling" and "restart" and wonder if you're gambling with their service.

Translate. Always. Here's a guide:

• "Rolling restart" → "We'll update the system in waves. One small part goes down for 30 seconds, then comes back up. Then the next part. Users won't notice."
• "Database migration" → "We're moving customer data from one storage system to another, like moving houses. It takes X hours and customers can't place orders during that window."
• "Caching layer" → "We're keeping a fast copy of popular data nearby so we don't have to ask the slow storage every time. It's like keeping your most-used tools on your desk instead of in the garage."
• "Graceful degradation" → "If one system fails, we fall back to a simpler version. You'll see fewer features but things still work."
• "Circuit breaker pattern" → "If a system keeps failing, we stop trying to use it for a while and use a backup instead."
• "Data consistency" → "Making sure all copies of the data match so nobody sees outdated information."

The deeper principle: every technical term should have a business or user-visible translation. If you can't translate it, you don't understand it well enough yet.

At a SaaS platform, I had to explain why we couldn't instantly scale our API. Instead of talking about Kubernetes autoscaling and resource contention, I said: "Think of our API like a cashier line. When lots of customers arrive suddenly, we can't instantly hire new cashiers. There's a delay of 30 seconds before new ones are working. During peak traffic, some customers wait in the queue." Suddenly the product manager understood why we pre-warm servers during known busy periods.

Confirm understanding — Ask them to summarize the decision back

You've explained the three options. They nod. You assume they understand. Then three weeks later, they're frustrated because expectations didn't match reality.

Confirm. Ask them to tell you back what they heard.

Simple phrasing: "Just to make sure I explained this clearly, can you walk me through what we're doing and why we chose Option B?"

This isn't condescending. It's professional. Pilots do this before every flight. Surgeons do this before every procedure. It's called a read-back, and it catches misunderstandings before they become expensive mistakes.

I've done this at every company. A product lead once said back: "We're going to upgrade the database and it'll be cheaper." I caught it immediately. "Actually, it'll cost more per month, but it prevents a bigger risk." Without the read-back, they would have approved it thinking it saved money and resented me three months later when the bill arrived.

The read-back also gives you insight into what actually mattered to them. Maybe you emphasized uptime, but they heard "faster features." Now you know to double down on timeline in future conversations.

Common mistakes

Mistake 1: Leading with elegance instead of impact. "This uses the adapter pattern to decouple X from Y" sounds sophisticated. "This means we can swap out the payment provider without breaking bookings" sounds useful. Stakeholders care about the second one.

Mistake 2: Giving false precision on timelines. "This will take 37 days" implies certainty you don't have. "This usually takes 4-6 weeks depending on edge cases we discover" is honest. Estimates are wrong, but ranges are less wrong.

Mistake 3: Not acknowledging the cost of your proposal. If you're asking for three weeks of engineering time, say it: "This costs three weeks we could've spent on feature X." Let them decide if it's worth it. Hidden costs create resentment.

Mistake 4: Assuming non-technical means non-intelligent. Most stakeholders understand trade-offs, priority, and risk. They just don't speak your language. Translate, don't simplify.

Mistake 5: Presenting a decision as already made. "We need to do this" is different from "Here are three ways forward, which appeals to you?" The second one builds buy-in. The first one builds resistance.

Key takeaways

• Start with outcomes, not mechanisms. Lead with what changes for users or the business, not how the system works.
• Always present options with explicit trade-offs: time, cost, and risk for each path. This lets stakeholders make informed decisions rather than guess at your recommendation.
• Translate jargon ruthlessly. If you can't explain it without technical terms, you don't understand it well enough.
• Confirm understanding by asking stakeholders to summarize the decision and reasoning back to you. This catches misalignment before it becomes expensive.
• Acknowledge costs and constraints openly. Hidden costs breed resentment; transparent trade-offs build trust.
• Treat non-technical stakeholders as intelligent people who speak a different language, not as people who are less intelligent.