The Storytelling Traps I Still Fall Into As A Technical Leader
Being right isn’t the same as being heard. How to stop losing the room and start using progressive disclosure to get buy-in.
The meeting where I lost the room
Have you ever walked out of a meeting thinking, “That was technically correct”… and also realising nobody is going to back you? I've been there. I've delivered what I thought was a solid update — architecture, edge cases, trade-offs, the whole thing — and watched people's faces do that slow, polite fade into the distance.
At some point I had to admit something slightly painful: being right isn't the same as being heard. And if the room doesn't “get it”, the best idea in the world dies quietly in a calendar invite.
Why your audience forgets the best bits
Here's the annoying part: your audience isn't failing you. Their brain is doing what brains do. Working memory — the “mental workspace” we use to hold and manipulate information — is limited. A lot of research converges on a small capacity, often described as roughly about four chunks at a time.
So if I start my story with:
- five system components
- three historical migrations
- two competing algorithms
- and a “quick” detour into how we model idempotency
…I've already used up the mental budget, before I've even explained why anyone should care.
The Coherence Principle:
Learning and comprehension tend to get worse when we add extraneous material. “Less extra stuff = better learning.” And even if your content is good, attention is fragile. In lecture settings, mind-wandering is common across a third of attention probes. In a meeting where Slack is pinging? You don't get many second chances.
Stories are not fluff; they are a delivery mechanism
A story isn't “dumbing things down”. It's a compression algorithm for meaning.
Across a large meta-analysis, narrative texts were more easily understood and better recalled than expository texts. There's also evidence that stories can stickin a way that raw numbers don't — the “story–statistic gap” shows the belief impact of statistics decays much faster over time than stories.
Why? Narrative transportation: when people are absorbed into a narrative, attention, emotion, and mental imagery line up behind the story, making them less likely to counterargue. That's why technical leaders have a responsibility: use story to make truth travel, not to smuggle in nonsense. Story is the vehicle; evidence is still the fuel.
“Treat the audience as the hero and the speaker as the guide — the point is their journey from confusion to clarity, not your journey from PRD to production.” — Nancy Duarte
Trap: shipping the appendix first
This is the classic technical-leader reflex: leading with the internals.I do it because I want to be correct, I want to pre-empt questions, and I don't want anyone to think I've missed something. But it's the wrong order. A better default is progressive disclosure.
Headline: Give the headline and stakes.
Layer Two: Offer the next layer.
Backup: Keep the deep technical layer ready as backup.
Here's what that looks like in plain English:
What I used to say (appendix-first)
“We're moving from batch processing to a streaming architecture. The current pipeline uses X, Y, Z, and has backpressure issues at peak. We're considering Kafka versus Kinesis, and...”
What I say now (stakes-first)
“Right now it takes us a day to spot data issues... The change I'm proposing gets detection down to minutes. The trade-off is extra operational complexity — and I've got the options and costs if we want to go deeper.”
Notice what changed: I didn't hide the complexity. I just earned the right to talk about it.
Trap: thinking credibility comes from caveats
You know the move: I'm telling a story, it's going well, and then I interrupt myself with a caveat like, “Technically speaking...”, followed by a 90-second qualifying statement that includes at least one acronym. A huge driver of this is the curse of knowledge: when you know a lot, it becomes hard to remember what it's like not to know it.
If working memory is limited, every extra branch competes with the main line of the story. I confuse thoroughness with clarity. What I try to do instead is separate “truth” from “totality”. A story can be true without being complete.
“There are edge cases, and I'm happy to go into them — but the decision in front of us is ___.”
That one line does three things at once: it preserves credibility, it keeps momentum, and it invites the right questions at the right time.
Trap: rewinding to the origin story
Technical people love context. But in storytelling, context is a tax.If you collect too much tax upfront, people stop paying attention. One simple fix is the ABT template (And–But–Therefore) popular in science communication.
- And = what we agree on / the current reality
- But= the tension / what's broken / what changed
- Therefore= what we're doing about it
ABT basically gives you permission to start near the "But". Let's look at an AI/data example:
The "rewind" version
“Three quarters ago we started exploring document extraction. We tried approach A, then we ran into scaling issues, then we refactored the pipeline, then we...”
The ABT version
“We process loan documents, and today critical fields still get checked manually. But manual review slows approvals. Thereforewe're rolling out an extraction workflow that flags uncertainty...”
Trap: building a saga when people need a decision
If I deliver a ten-minute epic, I'm not demonstrating rigour — I'm consuming attention that doesn't exist. A leadership meeting usually isn't asking for a full narrative, it's asking for: What's the decision? What's the risk? What do you need from us?
So the practical move is to segment: deliver a short arc, pause, check for alignment, then optionally go deeper. What I aim for now is a short decision story:
- a 15–30 second setup
- a 10-second tension
- a clear ask
If I can't do it in under a minute, it's often a sign I haven't decided what the real point is yet.
The two-layer method I use now
Layer One (For Everyone)
The simplest true version — the one that fits in working memory. E.g., “We're spending too much time on manual checks... Therefore we're introducing an automated step.”
Layer Two (For the Lean-ins)
The appendix and architectural diagrams. Confidence thresholds, failure modes, monitoring plans. You keep it ready, but it doesn't drive the first two minutes.
To avoid the storytelling traps:
- Don't ship the appendix first — use progressive disclosure.
- Separate “truth” from “totality” — skipping a nuance isn't a lie.
- Cut the origin story tax — use the And-But-Therefore format.
Ask yourself: am I trying to be impressive… or am I trying to be understood?