This is the third in a series of posts about giving a tech talk. The first post covered the length of talk a first-time speaker might choose, the second post covered selection of topic. For this post I asked a number of experienced speakers how they prepare their talks.
Paul Fenwick (PJF) said:
Well before I write a talk, I'm usually preparing references for it. Zotero is amazing here; I never knew I needed citation management software until I found it, and now it's one of my most heavily used tools.
Before I work on slides, I usually map out "story arcs" using a mind-mapping tool like freemind, under a big branch I've got called "My Talks". This lets me figure out the broad things I want to discuss, and break those down into sub-topics and eventually point that become individual slides.
The slides themselves are done in pinpoint, which is a presentation tool that uses text-based input. For a developer who spends all their time in an editor and using git, it's perfect. I've written my own pre-processor (App::Pinpp) that lets me keep each story arc in its own file, which makes managing the talk much easier, and means I can include or exclude arcs before going on stage, depending on my allocated talk length. Pinpoint lets me put in speaker notes just by starting lines with a hash (#), and I'll put in any citations I'm using there, as well as any salient points I need to remember.
Usually at this stage I'm thinking about the words I'm going to say with each slide. I'm a big fan of the Lessig method, to have just a big word or picture on each slide, so I'm not splitting the audience's attention between what I'm saying and what's on the screen. I'll often speak out loud to see how things sound, pace around, write down more slides and notes. Just like when coding, I'll try to commit often after completing significant sections.
Finally, I'll start a timer and try running the whole thing through from start to finish. Usually I'll find lots of things I'll want to adjust here, so I'll be starting and stopping the timer regularly as I adjust both my slides and my oration.
These practice runs repeat until I'm no longer making changes on each pass, at which point the presentation I'm giving to my bedside lamp is likely to be the same one I'm giving to the conference.
One thing I really appreciate is when I'm lucky enough to find someone I can practice on and ask for feedback. It's nice if they're an accomplished speaker themselves, as they'll have a better grasp or what will and won't work in front of an audience, but honestly anyone is good here. They'll spot whenever you've assumed knowledge in the audience (which is easy in tech talks) or other improvements you might be able to make.
Stevan Little (STEVAN):
First I do a couple of outlining/brainstorming sessions, mostly just to organize my thoughts because I rarely use them to actually build the slides themselves.
Then I start building some very (and I mean VERY) rough slides, usually nothing more than the key points I want to cover. From here I will just start refining the narrative I wish to convey, sometimes getting preoccupied with visual and/or jokes, but mostly it is just a constant loop of refine, refine, refine.
If you want, you could think of it like sculpting in clay. At first it looks like nothing more than a lump of clay, then slowly as I work something starts to take shape. Occasionally I need to add some clay, to maybe reinforce a point or something, and sometimes I need to remove some clay, usually because I have wandered off on a tangent that is not really adding to the overall narrative.
Then towards the end, I will spend time just polishing details and re-reading and often re-writing speaker notes until the narrative feels good and I feel comfortable presenting. In some cases I will do this up until the very last moment, but not always.
This sort of depends on what sort of talk it is, and various little things like: do I know where I want to end up? Do I know where I want to start? Are there particular points I want to go through on the way from the start to the finish? For something like a "I learned this thing and I'm going to tell you about it" talk, it's pretty straightforward; for something like a keynote or a "message" talk, it can get kind of complicated and involve a lot of long walks, staring off into space, and starting over. And over.
At some point, regardless of the type of talk, I'll get to the point where I start drafting an outline, usually on paper. At some point before that's all the way completed — probably when it's 50 or 60% done — I'll switch over to making slides (I generally use Keynote for that). Depending on just how gnarly things get, I'll either finish out the slides and then go back and add in images and tweak and rearrange, or I'll decide the whole thing sucks and go back to the long walks and sighing at the ceiling phase.
Eventually I'll end up with a slide deck I don't totally hate, and then I'll run through it once or twice or 10 times (it just depends), generally adding at least a few words to a few lines of speaker notes to each slide. The struggle for me at this point is to know the material well enough to give the talk in a relaxed way, but not have it memorized to the extent that I'm bored with it. Because if I'm bored with it, I'm probably going to seem bored when I'm giving the talk, and that's a crap way to present, really.
For a "major" talk, like a keynote or if I'm going to say something that might be controversial, I'll probably circulate the slide deck amongst a few trusted friends to get some feedback. For "normal" talks, I generally don't do that.
It varies by subject matter, and I'm currently actively evolving my slide-writing process and style, but there still are some preparation elements which are common across all of my talks.
First I will typically do some sort of mind mapping. Lately my tool of choice for that is MindNode, but sometimes it's just me scrawling in my Moleskine. The main goal is to give myself permission to write anything in any order for any reason, totally unstructured. Once I've done the brain dump, I usually set it aside for a day or two to let my mind stew on it for a bit.
Next it's time to organize those thoughts (and usually augment them with others which have occurred to me in the meantime). That may be in my mind mapping software, or it may be by writing each idea on an index card and then arranging those into columns. Either way, this forms the basis for the next step: writing the outline. The outline is usually what I use as the basis for my slides. As I mentioned above, the process I use for writing my slides is currently in flux, so I won't go into those details.
At some point during the process I'll often open a Trello board for the talk to help me track items I'd like to add or change but can't at that moment for some reason. I also use the Trello board to capture feedback I receive from audience members so I can make sure I integrate it into future versions of the talk.
Curtis Poe (OVID):
I usually take a few notes on things I'd like to see in the talk (major concepts, key technical points) and just start writing slides. From there, I start speaking them to see how they sound. Even if I only have ten slides for an hour long talk, I start like that and quickly I start to see new points I need to raise (more slides!), and points I need to alter and just like an Agile project, the structure of my talk evolves. I'll usually start researching from finer points at this time, add and remove slides, and start speaking again.
I'll do this over a course of many nights until eventually I have a slide deck I've worked through many, many times and have my transitions and concepts perfect.
I used to do about 20 different talks a year, but I realized that's just too much to prepare, especially with growing responsibilities. Nowadays I prepare one or two and try to stick with them for the entire year, somewhat successfully.
Most talks have a similar timeline for me. I'll usually pick a topic and let it soak in my head for a while. That can be a week or two or three. Then I'll outline the basic principle. "What do I want to say about it?", "Why is this interesting?", "What is the interesting thing about it?", "What's the angle I want to present?". I'll try to figure out what kind of talk it will be. Is it funny, is it a tutorial style, is it a short or long talk. I prefer to give short talks, when possible. They're easier to prepare.
I then draw out the basic story outline (beginning - introduction, middle - the core, end - the conclusion) while making along the way regarding how to present a specific topic, possible examples, and jokes I can include (do you really think all jokes are spontaneous? Nope!). I then write it down and refine it over and over and over.
Writing a proper talk can take between a week to a month. Sometimes it flows and I'll do most of it within a day, especially when it's a simple topic that comes naturally.
I also refine every time I give the talk. I make notes of what jokes worked, what examples people needed more time with. It reminds me of the process of writing comedy. It's a continuous process.
Do you have a couple of hours?
- Because it's complicated
- And elaborate
- And detailed :-)
Actually, if you do have a couple of hours you can learn quite a lot about my approach to preparing a talk from:
Rik Signes (RJBS):
First, I think of an idea. Then, I think about it for a while, wondering what points I'd cover, and especially what the narrative structure would be. It needs to have a beginning and an end, and it should have some amount of up and down internally. If I realize that it's just going to be a walk through the documentation (either literally or in effect) then it's scrapped. Similarly, if I think it's really interesting, but nobody else is going to care, or if I don't have enough expertise to talk about a topic that I find interesting as a lay observer, I skip it.
If I get past that, I start in OmniOutliner. I make a list of points to hit, which I re-arrange as I work. If I have specific examples or anecdotes to include, I make a note as I go. Similarly, things that I need to learn more about before doing the talk.
Once that's done, I don't do anything for a long time because I am avoiding work. Eventually, I can't do that any more and I fire up Keynote and start making slides in order. Then I go back and work through the slides a bunch of times until they make sense in order. Sometimes, I find that the topic is too complex to explain, so I change the underlying code to be simpler, or maybe write an abstraction over it to present instead.
When that's done, I run through the talk in rehearsal mode at a leisurely pace, saying things out loud. That usually shows off problems, or awkward transitions, or places where I should add notes to myself in the presenter notes.
If I'm really on the ball, I'll do a timing run, where I do the talk from the top, not stopping at all, and try to hit my time mark exactly. This is important, and it is even more important when you don't have a good sense for your own pace, or the ability to run long without displacing anyone (I usually get myself scheduled before a break).
I started trying to distil their advice down into a concise process, but decided to save that for another day.
I think the most important point is that your presentation should have a clear narrative arc: a clear story that you tell. Better to leave points that that don't fit in; save them for possibly another talk, rather than derail your current one.
And I can definitely recommend watching the talk that Damian referenced.
comments powered by Disqus