I was setting up for a workshop on technical storytelling recently when someone asked me about the elevator pitch. You know the one: you’ve got 35 seconds in an elevator to sell your idea. Short, punchy, persuasive.
But here’s what most people don’t know: the original elevator pitch wasn’t a speech at all.
Elisha Otis, the inventor of the safety elevator brake, didn’t stand in front of a crowd and tell them his brake worked. He had his crew cut the elevator cable while he stood inside, demonstrating the safety mechanism in real time. He showed them. That’s the real elevator pitch: a live demonstration that proves your point instantly.
That story has stuck with me because it captures something I’ve been thinking about for years: the difference between presenting information and actually connecting with people.
The Interpreter, Not the Translator
Working in IT since the mid-90s, I’ve seen this pattern: technical people struggle to communicate with business stakeholders, and business people struggle to understand what the technical team is actually doing. The gap isn’t about intelligence. It’s about translation.
But translation isn’t enough. You can translate words from one language to another and still miss the meaning entirely. What we need is interpretation: understanding the context on both sides and conveying the true intent.
When I talk to developers about automated testing, I tell them tests ensure their architecture tells a coherent story and allows for safe future changes. When I talk to business stakeholders about the same tests, I tell them it’s a way to explicitly document our current understanding of their business needs. Same practice, different lens.
The key is knowing your audience well enough to speak their language.
Start With Why, Not What
I like Simon Sinek’s Golden Circle concept: people don’t buy what you do, they buy why you do it.
When I first started writing tests, I thought the “what” was the point: write tests, run tests, ship code. But the real “why” took me years to see: tests are fundamentally about improving collaboration and communication. Once I understood that, everything else became flexible. The practices could adapt, but the purpose stayed clear.
This applies to any technical story you’re trying to tell. If you lead with the “what” (we need to implement this framework, adopt this tool, refactor this system), you’ll lose people. But if you start with the “why” (we need to reduce deployment risk, improve team velocity, make our system more maintainable), suddenly you have their attention.
The “why” is where the business impact lives.
Show, Don’t Just Tell
If you rely entirely on words, you’ll lose people who think in images.
I used to give talks that were mostly me talking through concepts. Then I started adding visuals, diagrams, and live demonstrations. The difference was immediate. People stayed engaged. They asked better questions. They remembered the content later.
This is about recognizing that different people process information differently. Some need to see it. Some need to hear it. Some need to try it themselves.
When I’m explaining a technical concept now, I think about Elisha Otis standing in that elevator. What’s the equivalent demonstration for what I’m trying to communicate? How can I show this, not just describe it?
Engineer Your Talk Like You Architect Software
One thing that surprised me when I started giving talks was that the skills I use to design software apply directly to designing presentations.
You map out the flow. You think about pacing. You consider the emotional journey. You identify the critical path and the dependencies. You test your assumptions.
And just like in software, you acknowledge what you don’t know. I start most talks by saying something like: “This is what I know as of now. I don’t expect to have all the answers. If anyone here knows more than I do about this topic, please reach out afterward. I’d love to learn from you.”
That vulnerability disarms the room. It earns respect. And it’s honest.
The Problem With Self-Editing
During the workshop, someone mentioned they had too many ideas but struggled to ship them. They’d create a presentation, look at it, and think: “This isn’t good enough.”
I see this all the time. We’re our own worst critics. We compare our rough drafts to other people’s polished work and conclude we’re not ready.
Here’s what I told them: get it out. Show it to someone else. Don’t keep refining it in your head. The thing you’re creating isn’t for you—it’s for someone else. So test it with someone else.
Most of the time, what you think isn’t good enough is actually exactly what someone needs to hear.
Finding Problems Worth Solving
Someone asked me once: how do you know what talks to give? What problems are worth addressing?
My answer: Pay attention to people. When you see someone struggling, ask them what’s going on. Listen. Empathize. Maybe you have the solution. Maybe you know someone who does.
The best technical talks I’ve seen aren’t about showcasing the speaker’s expertise. They’re about solving real problems that real people are facing right now.
If you’re stuck on what to talk about, look around. The problems are everywhere. You just have to notice them.
Avoiding the Traps
A few things I’ve learned not to do:
Don’t assume everyone shares your references. I can’t tell you how many technical talks I’ve sat through where the speaker assumes everyone is a Star Trek fan or follows a particular sport. If your analogy requires niche knowledge, you’ve lost half the room.
Don’t hide behind jargon. Acronyms and technical terms have their place, but if your audience doesn’t know them, you need to explain. Or better yet, find a simpler way to say it.
Don’t present like you have all the answers. You don’t. Nobody does. The moment you pretend otherwise, you invite people to poke holes in your argument.
What I’m Still Learning
I ran this workshop for the first time recently. I’ve created my own technical stories for years, but teaching others how to do it? That’s different.
Not everything landed as I hoped. But that’s part of the process. You ship something, you get feedback, you refine it. Just like software.
The participants shared their struggles: too many ideas, not enough confidence, pressure from leadership, and uncertainty about what the audience wants to hear. All valid. All familiar.
These challenges are similar to the challenges we face in software development. Communication isn’t a separate skill from technical work. It’s woven through everything we do.
The question I’m sitting with now: how do we make this easier? How do we help technical people see that they already have the skills to tell compelling stories? They just need to recognize that the same principles that make good software also make good communication.
What would change if we approached every technical conversation the way we approach system design—with intention, empathy, and a focus on solving real problems?
Leave a Reply