You can be the most technically right person in the room and still lose the decision.
It happens more often than anyone admits: an engineer, an architect, a specialist walks into a meeting with the correct answer, the honest risk assessment, the number that should end the conversation — and watches the room decide to do something else. Something more expensive to fix later.
Being right is not the same as being heard
In more than three decades around technology projects — networks, migrations, integrations, transformations that didn’t have that name yet when I started — I’ve watched the same pattern repeat across companies, industries, and generations of tools. The technical case was correct. It didn’t matter.
Decision-makers aren’t evaluating your competence. They’re evaluating exposure: budget, timeline, political capital, reputational risk, what they’ll have to explain upward if it goes wrong. When a technical case is presented as “this is objectively correct,” it’s competing for attention with framings that speak that language — and usually losing.
From proving to translating
The shift that changes outcomes isn’t getting more technically thorough. It’s translating the same truth into the currency the room actually trades in. Three moves that consistently work:
1. Lead with the decision, not the derivation. State the recommendation and its consequence in the first sentence. Put the architecture diagram on slide six, not slide one.
2. Translate technical risk into business risk. “Unpatched dependency” becomes “a single point of failure that can stop billing for 48 hours.” Same fact. Different weight.
3. Offer a choice, not a verdict. Decision-makers resist being told what to do. They respond to two or three options with visible trade-offs — cost, time, risk — because a choice lets them own the outcome instead of just approving yours.
What gets in the way
The most common failure isn’t lack of expertise. It’s jargon-first slides, a recommendation buried on the last page, technical purism that treats “good enough” as an insult, and — quietly the most damaging — no named owner for the decision once it leaves the room.
If nobody owns the decision, the correct technical answer simply evaporates under the next budget cycle.
A practical exercise
Before your next proposal, rewrite the opening line so that a non-technical stakeholder could repeat it accurately after hearing it once. If they can’t, the rest of the deck won’t save it.
Technical credibility gets you into the room. Business translation is what keeps the room listening.
Leave a Reply