There’s no shortage of advice on how to give a great talk. You’ll find videos, Twitter threads, ChatGPT prompts, and even entire books. Most of it is solid. But in this post, I’m skipping the usual tips to focus on stuff nobody talks about. The things that only become obvious after you’ve given—and, more importantly, sat through—enough talks.

Most bad talks are bad because the speaker never thought about the outcome they wanted. I don’t mean vague performance metrics like the applause afterward or even the session feedback scores. I mean actual outcomes: Did the audience learn anything new? Did they follow up with questions? Did they try out your project?

A lot of speakers don’t ask these questions. They treat conference talks like a checkbox. “We need to do more developer relations,” someone says, and the next thing you know, someone’s on stage with 40 slides of a product pitch disguised as a walkthrough. No one remembers it five minutes later.

The greatest talks I’ve been to—and the ones I’ve given—started with a clear goal. These goals weren’t always complex; sometimes, it was just: I want Kubernetes users who have never heard of the Kubernetes Gateway API to understand why it was created and how they can try it with Apache APISIX. That’s it. That level of clarity makes it easy to omit everything that doesn’t help you get there.

And that’s another problem: too many talks are full of details no one asked for. In my “How is Apache APISIX Fast?” talk, it would have been easy for me to go down the rabbit hole to explain Nginx internals and LuaJIT quirks, but it would have been too much for someone in the crowd who is already three talks in and thinking about lunch. Hiding the details isn’t dumbing things down; it’s respecting the listener’s time and energy.

This doesn’t mean all talks should be beginner-friendly. It is safe to assume some level of knowledge and experience in your audience depending on the conference. But it does mean all talks should be accessible. There’s a difference. You need to make it easy for your audience to connect the ideas. That doesn’t have to mean simplifying your ideas but simplifying the way you present them.

It doesn’t help that everyone has TikTok brains now. Attention spans are short, and even the most motivated attendees can only absorb so much in a sitting. If your talk is just a long, boring monologue with no clear thread, people will tune out—and there’s nothing worse as a speaker to see people in your audience chatting amongst themselves or being on their phones. This means you need to be clear and build a narrative. People forget bullet points, but they remember stories.

Another thing that speakers often forget is that a conference talk is not documentation. Knowledge is mostly free. People don’t come to your talk for facts—they come for your takes. They want to know what worked and didn’t and why you chose to do something over the other. Your experiences and opinions give your talk its weight. One of my most popular talks is on the Kubernetes Gateway API, and it is popular because I include my experience in working around such specifications for the past five years.

None of this is set in concrete. I’ve figured out everything I shared here by doing them wrong and watching others do them right. But if you start with a clear outcome, cut what doesn’t help, keep it accessible, and share your perspective, you’ll be way ahead of most speakers.

Thanks to Abhishek Choudhary for asking me to write this post.