How I write talks

I recently delivered a talk called Fallible Humans at DevOps Days Minneapolis, which was well received. Although I’ve spoken in front of audiences before—internally at Etsy, at local meetups, student groups, etc.—this was my first “proper” conference delivering a prepared talk.

In one of the afternoon Open Spaces, we discussed the topic of “Public Speaking For Beginners”, and I discussed my approach to writing, preparing, and delivering my talk and I thought it might be useful to document it here too.

In the past I’ve always been a “slides first” writer: I’ve had an idea of the story to tell, and my work begins by opening up Keynote and adding slides around which I wrap words. However, last year I ran an internal Ignite night at Etsy and found that this approach failed horribly for the Ignite format. Because you’re so constrained by the fixed duration of each slide, if you write your slides first you are compelled to talk (or have awkward silences) to suit each slide and if you make the wrong decisions it pulls the pacing of the talk awry.

As a result, I’ve been trying to be a “prose first” writer, and this worked very well for my DevOps Days talk. Essentially, I began with an essay. (For Ignites, I suggested to speakers to begin with an anecdote such as you might tell at a party.) What this allowed me to do was to concentrate on telling a story and expressing my ideas without the constraints of slides and transitions. What was the message I actually wanted to get across? What was the best way to tell the story? Were there any particular turns of phrase that were pleasing or memorable?

As I look back, I realise that I had subconsciously chosen to use the structure of the three-act play: exposition, development, resolution. I wouldn’t necessarily advise forcing yourself to use that structure, but talks and presentations do have performance and dramatic elements to them, and the parallels to plays and storytelling are useful things to consider. In my case, it ended up boiling down to “What is blame?”, “Why do we blame?”, and “How are we going to make things better?”.

The talk didn’t start to gel in my head until I had a “hook”—a particular, catchy idea to get things started. I had casually used the word “scapegoat” in my talk’s subtitle when I proposed it, but one morning I woke up thinking “talk about the history of the word ‘scapegoat’ first”, and then I had something to get the ball rolling. Reading up on the history of the word then made me think “it sucked to be a goat” and there, really, was the hook: we can empathise with the goat, draw an immediate parallel to our own situation, and it can get a laugh. With the hook, a little bit of historical research, the background reading I’d already done, and the stage-setting I’d done in my proposal, the actual words for the first act flowed fairly freely.

I then hit a wall, not having consciously expressed my intention to do a “what, why, how” approach. I knew I’d run out of things to talk about but didn’t know where to go next. (The next talk I do will probably involve more conscious structuring….)

I did know that I wanted my talk to be practical. Particularly with the genre of “technical culture talks” it’s very easy to talk about philosophy and generalities without giving concrete advice on what to do about it, leaving the audience feeling a little adrift. It made intuitive sense that this should go towards the end: the end of your talk should leave people wanting to stand up, head to work, and get cracking. I decided that if I had the beginning sorted, I could work on the end, and see what (if anything) was missing in the middle.

When dealing with technical incident reviews, we refer to SMART criteria—Specific, Measurable, Achievable, Relevant, Time-bound—when coming up with remediation items. These can be a useful tool for reviewing advice you may give in a talk too (although “time-bound” depends rather on how the audience might take up your advice). I tried to think of just a few basic principles, since I only had half an hour in total for the talk, and there’s only so much people can take in at once before they start to tune out everything you say. Each principle then got some explanation, ideally with a concrete example or reference to back it up.

Each time I had a reasonable chunk of text written but had hit a wall, I’d do a run through with a stopwatch to see how I was doing for time. This both gave me an idea of how much room I had left and helped me get a feel for how what I’d written actually flowed in practice and what needed adjusting. Usually the next thing I needed to say would come to me as I reached the gap I’d left.

In hindsight, obsessing over time was a mistake. I think it’s generally better to complete your draft before timing it, so that you’re not tempted to edit before you’re done if you go over time. You’ll have a better sense of what can be trimmed when you have everything in front of you. I was lucky that I hit 28 minutes of good talking on the first draft and didn’t need to cut anything.

Once I was happy with the talk in essay form, I opened Keynote and began to work through my slides. I generally stick to the idea that you should have as few words as possible on each slide. A transition to a new slide is a moment for the audience to read, orient themselves for the next segment, and then return to listening to what I’m saying. (As an added advantage, in the age of live-tweeting talks short phrases can also help provide ready-made tweets that fit nicely within the 140 character limit. If you want to go all-in on the Twitter thing, you can follow the example of Lara Swanson and auto-tweet from your presentation.) I’ll sometimes add sub-headings or highlight pithy sentences when writing the initial essay if they seem to suggest good slide content; beyond that it’s just a case of seeing where the natural breaks, pauses, and subject shifts occur.

I don’t read off the slide, although the words there may well be echoed in what I’m saying. The main time I violate that rule is for quotes. Good quotes and citations can anchor sections of the talk, and the words are usually important. Having them on the slide, and reading them as part of talk, reinforces their importance (and allows you to stress particular parts if you wish). The trick is to only transition to the slide at the point where you’re ready to read it, so that you’re reading with the audience. If you transition too early, they’ll be reading (and not listening) while you’re talking about something else, then bored when you read it to them.

I find reading prepared text verbatim, either from note cards in hand or from notes on a slide, results in my delivery becoming stilted and awkward. For each slide, I took the relevant text from the essay and broke it into a few bullet points. These went into the speaker notes for the slide to act as an aide-mémoire. I didn’t try to memorise the essay word-for-word (since that doesn’t leave much room for flexibility) but rather to know the material well enough that I could talk fluently and be sure to cover all the necessary information. With the speaker notes, I could relax knowing I’d still have pointers to remind me of the salient points I wanted to cover to which I could refer if I suddenly got lost mid-slide.

Slide and notes done, I did a complete run through with the speaker notes visible and my essay next to it so I could refer to it if (well, when) I forgot what I intended to say. With that experience, I could adjust the notes and slides and do a run through without the essay to guide me. Further runs were a matter of satisfying myself that any time I went astray, I could recover. (As with engineering, it’s all about minimising the cost of failure….)

Once I felt fairly fluent, I recorded a demo version. This allowed me to export a video of it, which I could then watch and review. (For me, it takes some effort to listen to myself talk, but it’s very valuable for improving my delivery.) I could also upload it to Dropbox and share with people I hoped would review it. (One of the many advantages of working at Etsy is having a large number of colleagues who are experienced presenters, have a deep knowledge of your subject, or quite often both.) I got some useful feedback, updated the slides, and called it good.

My original plan, having about four or five weeks between having my talk accepted and the actual conference, was to write early and have plenty of time to rehearse and gain confidence. It turns out that words will only come out of my brain and take written form when squeezed out by the pressure of a looming deadline, so I ended up finishing with about two days left. This at least meant that the material was fresh in my mind.

On the first day of the conference, I was fortunate to have lunch (and a very engaging discussion) with Patrick Debois. His advice, when we discussed about my talk for the next day, was to chat to people at the conference and be willing and able to tweak my content if interesting ideas emerged. As it happened, someone proposed an Open Space that afternoon on blameless postmortems, and I was able to get some useful ideas from there which I could incorporate.

The talk itself was something of a blur. Some tips, though:

• Turn off notifications. There’s nothing quite like an IM notification popping up on screen in the middle of your talk.
• Do without wifi. Even better than turning off notifications is blocking out the outside world entirely. Given the famously patchy nature of conference wifi networks, and the vagaries of tethered mobile services, where possible it’s best to have your material on your computer, and be able perform without subjecting yourself to these extra sources of failure.
• Clean up your desktop. I recall one speaker at a different conference accidentally revealing some secret clients due to some file names visible when his presentation was closed.
• Use a remote. I use a Targus remote which has served me well. It fits nicely in my hand and having the buttons at my fingertips allows me to let the slide transitions flow smoothly without large, overt physical gestures (like leaning forward to press the spacebar). Since I tend to pace as I talk, this frees me up considerably. It is possible to use a smartphone as a remote, but the one time I tried that the wifi network failed and I was stuck; I’ve used a dedicated device since. I also find my iPhone doesn’t feel as comfortable and forgettable in my hand as my remote.
• Try to avoid pacing. I made the AV crew’s job much harder as they had to do a lot of panning on the close shot for the live stream.
• Have a bottle of water. Not only will you probably find your mouth gets dry as you talk, it provides a useful cover for pauses when you suddenly realise you can’t recall what you were going to say next. And if worst comes to worst, you can choke on the water and get yourself carried off stage.
• At the end, try to remain sufficiently alert to remember to remove your mic. The event’s AV technicians may well collar you and do this for you, but I did manage to forget and be talking to someone after my talk while my mic was switched on. Not quite as bad as going to the toilet while broadcasting, but best avoided.
• Feel free to hide afterwards. Most of the people I’ve spoken to who have done talks say that all they want to do after being on stage is to go somewhere quiet and not see or speak to anyone. There’s plenty of time for people to talk to you once you’ve had a chance to recover.

Talking at DevOps Days Minneapolis was a great experience (as was the entire conference) and I’m definitely looking forward to applying what I’ve learned so far to the next talk I get to give.