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:

1. Situation (1-2 sentences): What problem were you trying to solve? What was at stake?

2. Battle (2-3 sentences): What made it hard? What did you try that didn’t work?

3. 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.