I've given technical talks in college and at work, and for a long time I assumed people remembered them.
Then, six months after what I thought was a definitive talk on React context re-renders, an engineer brought it up. They remembered the venue. They remembered the lunch. They could not name a single technical point from the forty-five minutes.
Fair enough, honestly. I'd built that talk the way I'd seen many technical talks built: background on the architecture, every dependency listed, three slides of code too small to read, a wall of Lighthouse numbers, and an ending rushed because questions ran over. I was aiming for thorough, and nobody keeps thorough.
One idea per talk
So now every talk gets one idea, the one I want people using in their next pull request. If someone still uses it two quarters later, the talk worked.
A few things help it stick. Show the effect instead of the code: a profiler flame graph spiking, then going flat after the fix, beats any snippet. Open with a problem everyone in the room has suffered through, because a fix only lands when the pain is familiar. And leave things out, edge cases especially. People are building a mental model, and nobody builds one from a spec read aloud.
Big architecture diagrams and tiny code are often a way of proving you deserve the stage. The audience doesn't need proof. They need something to do differently on Monday.
Questions I ask before opening Keynote
- What should the team stop writing tomorrow?
- What's the clearest visual proof that doesn't need a terminal?
- What's the least context that makes the fix obvious?
A talk is one of the most expensive hours in a team's week. Please don't spend it reading them your documentation.