I recently gave a talk to my colleagues about giving talks. Here is an annotated collection of the notes I made in preparation.
- What do you want the audience to get out of the talk?
As you’re constructing your talk, ensure that you’re actually satisfying your mission. If you want to inspire people, make sure you’re not just promoting your own knowledge, business or ability. If you want people to learn things, make sure your talk is appropriate to the experience level of the audience.
- Find out about the audience
- likely skill level
- range of experiences
- interest in technical, business or other issues
- Don't assume that because you think something's obvious, everyone else does
A big stumbling block for novice speakers I talk to is to assume that because you know something, it’s not worth talking about as there are people out there who know way more. Your own experiences and interpretations are different from everyone else’s, it’s very likely that you’ll have something new to contribute—as long as your talk is personal, and not just a restatement of readily-available documentation.
- Decide what it is you're going to say
- are you trying to inspire or persuade the audience?
- decide your conclusion
- if you're worried about timing, give yourself a couple of different exit points
- how do you want to start?
- the conclusion's a good place to start
This is a tough place to start though. The idea is that you’re challenging the audience by telling them something that sounds implausible, so they get mentally engaged. If the leap required is too big then you’ll either turn people off, or they’ll still be thinking about the challenge after you’ve started talking.
- outline the problem that your solution solves
This is the Jobs approach. Start by saying the current world sucks. Explain what a better world would look like. Make it obvious that your proposal leads to the better world. Tell them the thing you propose is available in the foyer as soon as the talk finishes. It’s based on setting up one or more distinctions between the world as it is (or as you tell the audience they currently perceive it) and as it could be (or as you tell the audience they should want it), then showing that those distinctions have actually been resolved. Nancy Duarte did a good talk on this topic.
- what's the flow between the problem and the conclusion?
- notice this isn't "tell them what you're about to tell them…"
- are you trying to educate the audience?
- you can't in under an hour; aim for awareness or persuasion
- put additional relevant content on your blog and refer to it
- you still need a flow
In this case, the audience’s problem is “we don’t know how to do [x]”, the better world is one where they do know how to do [x], and the solution is your content. Don’t try to cram all the code into your talk because it’s distracting, only relevant in a few cases, and hard to parse while keeping up with the presentation. Instead, give people the key parts of the solution so that when they come across [x], they’ll remember some things from your presentation which will help them piece together the full solution.
We had a discussion about WWDC talks at this point in the “live” version of these notes. WWDC seems to provide a counterexample to this rule about not educating people in a talk, with graphics-poor code-rich presentations. Those sessions have two goals: giving developers who aren’t in the labs something to do, and being available on video afterward. The live presentation frankly is overwhelming and often confusing, but isn’t the main use of the talk. You’re expected to watch it over, to refer to the documentation, to ask people about the content in the labs.
[To be honest I also expect there’s an extent to which a lot of the people presenting at WWDC are both strongly pressured by the additional workload of the conference and are uncomfortable with speaking publicly, and the format they’ve settled on is one that works in that context and doesn’t make too many compromises or create too much additional stress. That’s just speculation on my part though.]
- entertainment
- doesn't need to be jokes, a compelling talk is entertaining
- in fact be careful of jokes unless you know the crowd
- certainly don't lead the laughter
I put this in as a homage to Thorsten Heins, who ruined an otherwise reasonably competent and well-executed presentation by laughing at and even applauding his own jokes. If you want to try a joke, think twice. I only do it in arenas where I’m comfortable I know the people. If you still want to do it, and it falls flat, move on.
- if you want a set piece, make it relevant to the talk and practice the bejeezus out of it
- engage the audience
- "hands up if" exercises are light forms of interaction but make people engage with the talk
As discussed earlier, making people too introspective will distract them from your talk. But these days you have to stop people from diving back into their laptops and working during talks, so you need to provide some form of engagement. You also have to deal with the fact that various sub-sections of your audience may be jet lagged, full of lunch or hungover. If they don’t have a part to play in your talk they’ll sleep through it.
- make eye contact with every part of the audience
- you will see people asleep or working; don't worry
- don't forget the back of the room
It’s easy for introverts particularly to “protect” ourselves from the audience by avoiding looking at them. The problem is it then doesn’t feel like we’re talking to everyone out there. You shouldn’t aim to make eye contact with every individual attendee, that doesn’t scale—you definitely should talk to each “part” of the audience though. Talking to someone at the back of the room when you start your talk helps you pitch your voice correctly.
- motion, nervous or otherwise, gives people a reason to be concentrating on you rather than the screen/their phones
- slides
- too much text and you lose people while they read along
- again, relevant content
- animation where relevant helps, where irrelevant distracts
- progressive disclosure and hiding
So much has been said about building good slides that I don’t want to add anything. Make sure your own notes are separate from your slides, and everything on-screen now is germane to what you’re saying now.
- q&a
- there will be an awkward question. Your goal is to handle it gracefully, not to avoid it coming up
- continuum fallacy
Most of the “well actually” questions you’ll get in conference Q&As are not actually questions. They’re the phrase “I know more than you” dressed up with some rhetorical sugar to appear more question-like. These are poisonous: the audience gains nothing from them, you gain nothing from them, the person “asking” gains nothing from them. Nonetheless we can’t ban people who ask these questions from conferences, so we just have to cope with them. “That’s an interesting point, we should talk about it later” is an OK response—especially if you need to catch the train as soon as you’re off the stage.
The ones that are questions frequently represent instances of the continuum fallacy: you said X is true. Well actually I’ve found an edge case where X isn’t true, therefore X is never true. No. Politely point out the fallacious reasoning, move on to another question. The biggest mistake I make in handling Q&A is letting people argue the toss over questions like these. Again, the rest of the audience is learning nothing from a pointless to and fro; and there are more of them than the two of you having the discussion.
- set expectations on questions at the beginning, e.g. "I'll take questions at the end" or "interruptions welcome". "No questions" is hard to get the conference organisers to agree with (though would probably help a lot of nervous speakers)—filibustering sometimes works but is apparently rude :)
- you're effectively chairing a discussion you're also involved in, so don't be afraid of setting topic boundaries. The q&a has to be valuable to the audience.
