Giving a Tech Talk – Part 3/3: Design the Delivery

A great talk can seem very natural and off-the-cuff when seated in the audience. But, behind the scenes, most speakers put a lot of effort into preparing a talk.

Preparation is everything, especially for those of us that aren’t natural public speakers. How you prepare will differ based on your strengths, weaknesses, and personality. Over the last few years I’ve found a process that works well for me, I hope that sharing it will be helpful to others.

There are three stages I use to develop a talk, each is covered in this three part series.


Part 3: Design the Delivery

Great content is only half the story. That content needs to be presented clearly, so that people understand it. Your talk also needs to be engaging, so that people can stay awake to absorb it.

Just like building software, this is where you need to be customer obsessed. Keep asking yourself “what will this be like for someone sitting in the audience?”.

Here are some if the things I pay attention to…

Timing & Pace Notes

A presentation that finishes more than 5min early looks sloppy. A presentation that runs long (even by a few minutes) is frustrating to attendees who can hear the other rooms heading to enjoy the delicious conference lunch.

I present and time each section individually, jotting down roughly how long it took. Then I add it all up and see how it fits. Now is the time to add to or remove content (or perhaps even full demos). Trying to cram content in, or stretch it out, will never end well.

Your timing might be great when you’re relaxed in your hotel room, but keeping a good pace on stage is a different matter (especially if you are new to presenting). I write up pace notes that are going to sit with me on the stage. The end of each section/demo is a natural place to take a few seconds to check how on pace you are.

I pace notes them in whatever format is going to be easiest for the setup I’m working with. At big conferences that’s a countdown timer showing how many minutes I have left.

pace-notes.png
Image: Pace notes from a smaller conference, where I was using my watch

Have a plan for what you’ll do if you are off. I make sure my last demo is the one I will cut if I’m running behind. I typically have one extra demo up my sleeve in case I’m running ahead.

Practice

I really dislike practicing out loud, but I will dry run thru the whole presentation at least once – maybe two or three times if it’s new content. This ensures the story and demos work end-to-end. I’ll have a stopwatch going to make sure my pace notes work.

While I only practice actually presenting a few times, I practice the demos over and over again until I am super confident with them. This helps you find the quirky ways that they sometimes fail – so you know how to fix it if it happens live. Most of the time I’m just doing the coding steps, but sometimes I talk to make sure I can explain things crisply.

Practice also helps identify the operations that take a while, so you can plan to explain something while you wait for code to deploy etc.

Planning for Nerves

If you’re going to be nervous, the first 30sec will be the worst. Memorize your first two sentences, once you get these out things will be a lot easier.

I did this for my first couple of talks, and now out of habit I always start with “Good morning/afternoon everyone, thanks for being here. My name is Rowan and I work as a program manager…”. It’s ok if folks miss some of this, it gives time for folks to tune in to the fact the talk is starting, time to adjust mic level if it is off, and gives folks a few less important sentences to get used to my accent etc.

Make Sure the Audience Can See

Just like a great movie is no good on a distorted screen with poor sound. You need to put yourself in the audience’s position (literally) and look at your talk (also literally).

Font sizes are the most obvious. I set everything to font size 16 as a starting point (code, console output, log viewers, application UI… everything). Make sure you practice like this; it makes a huge difference to how you navigate thru code.

If you have hardware etc. then think about how are folks going to see it. Do you need a camera so that they can see what is displayed on your phone? Or is there some remote viewing software to display it on your laptop?

hardware
Image: Using a camera so that the audience can see a hardware demo
Photo credit: @mansi_marco

Avoid Distractions

Some tips to help the audience focus on exactly what you want.

  • Hide your clock – If your task bar clock is visible, then folks will be distracted by how long it is until lunch.
  • While you’re at it, hide everything else
    • Move all the icons off your desktop, folks don’t need to know what you are working on
    • Personal pictures shouldn’t show up in the start menu
    • Switch off any auto-preview of incoming emails
    • Make sure IM etc. is closed.
    • Set the default browser page to be blank. Folks don’t want to see your Facebook page when you open a browser (or the latest news from MSN).
  • Avoid custom themes and stick with the default schemes for your IDE, operating system, etc. You may love your dark IDE theme, matrix desktop background, and Windows 7 style start menu… but it’s going to be distracting to folks that aren’t used to it.

Know Your Room

This will vary so much depending on your content, the venue, the conference, etc. Take the time to think about it for every talk, even if you’ve presented the content before.

If you are at a conference, can you attend an earlier talk in the same room? That way you can see any room specific issues and plan around them (or talk to someone to address them).

Check that your font size is increased far enough for the room. I will bring up some code and go stand at the furthest seat from the screen. Sometimes I need to bump fonts up to 18 for them to be easily readable.

Think about lighting, mic levels, etc. Big conferences take care of all of this for you, but it’s your job if no one else is doing it. You want enough light that folks can see you, but not so much it makes the screen hard to see. It should be easy to hear at the back of the room, but not uncomfortable at the front.

Closing Thoughts

The purpose of all this preparation isn’t to give a robotic talk. All this prep should give you the confidence that you have a great talk, robust demos, and contingencies for everything that could go wrong. Now you can relax and be yourself on stage. The best presentations are where the presenter is relaxed and confident with their content.

Someone once told me to treat each session as if you just discovered something cool and you are taking your laptop to a co-worker to show them. You’ve just built something cool… go show people.

 

<< Part 2: Build Demos