What giving talks keeps teaching me about clarity

The fastest way to discover whether an idea is actually clear is to say it out loud in front of other people.

Preferably with slides.

Preferably while a projector is negotiating with an adapter that appears to have given up on life.

I like speaking because it forces compression. You cannot bring the whole notebook. You cannot hide behind “well, it depends” for twenty minutes straight. You have to choose what the audience actually needs, what order to present it in, and which caveats deserve space versus which ones are mostly a sophisticated form of stalling.

That pressure is useful.

Talks expose fake understanding

There are ideas that feel clear in your head because they are surrounded by context only you can see.

Then you try to explain them to a room and realize you have been leaning on invisible assumptions the whole time.

This happens to me most often with technical abstractions. I think I understand a system because I can navigate it internally. But when I try to explain why a design tradeoff mattered, or how a workflow actually helps in practice, the weak points show up immediately. The talk becomes a diagnostic tool.

That is one reason I recommend speaking, even informally, to people who build things. It is a great test of whether your thinking is portable.

Clarity is often a subtraction problem

The instinct when preparing a technical talk is usually to add.

Add more detail. Add another diagram. Add the edge case. Add the clever example. Add the backup slide for the backup slide.

Usually the better move is subtraction.

What does the audience need to remember tomorrow? What is the one diagram that actually unlocks the idea? Which detail earns its place, and which one is there because I find it interesting?

Good talks are not just collections of facts. They are carefully designed paths through complexity.

Sequence matters more than density

I have seen extremely smart people lose a room simply by presenting the right information in the wrong order.

You can often fix a confusing explanation without changing the content at all. Change the sequence. Start with the problem instead of the architecture. Show the before state before the solution. Name the constraint before the tradeoff. Let the audience build the mental model with you instead of throwing the whole thing at them like a dependency tree.

This lesson applies far beyond talks. It applies to docs, onboarding, product design, even code review comments.

Clarity is choreography.

Audiences are excellent at detecting unnecessary cleverness

One of the more humbling things about speaking is realizing that people respond much better to grounded specificity than to intellectual ornament.

If I say, “Here is the workflow we tried, here is what broke, and here is how we fixed it,” the room tends to lean in.

If I try to sound abstractly visionary too early, the room politely waits for me to become useful again.

That is healthy. It is also transferable. I think a lot of engineering communication improves when we stop trying to sound advanced and start trying to sound precise.

Why I keep saying yes

I say yes to talks because they sharpen my thinking. They help me package ideas without flattening them. They create conversations I would not have had otherwise. And every now and then, someone comes up afterward with a question that quietly upgrades the whole topic.

That exchange is the real reward.

A good event does not feel like broadcasting. It feels like collaborative refinement. You bring a frame. The audience brings context, disagreement, curiosity, and weirdly specific war stories. Everybody leaves smarter.

That seems worth keeping.