---
name: conference-talks
description: Get talks accepted and deliver them well through audience-first proposals, narrative structure, and rehearsed, demo-safe delivery. Use when proposing or preparing a technical talk.
---

# Conference talks

A talk is a transfer of one idea into a distracted room. Every
decision (proposal, structure, slides, demos) serves that one idea;
everything else is decoration that costs attention.

## Method

1. **Propose the audience's takeaway, not your journey.**
   CFP reviewers select for "what will attendees be able to
   do after": "You will leave knowing how to cut p99 latency
   with three profiling moves" (see systems-profiling for
   that talk) beats "Our migration story". Include the
   concrete outline and why *you* (the scars, the data:
   see incident-postmortem material: great talks live
   there); target the venue's level and check past programs
   for fit.
2. **Structure as problem, journey, resolution.** Open with
   the pain the room recognizes (nod test within two
   minutes), travel through the attempts *including
   failures* (the wrong turns are where credibility and
   learning live), land on the lessons as portable
   principles, not your company's specifics. One idea,
   three supporting points; a talk teaching five things
   teaches none (see six-pager-narrative's ruthless-focus
   sibling).
3. **Design slides as backdrop, not script.** One thought
   per slide, big text, minimal code (four to eight
   highlighted lines, never scrolling files: see
   code-review-comments' excerpt discipline), diagrams
   over bullets (see architecture-diagrams); if a slide
   needs apology ("you probably can't read this"), it
   needs replacement. The audience reads or listens,
   never both.
4. **Rehearse aloud, timed, at least three times.** Full
   run-throughs to a wall, then to a person (see
   design-critique's fresh-eyes value): fix the sections
   where you stumble (stumbles mark unclear thinking, not
   nerves), cut to 90% of the slot (Q&A and overruns eat
   the rest), script only the opening two minutes and the
   closing line: the parts nerves attack first.
5. **Make demos survivable.** Everything local (conference
   wifi is a rite of failure), pre-staged states for each
   step (see script-idempotency's spirit: resumable from
   any point), and a recorded backup video you can
   narrate: the demo gods take the unprepared. If the
   demo is not load-bearing for the one idea, cut it;
   screenshots do not crash.
6. **Deliver to humans, then harvest the compounding.**
   Eyes on real faces (find three friendly ones in
   different sections), pauses over filler, questions
   repeated before answering ("great question about X"
   buys thinking time; "I don't know, find me after" is
   a fine answer: see receiving-feedback's poise).
   Afterward: publish slides and a writeup (see
   technical-writing), note what landed flat for the next
   iteration: one talk, well-documented, feeds a year of
   content (see developer-marketing, promo-packet).

## Boundaries

- Speaking serves your goals (career, hiring, community:
  see mentoring-engineers' sponsorship when nominating
  others), but conference-circuit maximization is its
  own job; decline invitations that repeat your existing
  talk to no new audience.
- Vendor pitches wearing talk costumes burn speaker
  reputation durably; the line is "would this talk be
  useful if my employer vanished tomorrow?"
- Live-coding is a genre choice with a high floor of
  rehearsal (double the runs, half the content); default
  to prepared code you explain unless the coding *is*
  the point.