Amey-Thakur 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
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.