So you’ve signed up to give a tech talk, awesome! You’re a subject matter expert in something and want to share you knowledge, that’s what helps make a community awesome. You’re going to be speaking in front of a room of people that you don’t know in a place you’ve likely never been, talking about something you confidently know. Sounds easy, right?
Obviously this is sarcasm, it’s not easy at all. Public speaking is hard, like… really hard. Your nerves can and will get in the way if you’re new to the activity. You might get a bout of impostor syndrome while you’re making slides. Hell, you might even tap into that wine you’ve been saving for a special occasion to calm the nerves. But I’m writing this to help you give a great tech talk. With maybe 20% more effort you can give a better tech talk than 80% of all the others.
Jumping into a talk without some type of foreword will be jarring for your audience. You need to introduce yourself, give some backstory about who you are, why you want to give the talk you’re about to give, and (this is critical) tell them what you’re about to tell them.
Telling your audience what you’re about to tell them helps them know what they’re hearing when you’re actually telling them. You are giving this talk because the people in the audience want to learn more about the subject you are speaking about. Not telling them upfront what is about to be discussed at a high level will make the talk more difficult to follow as it progresses. This follows a pattern of:
- Tell them what you will tell them
- Tell them
- Tell them what just told them.
There’s a nice short article about this. Annie Sexton also did a great job of it in her talk about tribal knowledge. It takes her less than 20 seconds to explain what the talk is about to be about. Then at the end she tells the audience what she just told them. It’s very well done.
Raising hands isn’t for you
You’ve probably been an audience member in a talk when the speaker will suddenly pause and ask “has anyone done this before?”. A few hands go up (it’s almost always a disappointing amount) and then the speaker will say “ok, great, a few of us”, and continue the talk. While doing this isn’t necessarily a bad thing, it doesn’t make your talk better. It breaks the flow of the presentation and asks members of the audience to do something they really weren’t ready for. Another thing is it can hurt you as a speaker. You might think that a ton of people will raise their hands only to realize 2 people do and it might throw you off of your rhythm. I have an alternative for this though.
You should only have your audience raise their hands once and on rare occasions twice. Also keep in mind an audience raising their hands is for them to learn something, not for you to learn something. John Allspaw did an awesome job of this at Monitorama when he had the audience raise their hands about their system reliability. He uses their raised hands to show the audience how they are the reason their systems are working.. He knew the outcome of the raised hands before he did it. It was a great use of audience participation to progress a talk and teach something.
If you’re looking for audience participation, it’s rarely having them raise their hands. Measure your success by the number of eyes trained on you, rather than the number of hands pointing skyward.
You’ll probably have slides for your talk. Be it keynote, google slides, powerpoint, you’re going to have a linear way to progress through the presentation. There are some things you need to know about slides, though, that will ruin a talk if you don’t fix them before getting on stage.
Assume the projector has low contrast and that black is more of a dark gray trying to be black. I was in attendance at a meetup and the person giving the talk gave a great start, but then the rest of his talk relied heavily on code samples. Absolutely /none/ of the code was legible due to his code highlighting not cooperating with the contrast ratio of the projector. The problem was he had a grey background with solarized as the syntax highlighting for all of the code slides. To check color accessibility, use a tool like Accessible Colors. which will check your colors against WCAG 2.0 guidelines.
Including code in a slide is usually super engaging to a room full of tech terrans. We /love/ looking at code. But make sure you make the font big and with a slightly heavier weight if possible too. Assume someone is in the audience with less than stellar vision and is sitting in the back. A good trick is using VSCode’s “Copy with Syntax Highlighting” option (cmd+shift+p: Copy with syntax highlighting). This will copy the font with rich text formatting which you can then paste into your slides. However, it will copy with the background color too (I have no idea why), so you’ll have to remove that. Here’s a quick tutorial.
I’ve been to too many talks where the presenter didn’t rehearse and it’s a 45 minute talk. A music album is usually 30+ minutes long, do you think those artists just got into the studio and played music for 30 minutes off of a piece of sheet music and recorded it? (Hint: They did not). The thing that I’d also like to say is that rehearsing doesn’t need to be getting up in front of friends or your cat and giving your talk. Rehearsing can be sitting in your chair where you made your deck and flipping through your slides and speaking aloud. At a bare minimum you should know exactly which slide is next. Doing a TED Talk: The Full Story is a great recount of making a TED Talk.
You should follow the same way musicians rehearse. In music, you don’t play the entire song from start to finish over and over again. Instead, you pick a logical start and end (a chunk as we call it) and practice just that. Once you’ve got it down, move on to the next chunk. Then once you’ve mastered all of the chunks you start from the top and do a run through. It will help your confidence and make a much more engaging talk. Rehearse for your audience who possibly flew from a different country, drove across the state, or are missing a friends birthday because they’re at the conference.
No Blog Posts
I learned from a friend a long time ago that you should avoid giving “blog post” talks. If you could easily get your point across in a blog post, it’s probably not a great candidate for a talk. This doesn’t mean that you can’t have a talk /inspired/ by a post you wrote, but please don’t just make slides from a blog post and present that.
A great talk is one that tells a story. It’s the one where you as a speaker can utilize inflections that would not be caught simply through text on a screen. Incorporating a strategic pause, or even having people raise their hands. You should be trying to engage the audience in a way that 12pt font cannot. Sandi Metz does this by making her talks almost musical. You can almost find a tempo, with 8th notes and triplets, and crescendos and diminuendos.
Try to generate an emotion in your audience. Audience members will enjoy a talk that makes them feel something even if the same points could be illustrated with simple text.
Pick 3 People
One thing I like to do is find 3 people in the audience that are looking at you from the beginning. These people are now your best friends for the duration you are up there. Bonus points if they’re nodding their heads and laughing at your jokes. I try to find a triangle where the point is the front and center and the others in middle/back on the left and right. The people at these points of my triangle are who I’m going to look at throughout the talk while I speak. The reason is simple: It makes your head scan the entire audience and projects your voice to those farthest away from you. The people around these corners also will feel more engaged with too, giving you great coverage of the room. It’s unnerving when you’re talking to your computer screen and not the people in the room. A person that does this ridiculously well is Sidney Decker (watch as he scans the entire room while he speaks). Barack Obama does this incredibly well too.
You are a subject matter expert. You are giving this talk because you are /awesome/ and trying to help others by teaching something new. I’ve learned more through tech talks than books in many cases. I’ve spoken at conferences, I’ve taught in front of classrooms, and I’ve given all-hands talks to companies of hundreds of employees. A key theme is that it’s always nerve-racking. This post was inspired by being in the audience, being on the podium, and helping others with their talks. These are some of my tips based on observation and learning them first hand. I hope they’re useful to you, too.
Break a leg.
You just got paged. Now What? Get started with FireHydrant