Developer Conference Talks

A conference talk is a 25–45 minute window in which you have the attention of 100–2000 developers, in person and on video for years afterward. The talk that lands changes how the audience thinks; it earns the speaker a reputation; it earns the company customers and trust. The talk that doesn't land is forgotten by Tuesday.

## Key Points

- **Specific.** The audience can describe the topic in one sentence after the talk. "How we built X using Y" is specific. "Modern software architecture" is not.
- **Hard-won.** You learned this. Your team learned this. The audience can't easily learn it from a search. Sharing it is genuine value.
- **In your wheelhouse.** You can answer questions for 30 minutes after the talk without feeling like a fraud.
- **Not a sales pitch.** The talk's value is technical or human; the company benefit is downstream. The audience can smell a sales pitch and resents it.
- 1 minute: hook and promise
- 3 minutes: setup and stakes
- 8 minutes: first major section
- 8 minutes: second major section
- 4 minutes: synthesis and takeaways
- 1 minute: closing and Q&A handoff
1. **One idea per slide.** The audience reads slides faster than the speaker speaks. If you crowd the slide, they read ahead and stop listening.
2. **Big text, big images.** Anything that requires squinting from row 30 has failed. Minimum font size is 24pt; bigger is better.

A conference talk is a 25–45 minute window in which you have the attention of 100–2000 developers, in person and on video for years afterward. The talk that lands changes how the audience thinks; it earns the speaker a reputation; it earns the company customers and trust. The talk that doesn't land is forgotten by Tuesday.

The variance is enormous. Same speaker, same audience, two different talks. The difference is preparation and the discipline of the form.

Topic Selection

The hardest part of the talk is choosing what to talk about. Not the choosing of words; the choosing of subject. Pick wrong and no amount of polish saves the talk.

Selection criteria:

• Specific. The audience can describe the topic in one sentence after the talk. "How we built X using Y" is specific. "Modern software architecture" is not.
• Hard-won. You learned this. Your team learned this. The audience can't easily learn it from a search. Sharing it is genuine value.
• In your wheelhouse. You can answer questions for 30 minutes after the talk without feeling like a fraud.
• Not a sales pitch. The talk's value is technical or human; the company benefit is downstream. The audience can smell a sales pitch and resents it.

Bad topics: "Introduction to X" (boring; the docs cover it), "Why Y is the future" (speculative; nobody believes it), "Our product's roadmap" (sales pitch).

Good topics: "How we cut p99 latency from 800ms to 80ms" (specific, hard-won, technical), "Migrating 47 services to a new database without downtime" (specific, hard-won), "What we learned shipping ML models in production for three years" (specific, perspective-driven).

The Promise and the Story

Every talk has a promise — what the audience will know at the end — and a story — the narrative arc that delivers it.

Open with the promise: "At the end of this talk you'll know how we cut p99 latency by 90% and the three patterns we use that you can apply tomorrow."

Then tell the story. Not a chronology of project events; a narrative arc. Setup (why latency mattered to us, what state we were in), conflict (why standard approaches didn't work), discovery (the three patterns), resolution (the result and what we learned). The arc has tension; the audience is following along because the story makes them want to know what comes next.

A talk without a story is a list of slides. The audience disengages. A talk with a story has emotional investment; the audience is rooting for you to get to the end.

Time Budgeting

For a 25-minute talk, the budget:

• 1 minute: hook and promise
• 3 minutes: setup and stakes
• 8 minutes: first major section
• 8 minutes: second major section
• 4 minutes: synthesis and takeaways
• 1 minute: closing and Q&A handoff

Rehearse to time. Most talks run long; the speaker hits a 30-minute talk in a 25-minute slot, gets cut off, and the closing — the part the audience remembers — disappears. Rehearse with a timer. Cut content until you fit.

Forty-five-minute talks are different. The arc has more room to breathe. Two more sections. A demo. But the discipline is the same: rehearse to time; cut to fit.

Slide Design

Most slides should have less on them than the speaker thinks. Three principles:

1. One idea per slide. The audience reads slides faster than the speaker speaks. If you crowd the slide, they read ahead and stop listening.
2. Big text, big images. Anything that requires squinting from row 30 has failed. Minimum font size is 24pt; bigger is better.
3. No bullets-of-bullets. A slide with three nested bullet levels means you have not finished thinking. Decompose into multiple slides.

Code on slides: only show code that the audience can read and that you will explain. If the code is too long for one slide, break it across slides; show the relevant lines. Use syntax highlighting; use a dark background; avoid ligatures that look weird on projector.

Diagrams: line widths, contrast, callouts. The diagram has to read at the back of the room.

The Demo

Live demos are dangerous and powerful. Powerful because nothing lands like watching your code run on stage. Dangerous because everything that can go wrong does.

Rules for live demos:

• Test on the conference's projector. Not your monitor. Conference projectors blow out your dark themes and your colors. Test live before the talk.
• Network in the room is unreliable. Either don't depend on it or test it before going on stage.
• Have a recording as backup. If the live demo fails, switch to the recording without losing momentum.
• Demo only what you've practiced. No improvisation on stage. The audience didn't come to watch you debug.
• Time-box. A demo that takes longer than 4 minutes loses the audience.

The alternative to a live demo: pre-recorded screen capture, narrated. Less risky. Less impressive when it works. Use live demos when they're worth the risk.

The Q&A

Plan the Q&A. The questions you'll likely get, the questions you don't have a good answer to, the questions designed to trip you up.

For questions you can answer: answer briefly. The audience wants the answer, not an excursion. Two minutes max per question.

For questions you can't answer: say so. "I don't know — that's a great question, ping me after and I'll find out." Better than guessing.

For questions designed to trip you up (rare but happens): respond directly to the question's substance, not its form. Don't get drawn into argument. Answer the legitimate version of the question and move on.

If there are no questions, that's a sign the talk was either complete (rare) or unclear (common). Be ready to seed a question yourself: "A question I often get is..."

After the Talk

Hang out at the speaker's lounge or in the hallway. Developers will approach. They want to ask follow-up questions, share related experiences, exchange contacts. This is where the talk earns its long-tail value — the relationships you build after the talk are often more valuable than the talk itself.

Post the slides and any code samples within 24 hours. People who saw the talk want to share with their team; people who didn't want to learn what was missed. Slides on a public URL, code samples on GitHub, link tweet/post within the day.

If the talk is recorded, the recording will be online weeks later. Engage with comments and discussion when it lands. The video has a long tail.

Practice and Rehearsal

Most great conference talks have been rehearsed 10–20 times. The first three rehearsals are awful; you find the gaps. By rehearsal 10, the timing is right; the transitions are smooth. By rehearsal 15, you can deliver while distracted; the talk is in muscle memory.

Rehearse:

• Out loud. Reading silently to yourself does not count.
• To time. Use a timer.
• In the same physical configuration as the talk. Standing, walking, with the slides on a projector if possible.
• In front of someone. A colleague, a friend, anyone. Solo rehearsal misses what's confusing.

The night before, rehearse once. The morning of, don't rehearse — rest your voice and your mind. The talk is in muscle memory; trust the practice.

The Recording's Long Life

Conference talk recordings live on YouTube for years. The talk you give in 2026 is being watched by developers in 2030. Plan for that.

Implications:

• Avoid timestamps that age. "Last week we shipped" becomes "in some unknown past we shipped" by 2030. Specific dates ("in April 2026") age better.
• Avoid product features that change. "Our pricing model includes" becomes wrong. Avoid or note the date.
• Talks about durable patterns age well. Talks about specific products age poorly. Lean toward patterns.

The recording is your portfolio. Treat the talk as a permanent artifact.

Anti-Patterns

Sales pitch. The talk is a 30-minute commercial for the product. Audience tunes out and resents being sold to.

Slide-heavy. Speaker reads the slides. Audience reads the slides faster. Disengagement is total.

Live demo without backup. Demo fails on stage; speaker scrambles; the talk's momentum is lost. Always have a recording.

Running long. 35-minute talk in a 25-minute slot. Closing — the part the audience remembers — gets cut. Rehearse to time.

No story. A list of slides without an arc. Audience can't follow why each slide matters.

Not rehearsed. First time the speaker delivers it is on stage. Pacing is off; transitions are bumpy; the talk lands at 60% of its potential.