Creating, writing & delivering awesome technical talks

September 24, 2018

After DevOpsDays London, a bunch of people approached me, IRL and on Twitter, to ask for tips for delivering technical talks. I made a Twitter thread after my keynote at Write/Speak/Code:

I’m not an expert at giving technical talks by any means – but I do know a thing or two about public speaking, thanks to over ten years of public speaking training throughout middle school, high school, university and graduate school. This blog post is my attempt to externalise my process for brainstorming, designing, and executing technical talks over the last few years.

Also side note: I’ll be giving a lightning talk about this subject at the unconference before Cloud Foundry Summit in Basel, which will cover a subset of this blog post!

But first, a rant about imposter syndrome and technical speaking:

Being a domain expert is not a requirement to give a talk

A few times I’ve submitted proposals for talks that I knew would be ambitious for me to write, because I hadn’t spent much time working or tinkering in that subject area. From conversations with newer speakers, I know anecdotally that many people are hesitant to volunteer for talks because they feel like they need to have unimpeachable authority. But this isn’t true, and this is a manifestation of Imposter Syndrome, which is experienced more acutely by women and non-binary folks, and people of colour.

You can and should start giving technical talks before you’re a domain expert on anything. Of course you should still research the topic! More on this later. Writing the talk in itself is a learning journey that will force you to build mental maps of the topic area faster than learning it organically, and no matter where you are in your understanding, there will always be people in the audience hearing this information for the first time.

3-6 months out: Discovery & CFPs

Conference Discovery

I basically learn about conferences that I want to speak at on Twitter, via other speakers and colleagues that I want to emulate! This is a long list, but some examples include Ashley McNamara, Carolyn Van Slyck, Liz Fong-Jones, Bridget Kromhout, Steve Smith, Liz Keogh, Nadia Odunayo, Angela Chin, Elisabeth Hendrickson, Gwen Diagram, Chris O’Dell, Sarah Mei, and many more. I was going to add more guys to this list but I am amused by Steve being the token guy :-D

Writing the proposal

Sarah Mei wrote a great blog post a few years back on the anatomy of a great CFP: What Your Conference Proposal is Missing

Fundamentally, when I try to write proposals, I try to answer the question: “What would I as an attendee get out of going to this talk?” As an audience member, I don’t expect some groundbreaking new worldview, but I do expect two or three “nuggets of knowledge” that I can go and research in more depth after the talk. Be upfront about what your “nuggets” will be!

If you have time, get a colleague to proofread your proposal before submitting, and ask them, “What do you think you’d learn from attending this talk?” If their answer doesn’t line up with your expectations, revise and iterate.

I recommend setting up a Google Drive folder, or Dropbox, or whatever you like to use, to keep track of all of your proposals, where they were submitted, and their acceptance status. Alongside this information you should also keep a speaker photo and short speaker bio handy. I alternate between a few different speaker bios depending on what type of conference and talk I’m delivering. I have one bio that is more oriented towards product management, another that includes more engineering career details, and another one that mentions more about my art side projects.

1-3 months out: Designing and practicing your talk

After I have a talk accepted, I celebrate for about 30 minutes, until I realise the enormity of the commitment I’ve just signed up for. The best way to manage the overwhelming feelings of stress is to come up with an outline and a game plan as soon as possible, then give myself soft deadlines in the next few weeks to finish the slides, rehearse a certain number of times, etc.

Set talk completion milestones

I generally have five milestones:

  1. Write an outline (at least 2 months before conference)
  2. Create a first draft of the slides, usually with no visuals, and lots of ugly placeholders (at least 6 weeks out)
  3. Run the first draft in front of a small group of trusted people, to get feedback on the thesis (at least 6 weeks out)
  4. Create a more polished version of the slides, with 80-90% of the visual elements completed (at least 4 weeks out)
  5. Run the polished version in front of 1-3 audiences, depending on how high-profile the talk will be (1-4 weeks before conference). More on this below!

Some people might disagree with doing things so far in advance, and I know plenty of people who make their slides last-minute with great success – but that isn’t a healthy way for me to work. I am much more relaxed when I know I have extra time, but I know that my system won’t work for everyone.

Design a research plan

I generally give three types of talks:

  1. A neutral, technical overview of some technology, process, or concept
  2. A firsthand experience report of using some technology or process
  3. A consolidation of ideas and experiences by other people

My research process is different based on the type of talk it is.

For Type 1, I spend anywhere from 5 to 20 hours watching YouTube videos of recent other talks that deal with similar subject matter, reading official documentation, following tutorials, and reading blog posts. My outline usually begins broadly with a survey of “What have other people already said?” to set the stage, then goes narrower into whatever I said I would talk about.

For Types 2 and 3, in addition to the “academic research”, I interview people. Usually other people at Pivotal, because I talk a lot about my work, but I sometimes venture out into the Real World. I try to gather qualitative insights about whether something worked or not, why it was successful or not, and what others have learnt already. For my SwanseaCon talk I interviewed a dozen of my colleagues. I had joined the company recently, and it turned out that this was actually a great excuse to speak with senior-level people that I hadn’t had the chance yet to meet! For my competitive debate talk, I reached out to people who wrote articles that I relied on, and some of them became some of my biggest advocates and allies, sending me more research and introducing me to others who had more recent experiences to contribute.

Interviewing people takes more time and schedules are hard, so I start my research process earlier if I know that this is involved.

Presentation tools

I use Google Slides and Keynote exclusively. I use Google Slides when I collaborate with another presenter. I prefer the feel and flexibility of Keynote though, and I know that Keynote will run offline without any extra browser plugins. I usually just stand at my computer and use the arrow keys to operate the slides, but lately I’ve been trying to get more used to using a remote clicker.

I used to use slides.com, but it’s really heavy in terms of client-side JavaScript and (as of two-ish years ago) it had no offline support, so it could get really laggy if the WiFi wasn’t stable. Things may have changed now, but I still only use it as a place to store slides afterward.

My 80/20 (or 60/40) Rule

I only career-switched into tech a few years ago, so even after several mainstage talks, I still feel like I don’t know anything. Then I think back to the talks I’ve seen, and realise how many of the basic fundamentals I have today only because a conference speaker surfaced them for me. So now I try to relax about saying things that feel “obvious” to me, but may not be for everyone watching. When there are too many obscure or new things in a talk, there also comes a point when most audiences can’t absorb any more context – your audience will likely be fatigued, sleep-deprived, jetlagged, etc – so curating your content is important.

I try to adhere to an “80/20” rule: for 80% of my content, I believe that 50% or more of the audience will have encountered previously; for 20%, I believe that the content will be brand new or otherwise unintuitive. In this 20%, I don’t mean performing original research; but rather, framing existing ideas in a story about personal experience, or building on some existing body of literature, or offering a piece of advice that feels counterintuitive.

If I have a breakout session where people will self-select so that I can expect my audience to have greater specialised knowledge, then I try to aim instead for 60/40. For example, if at a large conference there is a product management track where I am speaking, I will probably not bother to explain what Lean Startup is, but at a mainstage presentation I would spend 20 extra seconds to avoid leaving anyone behind.

Content cadence

I learnt in competitive debate that the best way to make an argument stick is to signpost it before and after:

“I’m going to explain X. This is X. I have told you about X.”

In technical talks, you’ll often see the pattern of an agenda at the beginning, followed by the content, followed by a slide about “Key Takeaways”. I think that’s a good pattern – it’s one that audiences know.

Cadence is about more than just signposting though. It’s also about the speed and density of transferring information to the audience. I’ve iterated towards a style of slide-making that someone described to me as “subtitles for yourself”, which is a cool way to describe it! I like a combination of low-density and high-speed, because I’m a visual learner - I have trouble focusing when someone pauses on a slide that’s just a picture of some architecture diagram and explains it for ten minutes. I’d much rather see 30 slides cycling quickly, each featuring a very small slice of the diagram, then a quick synthesis at the end. I try to design my slides in the second way.

If you must have bulletpoints, then make each bulletpoint appear individually with transitions, or just multiple slides with one more bulletpoint on each subsequent slide. I don’t do bulletpoints much now - I use full-screen, one-sentence, text-only slides when I want to emphasise something. For an example of what I mean, you can check out my Write/Speak/Code slides.

To be really honest, I think I optimise too heavily towards attention-grabbing. Probably most people are better at paying attention than I am!

Speaker notes

I put the world into speaker notes. Some people are comfortable to riff, and sometimes I riff - but it’s really hard for me to run the talk consistently to the same timing if I riff. Plus, onstage, I get more nervous, which means I riff more.

I write out word-for-word what I am going to say, in my speaker notes, and I use the speaker notes at every single practice run-through, and iterate them as much as the actual content in the slides. In fact, I consider the speaker notes part of the talk’s “public API”. I don’t always read speaker notes word-for-word, but having full sentence structure tells me what I definitely need to cover.

I have two quick tips:

  • Always format speaker notes in at least size 24 font. If the notes are readable from a distance, you will be able to step away from the podium or walk around more freely.
  • If you plan to read part of a slide out loud, write that out in the speaker notes as well. This is because in presenter view, for both Google Slides and Keynote, the slide itself shows up super super small.

Visuals

Presentation visuals can be really tricky to get right. A temptation these days is to put ALL THE GIFS in every slide… in my opinion, GIFs tend to distract from any important content accompanying them, so I only use GIFs as full-page, standalone slides for transitions or simple messages, like “everything is on fire!”

Record yourself!

One tip that I received from a debating coach is to record myself delivering a speech, then watch it (SO MUCH CRINGE) and learn to critique myself. This is incredibly useful, especially if you are new to speaking in public.

Take your phone camera, prop it up against something on your dresser, and literally deliver your talk to your phone, without stopping. You can also get a roommate or pet to be present, if you feel too awkward talking to a phone :-) You will pick up on physical habits (maybe you bite your lip or fiddle with your shirt buttons) that you won’t notice otherwise. You’ll also get a sense of whether you’re speaking too fast and where you struggle.

But also remember to be gentle to yourself. For some people, this can be a slippery slope to beating themselves up, so just please remember to give yourself the latitude and understanding that you would grant to another new speaker. Celebrate the things you did well, and identify small things to try to fix, one at a time.

Get feedback! And bribe people if you have to

As mentioned earlier, I try to run the polished version of my slides at least 1-3 times. This is the most important component of shaping a talk, and also the scariest - all the more reason to do it often and early. I try to also gather different audiences:

  1. Small group of trusted individuals at work, such as my current teammates
  2. Larger group at work, perhaps even the whole office, framed as a “Lunch & Learn”
  3. Small group of non-work friends
  4. [Optionally] At a meetup where the audience is unlikely to overlap with conference attendees. I only do this if the meetup and conference are in different cities

I sometimes use talk rehearsals as an excuse to convene friends for dinner at my flat. In exchange for a homecooked meal, I’ll run my talk and collect feedback.

When I run these feedback sessions, I do a few things to maximise productivity:

  • Give everyone paper and something to write with
  • Create an extra slide at the beginning when people are shuffling in, with specific questions to frame the feedback. Examples:
    • Did you hear any jargon that wasn’t explained?
    • Did any part of the talk feel surprising or out of place?
    • Were any slides too dense, or too sparse?
    • Did the content you heard match your expectations based on the talk title and/or abstract?

Also, if you bribe people with dinner, it’s better to run the talk before the food, so people are more honest ;-)

As people give feedback, I type up their feedback in real time into the speaker notes section of the sildes. I don’t delete or rearrange slides in real-time because someone else might have contradicting feedback. I also don’t take onboard all the feedback I receive - this took me a while to learn, but just bear in mind that this is your presentation!

You can do this!

I hope this blog post was helpful! I haven’t covered tricks for day-of delivery, which might end up being a follow-up blog post later. Feedback is welcome - tweet at me or email me.