I’ve written quite a few talks over the years, but usually as a side-line to my day job. In my role as a Developer Advocate, talks are part of What I Do, and so I can dedicate more time to it. A lot of the talks I’ve done previously have evolved through numerous iterations, and with a new talk to deliver for the "Spring Season" of conferences, I thought it would be interesting to track what it took from concept to actual delivery.

tl;dr 🔗

Deadlines focus the mind. Once there was a fire lit under my arse it took a nett total of five solid days to prepare, covering both slides and rehearsing the content.

I can guarantee you now though: if you gave me five consecutive days in which to write another talk for delivery at a later date, no way it would happen.

A step-by-step guide to preparing a talk 🔗

  1. 🤡 Procrastinate. If the talk isn’t this month, then I can worry about it next month.

  2. 🤔 Worry. Hmm, the talk is this month.

  3. 😧 Freak out. Oh shit, it’s in two weeks.

  4. 😳 I guess we should crack on and get this thing done

  5. 🚀 Blast off!

Below I track the cumulative (nett) time spent, and how that was spread out over calendar days (starting from 'launch')

T plus 05 (nett: Day One) 🔗

This "day" was spread over five, starting with when I realised quite how soon the talk was. Spreading it out over time was useful to get the perspective on the stuff I was reading—perspective that you only really get from stepping back and mulling things over whilst in the shower, out for a run, etc.

  1. Re-read the abstract, remember what I’d promised the audience to impart to them. Feel smug that I also made notes to myself at the time as to the general structure of the talk

  2. Start re-reading articles that are relevant to the topic, past blogs that I’ve written. Make copious notes on all the millions of details that I’ll have to leave out.

  3. Start to warm up the idea, feel a nebulous forming of concepts and points

  4. Time for the pen + paper! My handwriting has always been bad and in 20 years of IT has just got worse and worse. But pen + paper is somehow more liberating for getting ideas and thoughts out that a note-taking program. Start to scribble out a top-level outline and fill in some general points underneath.

    IMG 8365

  5. SQUIRREL! Wouldn’t it be cool if I build a demo that does… disappear off down a rabbit warren of random tools and technologies and data sources that I could build in a demo.

  6. Use Keynote outline mode to start to collate ideas. Very rough, indent levels just to group thoughts. At last, I have a .KEY file I can save and reopen and feel like I’ve got the starting of a talk

    2019 02 18 09 51 23

  7. SQUIRREL! Maybe Keynote isn’t the best tool. I mean, I prefer asciidoc for all my document writing, maybe I should look at x y z text-based presentation/slide software.

T plus 08 (nett: Day Two) 🔗

This was after a weekend break, and was just a single day—with the inevitable Twitter breaks:

  1. The talk has been going around my head during the weekend. I’ve got a broad feeling for how much I can cover in the time. Time… good point.

    How long did I say this would be? Some conferences are 40, some 50, some 60! Turns out this first iteration is … 30. Shit. Next one at which I’ll be delivering it is 40, so write the material and figure out as it takes shape which bits get left out as required.

  2. Review the outline I did in Keynote; restructure it a bit and tag each bit with a general story arc to help with order and figuring out what fits. Quite happy with the general message at this stage.

  3. Add in notes taken whilst reading background articles to talk outline. Conscious that the scope is starting to broaden; it’s becoming an "everything I know about event stream platforms and why you should too" and not the focussed data-engineer talk that it was originally. More material to cut is fine but needs to keep the focus.

  4. Test Run #1. Deliberately not ready yet, but forces you to check the flow and if it makes sense, also timings. Turns out I already have WAAY more than 30 minutes. And also that some of it needs rearranging already. Made perfect sense on the screen, sounded like confusing nonsense when spoken out loud

  5. Refine content based on the first test run

  6. Test Run #2. I’m starting to iron out more kinks in the opening argument. Opening bit is too long though. Telling people how bad their world is currently is useful to set the scene and give them an anchor point to which they can relate, but labouring it is missing the point of why they’re there—to find out how much better their life could be.

    Main 'pitch' works but misses key argument thread throughout. Too woolly; what’s the point I’m trying to get across?

Test Runs 🔗

🗣 An important point—for me—on the test runs is that they are out loud.

I’ve learnt from experience that a presentation can make perfect sense as a sequence of slides, even in your mind, but it’s only with the words tumbling from your mouth that you really understand (a) what the heck you’re going to actually say and (b) if it makes any sense. You also develop arguments much more clearly and get a feel for where dialogue naturally wants to go—which can really trip you up if you don’t do this beforehand, as you’ll find yourself ad-libbing on stage with what seems to make sense, and then getting way off track from what you have in your slides. Ad-lib is good but only if you don’t end up lost and flailing.

Delivering a talk, speaking out loud, feels to me like what I imagine jumping out of an aeroplane would do. Suddenly you can’t just coast along pretending that you know your talk but actually don’t. You have to sink or swim (or fly; the analogy breaks down here). It’s like in Looney Tunes when they run off a cliff and suspend in mid-air; if they look down they plummet to the ground.

If all you do is polish slides and create witty meme captions, but don’t practise, then you risk being that presenter who reads their slides to the audience.

For the initial test runs, I’ll use a stopwatch, and pause it to make notes as I go if I really need to. Later on, I’ll be stricter and not stop even if it feels like I need to fix something. It’s too tempting to tweak as you go, and you lose the benefit of rehearsing the delivery of the talk. I had a music teacher once who taught me that if you stop every time you make a mistake when you’re playing something, all you do is teach yourself to stop when you make a mistake—when what you really need to practice is recovering from that mistake and carrying on without breaking your flow. And you know what, most of the time the audience won’t even notice either—unless, of course, you stop.

T plus 09 (nett: Day Three) 🔗

  1. Timebox like f**k. Set a time at which you’re going to do the next dry run and stick to it. Forces you to avoid rabbit holes, and keeps you honest in rehearsing your talk.

  2. Test Run #3 and #4. Recorded (Screenflow/Camtasia) #4 with no stopping. Timing is just over 30 minutes. Recording is useful to review timings afterwards, as well as be brutally critical of yourself in listening to it back.

  3. Putting slides together now, cutting out notes, transferring to presenter notes on slides.

It’s worth being clear that at this stage the slides themselves are a pile of crap, just lots of bullet points from the notes I made. All the effort so far has been on figuring out the content. Probably for a more technical talk, and/or one with live coding, I’d be spending more time at the keyboard on the technical content.

T plus 10 (nett: Day Four) 🔗

  1. Start trawling unsplash et al for images to put on slides. Moving from narrative to thinking how each slide will support what I’m saying

Three solid days spent this week. Slides order is set, half the diagrams are drawn, the rest will happen on next working day (Monday). If I HAD to deliver this tomorrow, I could—but I’d not be happy with the slides.

T plus 14 (nett: Day Five) 🔗

This was after a long four-day weekend spent away with the family. Mostly forgot about the talk which was nice. Had intended to sketch out slide diagrams in spare time but didn’t.

Today I want to finish the talk so that I can take tomorrow off with the family. The conference is the day after so it’s a hard deadline. Things expand to fill the time.

Did Test Run #5 and #6 (beginning and end of the day)

Spent all day preparing diagrams. A chunk of the talk is about concepts and patterns, and need diagrams to communicate clearly. I sketch these on paper (to avoid distraction of 'implementation' on the iPad) and then transfer to iPad after.

IMG 0200

T plus 15 🔗

Took PTO and went to the beach with my family :)

DSCF2580

T plus 16 🔗

Day of the conference!

✈️ On the flight there I did a bit of slide polishing (and I mean polishing; aligning image credit text across slides etc).

⏱ Timing was bang-on: 29:15 for a 30:00 time slot

🎉 The talk seemed to go down well. The audience looked generally engaged and interested, took pictures of the slides etc.

You can download the slides from my talks site

2019 03 01 22 49 35