The Best Talk I Gave Took 20 Minutes to Prep. The One I Rehearsed for Weeks Bombed.

Day 12: You're Not Bad at Public Speaking — You're Bad at Writing It Down First

Nobody freezes up because their voice is bad. They freeze up because the idea in their head never got finished, and the stage is just the first place that becomes obvious. Fix it before you ever touch a microphone.

The talk that was really just a Slack update

A couple of years ago I gave two talks in the same month. For the first — an actual conference talk — I burned three weekends on slides, wrote out a script, and rehearsed my pauses in the mirror like an idiot. It landed fine. Polite applause, a few nods, gone from everyone's memory by lunch. The second was an internal demo I almost skipped because I was slammed. So I grabbed the weekly Slack update I'd already written for my team — one thesis, three bullets of evidence, one 'so what' — pasted it into slides with almost no editing, and just read it out loud in my own voice. That one got more questions than any talk I've ever given. People were still quoting it back to me weeks later. Prep time on the first talk: maybe ten times what I spent on the second. Results: the exact opposite.

The fear, and the assumption hiding inside it

"I'm not a public speaker" is the line I hear most from senior engineers and new EMs — people who are completely fluent in a standup or a design doc. Buried in that sentence is an assumption: that speaking is its own separate skill, needing its own separate training — stage presence, vocal technique, charisma, the works. That assumption is mostly wrong. If you can write a clear status update, a clear incident postmortem, or a clear PR description, you've already done the hard part. The fear of standing up in front of people is real, sure, but it's a smaller problem than people think, and it's not what makes a talk bad. Talks go bad because the content was never made clear in the first place, and no amount of stage presence patches that.

The realization: every talk that worked, I'd already written first

When I went back through every talk, demo, or all-hands update that actually landed, they all traced to the same thing: something I'd already drafted and rewritten before I said a word of it out loud. A design doc I'd rewritten three times. A ticket description tightened until the acceptance criteria fit one sentence. A postmortem timeline cut down from a wall of text to five lines. The talks that flopped were the ones where I skipped that step and tried to figure out what I wanted to say live — in the slides, or worse, in my head, in the shower, the night before.

Why writing-first beats rehearsing delivery

• ▹You can only revise on paper. A live sentence is gone the second it leaves your mouth — but a bad paragraph you can cut five times until it's one clean line, and that's where the actual improvement happens.
• ▹The structure travels for free. Thesis, evidence, so what — same skeleton whether it's a Jira comment, a postmortem, or a keynote. Nail it in writing and delivery is just reading it with feeling.
• ▹You find the confusion before anyone's watching. On paper, confusion looks like a paragraph you can't finish. On stage, it looks like you, live, in front of a room — a much more expensive place to notice.
• ▹Rehearsing delivery trains the wrong muscle. Drilling tone and pacing on a muddled argument just makes you more confident at delivering something confusing.

When I tried to skip the writing step

I've got the opposite pattern on record too. A few times I winged it — decent instincts, no draft, trying to find the throughline live on stage. Those talks rambled. I'd start a point, get halfway through, realize I didn't actually know why it mattered, and either trail off or over-explain to cover the gap. Other times I overcorrected: memorized a script word for word and drilled the delivery for hours. Those came out stiff — more polished, less true — and the second someone asked a question that broke the script, I lost my thread completely. Both failure modes cost more prep hours than the Slack-update talk. Neither one cost more hours of actual writing and revising.

Where this fits in the 30-day arc

That's why this is Day 12 and not a standalone 'presentation skills' module. Public speaking isn't a new skill you're bolting on — it's the output stage of the clarity work you've been doing since day one: the status updates, the decision docs, the tickets you've been learning to write tighter. If those are sharp, speaking is just voicing them out loud. If they're not, no speaking coach is fixing that on the morning of the talk.

This matters more, not less, now that agents are in the loop. When an AI can draft the first pass of your status update, your PR description, or your incident summary, your job shifts from typing to editing for clarity — and that edited draft is exactly the artifact you'll stand up and deliver. If you're demoing an autonomous coding agent's work to stakeholders, or explaining why an LLM-judge eval regressed, the talk that lands is the one built on a doc where you already fought through 'what actually happened, and why does it matter' — not one where you're narrating a screen of agent logs live and hoping the story assembles itself as you go. Use the model itself as a first editor here: paste your draft update in and ask it where your thesis gets fuzzy, or to compress three paragraphs into the single 'so what' line you'll actually say out loud. That's a legitimate, high-leverage use of the tool — it's editing your writing, not writing your talk for you.

The exercise: try this on your next standup or demo

• ▹Next time you're asked to present anything — a demo, an all-hands update, even a five-minute standup segment — spend 80% of your prep time turning it into a tight written doc: one thesis sentence, two or three pieces of evidence, one 'so what.'
• ▹Revise that doc the way you'd revise a PR description: cut every sentence that doesn't serve the thesis. If a slide doesn't map to a line in the doc, cut the slide.
• ▹Read the finished doc out loud once, in your own voice, before you touch a slide deck. If it's confusing to say, it was confusing to write — go fix the doc, not your delivery.
• ▹Only then adapt it for speaking: add a transition, a pause, maybe one example. Spend your remaining 20% here, not before.

Extend your knowledge

• ▹Pull up your last three status updates or PR descriptions and check: can you find one thesis sentence and one 'so what' in each? If not, that's the real gap — not your speaking voice.
• ▹Read Paul Graham's essay 'Writing, Briefly' — a short, sharp case for revision as the actual clarity tool — then apply the same cutting discipline to your next demo script.
• ▹Next time you use an AI assistant on a status update, prompt it to critique clarity ('where does my argument get weak here?') instead of asking it to write the update from scratch. Keep ownership of the thesis.
• ▹Pull up a recording of one of your own past talks or demos and try to write its thesis, evidence, and so-what in three lines after the fact. If you can't, that's exactly the gap this lesson is about.