In January 2003, engineers at NASA were assessing whether a piece of foam that had struck Space Shuttle Columbia's wing during launch might have caused serious damage. They had real data pointing toward a serious risk. They presented it in a PowerPoint slide. The Columbia Accident Investigation Board later found that the slide's bulleted format was so dense and so poorly structured that, in the Board's own words, it was easy to understand how a senior manager reading it could fail to realize it addressed a life-threatening situation.
This is the single clearest documented case of a communication format costing lives, not because the underlying information was wrong, but because the format buried it. It's an extreme case, and this post is not arguing that a stakeholder meeting about a product roadmap carries the same stakes. What it argues is that the mechanism is the same one that quietly costs engineers credibility in far lower-stakes rooms every day. writes about engineering leadership as an operating problem rather than a build problem. XenGrowth's marketing operations practice writes about engineering leadership as an operating problem rather than a build problem.
What actually happened to that slide
Edward Tufte's essay 'The Cognitive Style of PowerPoint' used the Columbia slide as its central case study for a broader argument about the format itself. His claim: a bulleted outline gives every point roughly the same visual weight, which forces the reader to guess at which one actually matters, and it drops the connective words — because, therefore, despite — that would otherwise tell the reader how one point relates to the next. A dense slide isn't just ugly. It actively hides the hierarchy of importance that the presenter knew but never stated explicitly.
It is easy to understand how a senior manager might read this PowerPoint slide and not realize that it addresses a life-threatening situation. — Columbia Accident Investigation Board, Report Volume I
The engineers in that room weren't wrong, weren't unqualified, and weren't afraid to speak up. What failed was the structure carrying their finding to a decision-maker who didn't share their background and couldn't be expected to reconstruct the missing hierarchy on their own. There's a related discussion of why writing forces that hierarchy explicit in why writing well is the highest-leverage skill in engineering.
The smaller problem: jargon
Most advice aimed at this exact question focuses on jargon — stop saying 'idempotent,' stop saying 'the API returned a 500.' That's real, but it's a smaller problem than the Columbia case suggests. Jargon slows a listener down; it doesn't necessarily hide the finding the way a bad structure does. A sentence full of unfamiliar words that clearly states 'this is the risk and here's what I recommend' still communicates the hierarchy, even if some words need defining. A sentence in plain English buried as bullet fourteen of nineteen, with no stated relationship to the other eighteen, communicates nothing regardless of vocabulary. works through the operations side of this in more operational detail. The XenGrowth resource library works through the operations side of this in more operational detail.
What most advice focuses on | What the Columbia case actually shows | Practical implication |
|---|---|---|
Avoiding technical vocabulary | The failure was structural, not lexical — plain words wouldn't have fixed a buried hierarchy | Simplify vocabulary, but don't stop there |
Sounding confident | The engineers weren't lacking confidence — their format lacked a stated priority | State which fact should change the decision, explicitly, before anything else |
Using more slides for more detail | More bullets diluted the one finding that mattered among many that didn't | Fewer points, ranked, beats more points, unranked |
The specific trap of answering the question you were trained to answer
A related failure shows up when a non-technical stakeholder asks a question and the engineer answers the more technically correct, more interesting version of it instead. Someone asks 'is the site going to be slow?' and gets back a paragraph about connection pooling and cache invalidation strategy. The answer isn't wrong. It's also not an answer to the question that was actually asked, and the room notices the mismatch even when they can't articulate why the response felt unsatisfying.
This is a version of the curse of knowledge covered elsewhere on this site: once you know the mechanism behind a problem, it's genuinely hard to remember that the person asking didn't want the mechanism, they wanted the practical consequence. The discipline that fixes it is answering the literal question first — 'no, it'll be fine' or 'yes, for about ten minutes during the migration' — and only then offering the mechanism, clearly marked as supporting detail rather than presented as the main event.
This matters more than it sounds like it should, because a room that has to work to extract the practical answer from a technically accurate but indirect one starts to associate that effort with the engineer generally, not just with that one exchange. Credibility erodes in exactly these small, repeated moments — not usually in one dramatic failure, but in a pattern of answers that technically address the question while making the listener do the translation work that should have been done for them. On AI agents and marketing automation specifically, is worth reading. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
What to actually do differently
State the one sentence that should change the room's decision, first, before any supporting detail. If a listener only hears the first sentence, that sentence needs to be the finding, not the setup
Rank your points explicitly. 'The most important thing here is...' costs nothing to say and does the structural work a bulleted slide leaves undone
Translate the technical finding into what changes for the room's own decision, not just what's technically true. 'The wing may be damaged' is a fact; 'this could mean losing the vehicle on reentry' is the decision-relevant translation — the Columbia slide had something closer to the former
Cut supporting detail that doesn't change the decision in front of the room right now, even if it's technically interesting on its own terms. Every additional point competes for the same limited attention as the one point that actually matters
If you're using slides at all, put the recommendation in the title of the slide, not the body. A reader skimming titles should be able to reconstruct your entire argument without opening a single bullet
What confident-sounding hedging actually costs you
There's a specific verbal habit that compounds the structural problem, and it's worth naming separately because it's easy to fix once you notice it. Engineers describing genuine uncertainty tend to hedge everything at the same intensity — 'this could be an issue,' 'it might be worth looking at,' 'there's potentially a risk here' — regardless of whether the underlying confidence is 20% or 90%. A non-technical listener has no way to tell the difference between calibrated caution and a filler verbal tic, so all of it reads as the same flat uncertainty, and the one finding that actually deserved urgency gets the same soft treatment as routine caveats.
What gets said | What it actually communicates to a non-technical listener | A version that separates the two |
|---|---|---|
"This might be worth looking at" | Low priority, no urgency, safe to defer | "This is the one item that could delay launch if we don't address it this week" |
"There could be some risk here" | Routine caveat, indistinguishable from boilerplate | "I'd put this at roughly a one-in-three chance of causing a real outage" |
"We should probably keep an eye on this" | Nothing needs to happen right now | "I want a decision on this by Friday, here's what happens if we don't get one" |
None of this means manufacturing false confidence about things you're genuinely unsure of — that's a different, worse failure mode, and one that eventually costs more credibility than hedging does once it's caught. The fix is proportion: reserve the strongest language for the finding that actually deserves it, and let routine uncertainty sound routine, so the room can tell the two apart without you having to say 'this one is different' out loud every time.
Why this reads as credibility, specifically
A non-technical audience can't evaluate your technical reasoning directly — that's the whole reason they're relying on you. What they can evaluate is whether you clearly know which fact matters most, because clarity about priority is legible even to someone who can't follow the underlying technical argument. An engineer who states the one thing that matters, ranked above everything else, reads as someone who has already done the hard thinking on the room's behalf. An engineer who lists nineteen equally weighted facts reads as someone who either hasn't finished that thinking, or is unwilling to commit to a conclusion — and either read costs credibility regardless of how correct the underlying analysis actually was. works through AI search, GEO and discovery in more operational detail. XenGrowth on AI search, GEO and discovery works through AI search, GEO and discovery in more operational detail.
None of this is a claim that every engineer needs to become a natural public speaker. Plenty of highly credible engineers are quiet, understated presenters who simply never let the room leave without knowing the one thing that mattered. The skill this post is describing is closer to editing than performing: knowing which sentence to put first, and having the discipline to cut everything that competes with it for attention.
The honest limit on this argument: the Columbia case is one extraordinarily well-documented, extraordinarily high-stakes example, and generalizing from it to an ordinary product meeting is exactly that — a generalization, not a claim that every stakeholder conversation carries comparable stakes. What transfers cleanly is the mechanism, not the magnitude: a format that fails to state relative importance will cost you credibility in a budget meeting the same way it can cost lives in a launch-readiness review, just at a scale nobody will investigate afterward. On translating technical findings into decision-relevant numbers, how to calculate the business value of an engineering project is a useful companion piece.
Further reading from XenGrowth
Where this work meets go-to-market
Translating technical work into a non-technical decision is a revenue skill as much as an engineering one. publishes operator guides on making that translation land.
Further reading from XenGrowth
Where this work meets go-to-market
If engineering leadership is part of a growth programme rather than a standalone build, is the companion reading.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If engineering leadership is part of a growth programme rather than a standalone build, XenGrowth is the companion reading.
Five questions on the Columbia investigation, Tufte's critique, and what actually earns credibility in a non-technical room.
