How I write tech talks
A few people have asked me recently about writing talks, so I thought I'd document my process.
I only write technical talks, so keep in mind that some of this advice may not apply for your talk.
Goals
I have two goals in mind for any talk:
- Convey information.
- Keep audience attention.
You need both to give a successful talk, otherwise the audience won't learn anything.
Process
My process for writing talks is similar to how teachers taught you to write essays in school.
Write a thesis. A clear, simple thesis will help guide the content of your talk. Focus on what the audience will get out of listening.
Research. Gather any information relevant to the thesis. Don't worry about form or structure - focus on surveying any possible topics to cover.
Outline. Take all that information and arrange it roughly in the order you want to talk about it. Don't worry about polish yet - often times I have slides that just say "diagram of X" or "code sample Y".
Rehearse. Give the talk as if the slides were finished. You will discover all sorts of problems with your initial outline: confusing explanations that are out of order, slides that were unnecessarily redundant, or information that you forgot to include.
Even a single rehearsal makes a big difference in talk quality. It's like testing your code before pushing it to prod. Some presenters can get away with winging it, but not me.
Polish. Fix all the problems you discovered in rehearsal. Fill in "todos" with actual diagrams and code. Finalize the slide content.
Repeat. Do a rehearse/polish loop until you feel comfortable with the talk.
It can take me up to ~20 hours per talk I write, depending on talk length and my familiarity with the topic.
Slide Tips
Use as few words as possible on slides. It's called a "talk", not a "read." If the audience could get all the content from just the slides alone, what's the point of you being up there?
Take advantage of the medium. Use text to emphasize major points but use your voice to elaborate.
Minimize your code samples. Similar to minimizing words but even more important because it is harder than you think for an audience to follow code snippets. As such, you should show as little code as possible. I use abbreviations ("...") to shorten code samples.
Reveal content incrementally. If you put up a slide with five bullet points, people will read all five at once (and ignore whatever you're saying). If you reveal them one-at-a-time, then people follow along better.
The same applies for code. Either reveal code piece-by-piece or progressively highlight different portions of the code.
Don't worry about making beautiful slides. I use white backgrounds with black text because it takes me long enough to write talks. No one has ever complained that my slides were too plain.
If you want to make your slides pretty, by all means go ahead, but it's not essential.
Pet Peeves
Skip your résumé, especially at the start of your talk. Sorry to break it to you, but the audience doesn't care. All you're doing when droning on about your life is wasting time, losing audience focus and making yourself look narcissistic.
A brief self-introduction is all you need: "Hello, my name is Dan, and I work on the Android team at Trello." At the end of the talk, put up a slide with contact information (email, twitter, etc). That's all you need. If someone wants to know more, now they can contact you later.
Don't overwhelm the audience with too much information at once. You're an expert on the topic but your audience is not. What makes sense to you will fly over the heads of everyone watching.
Slides plastered with words (like long quotes), large complex architecture diagrams, and live coding demos that span hundreds of lines of code - these all seem reasonable when you're familiar with the topic, but they lose the audience in no time. Keep it simple, or take your time explaining it.
Be excited. The way you present almost matters more than the content itself. If you get up on stage and act like a zombie, the audience will get bored and tune out. Instead, get pumped up and excited! People love an animated speaker, or at least one who appears vaguely interested in the topic at hand.
One common way to suck all the air out of your talk is to stick to a script. Scripting tends to lead to "keynote voice," the uncanny valley of speaking. If you need to write a script for practice, go ahead, but you should let go of it before actually presenting.
Shorter is better. Don't draw out your talk for time. If your talk ends up shorter than you expected, then great - have the audience ask questions afterwards.
Getting Started
I recommend starting with a low-stakes environment. An internal talk at your company is a great way to start. Small local meetups are often looking for speakers.
You don't have to start with a detailed, hour-long talk. My first talk was fifteen minutes long. Just five minutes would be fine.
If you're nervous about presenting, remember that audiences want to enjoy your talk. As such, they are more forgiving than you think. Don't be too hard on yourself.
After your talk, watch a recording of it. Yes, this is excruciatingly painful, but if you want to get better you'll have to critique yourself. Learn, improve, repeat.
I tried to keep each point in this post relatively succinct, since it was getting long enough already. If you want me to elaborate on anything, let me know in the Disqus below.