Communicating Tradeoffs to Non Engineers Without Dumbing Down

TL;DR — Strip jargon, keep the structure. Use analogies that age well. Always present at least two options with honest costs. Let the listener decide, do not decide for them and seek ratification.

The hardest sentence I learned to write in my career is “we have three options, here are the tradeoffs, here is what I recommend, you decide.” It sounds easy. It is not. Engineers default to one of two failure modes when talking to non-engineers. We either drown them in detail until they nod and walk away with the wrong impression, or we oversimplify until we have lied by omission and committed our team to an option that does not actually fit.

The middle path is communication that respects the listener’s intelligence and the technical reality at the same time. It is the version of the skill I have been refining for a decade, and the version that, in late 2024, separates senior engineers who get to influence strategy from senior engineers who get assigned to execute it.

This post is what I have learned. Some of it is uncomfortable for engineers because it asks you to give up control of the decision. That is the point. If the listener cannot make the call, you have not communicated the tradeoff, you have asked for a rubber stamp.

The shape of a useful tradeoff conversation

Every tradeoff conversation worth having has the same three-part shape. You can run it in five minutes or fifty. The structure does not change.

1. Frame: What are we choosing between and why does it matter?
2. Compress: Two or three options, each in one sentence, with honest costs.
3. Recommend: Your pick, and the conditions under which you would change it.

The most common mistake is to spend 80% of the time on part one. The second most common mistake is to skip part three. Both errors hand the listener no decision to make.

Here is a worked example, the kind of thing I might say to a non-technical CEO in late 2024.

“We have to decide where to put the embedding workload for the new search feature. There are three options. We host the model ourselves on GPUs, which gives us full control and costs about $40k a month at projected scale, with a six-week ramp. We use OpenAI’s embedding API, which is $4k a month and ready next week but locks us to their pricing and availability. We use a smaller open model on CPU, which is $2k a month and ships in three weeks but loses about 8% accuracy in our tests. I recommend OpenAI for the launch, and we revisit in Q2 once we see real traffic and can budget the self-hosted option if it makes sense. The condition that would change my mind is if procurement raises a data residency concern this week, in which case we go to self-hosted.”

That is roughly 130 words. It is also a complete decision package. Cost ranges, time ranges, the technical concern named without jargon, a recommendation, and an explicit override condition. The CEO can ask one clarifying question and make the call.

Analogies that hold up under stress

Engineers love clever analogies. Most of them are bad. The test for a useful analogy is whether it survives the follow-up question. “It is like a database” survives. “It is like building a house with Lego bricks” does not, because the moment the listener asks “so why is one brick expensive” the analogy breaks down and the conversation is now about Legos.

Here are the analogies that have aged well in my experience.

Caching is like a sticky note on your monitor. Fast to read, slow to update, and you have to remember to throw it out when the underlying thing changes. Survives questions about TTL (“how long the sticky note is good for”), invalidation (“when you have to remember to update the sticky note”), and cache stampedes (“when everyone tries to read the sticky note at the same time and it falls off”).

A queue is a line at the coffee shop. Throughput is how fast they make coffee. Latency is how long you wait. A growing line means demand exceeds supply. Adding more baristas (consumers) helps, but only up to the size of the counter (backpressure). Survives most questions executives ask about Kafka or SQS.

A database transaction is signing a check. Either it clears entirely or not at all. You cannot half-sign. This is the easiest way to explain ACID to a finance partner who has signed actual checks.

Technical debt is exactly debt. Borrow against future capacity to ship now. Compound interest is real. There is good debt (mortgage, takes you somewhere you could not otherwise reach) and bad debt (credit card, funds something you should have skipped). This analogy is overused but earns its place because finance partners run their day-to-day on it.

The bad analogies, for the record, are anything involving cars, anything involving “magic”, and anything involving “imagine if this was a kitchen.” If you find yourself reaching for those, you are not yet clear on the underlying tradeoff. Step back, write it out in plain text, and try again.

Compress without distorting

The compression step is where most of the lying happens, even unintentionally. Three patterns help.

Ranges, not points. “Between $30k and $50k a month” is more honest than “$40k a month” because it acknowledges uncertainty. Executives are surprisingly comfortable with ranges, more so than engineers expect. They run their forecasts in ranges already.

Conditions, not absolutes. “This option is fastest if traffic stays under 10k requests per second” is more honest than “this option is fastest.” Conditions invite the listener to test the assumption, which is what you want.

Costs in time and money, both. Engineers default to talking about time. Finance defaults to talking about money. Always give both. “Two weeks of one engineer, roughly $20k of loaded cost.” That sentence does more diplomatic work than three paragraphs.

For more on quantifying these costs in a way the business will accept, see Translating Business Impact into Architecture Decisions.

The “what would change your mind” question

The best question a non-engineer can ask an engineer is “what would change your mind?” It forces the engineer to articulate the failure modes of their own recommendation. Most engineers cannot answer it crisply on the first try.

You can preempt the question by always closing your recommendation with a “conditions for revisit” line. Something like:

Recommendation: Option B (managed vector DB).
Conditions that would change this:
- If the security review surfaces a data residency requirement we did not know about.
- If projected query volume exceeds 5M/day, at which point the unit economics shift.
- If we hire a dedicated infra engineer in Q1, which makes self-hosting cheaper.

That paragraph builds enormous trust with non-technical stakeholders. It signals that you have thought about how you might be wrong, which is the single biggest thing engineers can do to establish credibility with executives. The Gerald Weinberg writing on consulting covers this ground better than I can, and is still worth a weekend.

Mediums and timing

Not every tradeoff needs a meeting. Some are better delivered in a Slack message, a one-page memo, or a five-minute hallway conversation. The medium matters more than engineers tend to acknowledge.

The mistake is to default to meetings. They are expensive, they invite hijacking by tangential concerns, and they make consensus harder, not easier, because everyone present feels obligated to comment. Where possible, do the work async, leave the meeting for ratification.

Common Pitfalls

Hedging the recommendation. “There are pros and cons to both” is not a recommendation. Executives need a verb. Pick the option, name the conditions for revisit, and own the call.

Treating the listener as an opponent. They are your client, not your adversary. They have less context than you and more context about the business than you do. Both are true. Plan accordingly.

Using engineering numbers without translation. “Latency drops by 200ms” means nothing to a non-engineer. “Page load gets fast enough that users do not abandon the cart” means something. Always translate to the metric they already care about.

Confusing certainty with confidence. Confidence is “I have done this before and here is what happened.” Certainty is “this will definitely work.” Confidence earns trust. Certainty, when it inevitably turns out to be wrong, destroys it.

Skipping the followup. Tradeoffs change. The vendor that was right in Q4 might be wrong in Q2. Build a calendar reminder to revisit any significant decision after the conditions you named might have changed.

Letting the conversation become a defense. If you find yourself defending your recommendation rather than helping the listener decide, the conversation has gone wrong. Pause. Reset. “I want to make sure I am answering your actual question.” Sometimes that one sentence saves a thirty-minute meeting.

Wrapping Up

Communicating tradeoffs is one of those skills that compounds quietly. The first time you give a clean three-option, two-minute briefing to a CEO who actually makes the call you recommended, you will notice that the conversation took less time and produced more action than the version where you tried to teach them everything you knew. That is the entire game.

The discipline is not to dumb down. It is to compress. Compression preserves the structure of the problem while shedding the implementation detail the listener does not need to make the decision. Done well, it leaves the listener feeling smart and your team trusted. Done poorly, it produces the worst of both worlds, a stakeholder who is confused and an engineer who is frustrated.

Practice it. The next time you have a tradeoff to present, write it out in three parts before the meeting. Frame, compress, recommend. Time yourself. Iterate. By the fifth or sixth time, the shape will be automatic, and you will have made yourself substantially more useful to the people who decide what your team gets to work on.