Speaking Skills: Technical Storytelling
The problem: You solved a hard problem. Nobody understands why it mattered. The fix: Learn to tell the story, not just explain the solution.
Today’s Focus Word
“Compelling” — something that makes people want to listen, that is interesting and convincing.
- “Her explanation was compelling — even the CEO was leaning in.”
- “I need to make this proposal more compelling before the board meeting.”
- Opposite: dry, technical, hard to follow
Why Engineers Struggle with Storytelling
Most engineers are trained to be precise, complete, and correct. Stories are the opposite — they are selective, simplified, and emotional.
When you talk about your work, you probably do this:
“We migrated from PostgreSQL to a distributed key-value store using consistent hashing with a replication factor of 3, achieving 99.99% availability with p99 latency under 5ms.”
Your audience hears:
“We did something technical. Numbers. More numbers.”
The goal of technical storytelling is not to simplify the truth. It is to make the truth matter to your audience.
The 3-Part Story Structure (SBR Framework)
Every compelling technical story has 3 parts:
S — Situation (Set the scene)
What was happening? What was at risk?
B — Battle (The challenge)
What did you fight against? What made it hard?
R — Resolution (The outcome)
What changed? What was the impact?
Key Phrases for Each Part
Situation phrases
- “We were in a situation where…”
- “At the time, the system was struggling to…”
- “Imagine having 3 million users and your database starts…”
- “Every time a user clicked checkout, they would see…”
Battle phrases
- “The tricky part was…”
- “The challenge we kept hitting was…”
- “We tried X, but it didn’t work because…”
- “We spent two weeks going in circles until…”
Resolution phrases
- “That’s when we realized…”
- “Once we made the switch, we saw…”
- “The result was a 4x improvement in…”
- “Now our on-call team sleeps through the night — literally.”
Before & After: See the Difference
Before (engineer mode):
“We implemented circuit breaker patterns with exponential backoff and added Redis caching at the service layer to reduce database load by 60%.”
After (story mode):
“Black Friday last year, our checkout was timing out every few minutes. Users were losing their carts. The team was panicking. We traced it back to one slow database query that was cascading everywhere. We added a caching layer and a safety net so one slow service couldn’t take down everything. This year? Zero incidents. The team had a boring Black Friday — and that’s exactly what we wanted.”
Same facts. Completely different impact.
Today’s Practice: 5-Minute Drill
Pick a technical project you worked on. Tell the story using SBR.
Write or say out loud:
-
Situation (1-2 sentences): What problem were you trying to solve? What was at stake?
-
Battle (2-3 sentences): What made it hard? What did you try that didn’t work?
-
Resolution (1-2 sentences): What changed? What was the actual impact in human terms?
Target: Under 90 seconds when spoken aloud.
Vocabulary Practice
| Technical term | Story-friendly version |
|---|---|
| latency increased | responses got slower |
| system degradation | things started breaking |
| incident | outage / users couldn’t log in |
| rollback | we undid the change |
| root cause analysis | figuring out what went wrong |
| p99 latency | 99% of requests responded in X seconds |
Practice saying each in a sentence. Bonus: record yourself and listen back.
Idioms to Sound Natural
-
“in a nutshell” — summarizing something complex briefly “In a nutshell, we replaced the bottleneck.”
-
“at the end of the day” — what really matters when everything is considered “At the end of the day, users just want it to work.”
-
“hit the wall” — reach a limit or barrier “We kept hitting the wall with the old approach.”
-
“connect the dots” — see how separate things relate “Once we connected the dots, the solution was obvious.”
Pro Tip: Know Your Audience
| Audience | Focus on |
|---|---|
| Engineers | Architecture, trade-offs, technical lessons |
| Product team | User impact, features unblocked, speed |
| Management | Business outcomes, risk reduced, cost saved |
| Interview | Your role, your decisions, what you learned |
Same story, different lens.
Tomorrow’s Preview
Tomorrow we continue with Agile English — handling difficult retro conversations and giving constructive feedback in English.
Keep practicing. The best engineers are the ones who can make others care about the work they do.