Most conference talks by engineers start from a design doc. It has the right content, but in the wrong order and at the wrong depth. The doc's job is to settle a decision for people who already care. The talk has to get a room of strangers to care in the first two minutes.
I build Maildoer, an email assistant that turns attachments into decks, summaries and reports, so I spend a lot of time looking at the briefs people write when they hand a long document to someone else to turn into a deck. This post is about that brief. It works the same whether you hand the doc to a colleague, a tool, or yourself next weekend.
The example below is a labelled hypothetical, not a customer story: say you wrote a 30-page design doc for moving your team's job queue off cron, and a regional meetup has offered you a 20-minute slot.
Why "make this into a talk" gets a bad first draft
If the brief is just the PDF and "turn this into slides", you get the doc's table of contents as bullet points. Every section gets a slide, and the alternatives-considered appendix ends up taking a third of the time. It's faithful, and it's boring to sit through.
What's missing are the decisions only you can make:
- Who is in the room. Meetup generalists need the problem before the queue semantics.
- What they should leave with. One idea they can use at work on Monday, not the full migration plan.
- What to cut. Internal names, the capacity tables, the three alternatives you rejected in week one.
- Hard limits. Slot length, whether live demos are allowed, whether the slides will be shared afterwards.
The brief
Here's the email I'd write. The structure matters more than the wording.
Subject: 20-min meetup talk from the attached design doc Attached: job-queue-design-v4.pdf (30 pages) Audience: backend generalists at a local meetup. Most run cron jobs; few have run a queue in production. Goal: they leave knowing when cron stops being enough and the three questions to ask before replacing it. Length: 20 minutes, about 12 slides. No live demo (venue Wi-Fi). Keep: the incident that started it (section 2), the "retries vs. idempotency" diagram (section 5), the rollout lessons (section 9). Cut: internal service names, capacity tables, appendix B. Output: slide outline with speaker notes, then a draft deck. Tone: plain, a bit self-deprecating about the incident. Three things in there do most of the work:
- "Keep" and "Cut" name sections. That is what turns a summary into an edit. Without them, every section gets the same weight.
- The goal is a sentence the audience could repeat. If you can't write it, the talk isn't ready to outline yet.
- Constraints are written as facts. "No live demo (venue Wi-Fi)" also explains why, so it still applies when the plan changes.
The second email is where it gets interesting
A week later the organiser writes back: two speakers dropped out, your slot is now 15 minutes, and they'd like you to open the evening.
The lazy follow-up is "make it 15 minutes". If whoever is helping you only sees that sentence, they'll shave every slide evenly, and you'll lose the incident story, which is the best part.
The follow-up I'd actually send is short, because it leans on everything already agreed:
Slot is now 15 minutes and we're opening the night. Same audience and goal as before. Keep the incident and the diagram; drop the rollout lessons to one slide. Opening slot, so add a 30-second "why you should care" at the start. That email only works if the reader remembers the first one: the audience, the no-demo rule, which sections were "keep", and the tone. This is the part I care most about in Maildoer. A follow-up from the same person is read together with their earlier emails, so "same audience and goal as before" means something, and the original PDF and instructions are still in play without being re-sent. You can also just reply to the deck you got back and say what to change.
Whatever you use, the habit holds: write the first brief so a second, three-line email can build on it. Name things ("the incident", "the diagram") so you can refer to them later.
A checklist before you hit send
- One sentence the audience should leave with
- Audience described by what they already do, not by job title
- Slot length and approximate slide count
- Sections to keep and to cut, by number or heading
- Constraints with their reason (no demo because Wi-Fi)
- What you want back first: an outline before a full deck saves a round trip
- Tone, in one phrase
What I'd do differently
The first time I tried this on one of my own docs, I asked for the full deck straight away. The structure was fine, but I rewrote half the speaker notes, because I hadn't said whose voice they should be in. Now I ask for the outline and notes first, fix the order, and only then ask for slides. The outline round is cheap, and every correction made there carries into the deck.
I'd also keep the original design doc in the thread instead of attaching a trimmed copy. A trimmed doc loses the context that explains why a section was cut, and that context is what makes the later "drop X to one slide" emails clear.
Here's an illustrative sample of the kind of slide that comes back (demo data from a sample deck, not anyone's real work):
How do you decide what to cut when a long doc has to become a short talk: by section, or by starting from the one sentence and working backwards?
Want to test the brief above? Send it with your own doc to do@maildoer.com. 100 credits come with your first email. https://maildoer.com
