Making a Talk

I've been asked how I put talks together.

Some are quick and easy, others can be a bit more intensive. If you're interested, pour yourself a non-alcoholic (it is a Monday) G&T and read on. ??

For the G3C - Glasgow Caledonian Cyber Convention talk in November I'm having to dig pretty deep. A lot of the time when I submit for a CfP the idea is very high level. If it gets rejected, I don't want to waste effort so I don't start heavy research until I know I'll be speaking.

This one is probably one of the heaviest I've ever done (including the introduction to information theory).

When I submit a CfP I have an outline in mind as a few mental bullet points. More important, I also know the outcome I want for the talk, and everything builds around that.

The goal this time is to give people a conceptual tool to use - vector space models - when thinking about risk.

Start Small

Going straight to using them for risk is likely going to lose the audience, not because it's beyond them but because for those not familiar with it it's not a grokky idea. I want a concrete example to construct the basics. Since I had a hobby project in the background (constructing cocktail space), that works well.

Then it's the research. A lot of reading, phone calls with people who know a lot more than me (fortunately there's a lot of them and they're almost always happy to talk), and prodding around at tools to construct it.

The research phase I try to keep open ended, in case I find something that invalidates the talk or changes its direction. These things happen.

It's only after I'm comfortable with all the stuff now floating around in my head that I'll go back to the outline, review it and change it if needed, and start putting the detailed structure or the slides together.

Structuring

Approaches vary on this. I start building slides as just a few words and illustrations plain - no design or formatting - based on my outline. Each bullet point becomes a section, and then gets broken down further as needed for the points I need to cover. If more detail is needed, those points get broken down more, and so on.

If I'm not using slides, I'll use the same approach but skip the final design step - they just become prompt cards at that point.

Importantly by the time I'm onto structuring, it's already largely mapped out in my head. The structuring piece is about getting it written down explicitly and forcing me to process through, which helps uncover any gaps or problems in the ordering.

Design

It's only when I'm happy with the structure that I'll work on design and formatting. Trying to do it at the same time as structuring is just a distraction, and by the time I've finished the structure I know the style I'll be delivering in.

As a general rule, I'll use standard PowerPoint templates (I've got a small library of custom ones as well). It's mainly laziness, and that frankly the standards combined with the design assistant do a much better job than I could in a lot less time.

Rehearsal

And then again, approaches vary. I very rarely rehearse aloud, instead I spend time running through the presentation in my head any time I can - flicking through slides (if using them) and mentally reviewing what I want to get across at each point.

Others swear by rehearsal and recording themselves. It's whatever approach works for you. I've tried both (and others), and this is what gets the best results for me.

Worth noting is that my use of rehearsals has changed over time. Ten years ago, before I'd created and delivered somewhere over 100 talks, I found them much more useful in figuring out timings and memorizing the points to deliver. I never script talks word for word, tried a few times, and it did not work.

Now, I've had a lot of practice and my estimates of timings and ability to memorize the talk structure are pretty much spot on.

Why the stages?

Breaking it down into distinct stages stops me from getting distracted, and skipping back and forth.

During research I may put together ideas that change the whole nature of the talk, so there's little point having a structure before then. Equally while structuring it out I'll need to rearrange things, and I like design to flow and be consistent with the structure so there's little point wasting time on formatting until that's set in stone.

While I put the rehearsal stage at the end that's not quite accurate. It's fairer to say that throughout the whole process I've got the talk going around in my head - and if an important point or turn of phrase comes up that goes into a brainstorming bucket until the appropriate stage.

The strict rule is to never go backwards. Once the research is done, it's done. Any more digging, no matter how interesting, waits until after the talk is finished (although if something comes up that completely invalidates the talk, that's a different matter).

Once the design is started, the structure is set in stone and cannot be changed.

I've spent too many hours skipping back and forth between stages before, having to revise the whole presentation, to let that happen again.

Parallelizing

At the moment I have six talks under development, and a couple of workshops. All of these are scheduled for delivery in the next couple of months and there'll almost certainly be more.

Each of those talks may be at a different stage. Some barely need any research as they're topics I know upside down and inside out. Some are commercial and the design is fixed by contract and style guides (saves a lot of time).

Each one gets a minimum amount of time spent per week. Usually I'll hit my stride with at least one, spend longer, and get a lot more done on it than expected.

Research is a little different, as that can cover more than one simultaneously and there's time set aside for what I call processing - basically going for a walk, a coffee, reading a popcorn-for-the-brain book, anything to just let stuff percolate in the background.

I've found if I don't do that I spend a lot more time staring at blank pages.

That's all folks!