Giving your first technical talk

Published in

Kickstart your developer career

8 min readMar 6, 2016

One of the best things you can do for increasing your credibility and visibility in a technical community is to give a talk or presentation.

Though we’d like to believe we’re rational agents, it turns out we’re basically chimps with Human Being OS 2014 installed. When we see one chimp standing in front of a room full of other chimps talking about something, we naturally assume the talking chimp has some special expertise or authority on the topic.

People who give talks are just like you, but the difference is that they decided they might have something useful to share and made the decision to stand up in front of a crowd and share it.

Giving a talk forces you to clarify your ideas on a topic into digestible content. Doing so helps to crystallize your opinion and properly address counterpoints that you may have been avoiding. All of this is good for developing and refining your personal worldview.

It also gets you in front of people in your industry. That probably includes people who are just starting out, alongside senior developers, hiring managers and CTOs. Positioning yourself as an expert on whatever you’re talking about will probably be in your best interest.

Speaking confidently in front of people is generally a good skill to have. It doesn’t mean that you have to become a slimy sales type, just that you’re forced to argue a case for a point or three, probably using logical premises to justify it. Speaking to an audience is about the best practice you can get.

I gave my first technical talk close to the beginning of 2013, and I’ve been invited to guest speak on numerous occasions since. I’ve also watched a lot of technical talks, so I know what it’s like to sit through them.

Picking a topic

Pick something that you’ve mastered, that you’ve experienced or written some code around. The chances are that someone can learn from your expertise or experience, especially if you think it’s a topic that everyone surely knows about in depth.

We always assume that what’s easy for us is easy for others. This is demonstrably false. In programming especially, everyone’s skill set is patchy. Developers who understand their operating system memory allocation in depth may have no clue how to write an SQL query. Others that are masters of computation may have no idea where to begin with natural language processing. Everyone’s traced a different path through the murky woods of technical knowledge, so it’s extremely likely that you have something useful to teach others.

If you’re presenting your talk at a meet-up then contact the organiser with a rough outline of what you have in mind and ask them if they think the talk would be appropriate for the group. If the meet-up has a mailing list, ask the members directly if there’s any interest in your topic. Asking people for feedback builds people’s involvement in the talk, so you know you’ll have at least a few audience members on the day.

The goal of your talk

Different mediums are good for different types of content. If you want to produce a comprehensive guide to solving a problem or achieving a goal, then you probably want to package it as an ebook. If you want to write a technical tutorial or walk-through, you’re better off with a blog post or a screen-cast. If you want to argue a well-reasoned point that takes into account other views on the subject, tons of research and your own experience, then a long-form (1000 words and above) blog copy might be a better choice. If you just want to share a brief insight to get people thinking, you can probably do it in 400–600 words.

For a spoken presentation, you may want to impart some advice, summarise a topic or persuade an audience to your point of view. But more than anything, your goal must be to engage the audience emotionally. I don’t mean that you have to juggle irradiated horseshoes for the first five minutes (though it couldn’t hurt) but unless you strike a chord with your audience on some level, they’re going to be back to email, Twitter and Hacker News less than five minutes into your talk.

People sitting in an audience want you to do well, but they fundamentally don’t care about you. They’re way more interested in the latest Ruby drama, the three new messages in their inbox or the missed call from their husband. As a side effect of your engaging talk, yes, you will inform, persuade, provoke and do all the other things you wanted your talk to do. But while you’re planning, make sure that at every stage of the talk you ask yourself why should they keep listening?.

Keep it short

Your audience has a short attention span. Don’t abuse it. They can concentrate on the sound of your voice for ten minutes before they tune out. The best way not to bore them is by not taking up too much of their time.

No matter how much time you’ve been allotted to speak, twenty minutes of material should be your target. If it’s a shorter lightning talk then you can pick the highlights and just present that. In a larger, say 40 minute slot no one in the history of public speaking engagements has complained about a talk being too short. People will love you for finishing early. Do your twenty minutes and then you’ll have plenty of time for Q&A.

The Setup

It’s annoying to be in the middle of a talk that meanders from point to point with no structure. While experienced speakers can probably pull off winging their talks without spelling out the structure, for your first time your audience will thank you for laying out the structure of your material before you dive into it.

If you think about the last technical book you read, you probably skimmed the table of contents before reading the first chapter. Show your audience the table of contents of your talk so they know what to expect, and aren’t wondering half way through what the point you’re trying to make is.

Here’s how I setup the security talk I gave to LRUG (and have delivered versions of it in-house at various organisations):

I’ve got about thirty minutes to talk to you about security and I’m going to cover five points. That’s roughly five minutes per point with time for a little Q&A at the end. The five topics are:
The mindset you need to adopt to build secure software
The basic security mechanisms of all Rails applications and how they tend to break
Vulnerability case studies
Cryptography and why you should avoid it at all costs
Practical advice for building more secure software

At every stage of the talk, indicate where exactly you are in your talk. Make it as easy as possible for your audience to keep track of their progress through your material.

One trick I like to do is to start the talk with a one to two minute story to get the audiences attention before rolling into the setup. Modern Hollywood movies start the same way, a punchy sequence to get you interested followed by the opening credits.

A basic talk structure

There’s no one true way to structure a talk. For some topics or formats, maybe a pure stream-of-consciousness style monologue is appropriate. You might find yourself spending the whole talk going through one giant list of mini-topics instead. Talks can be structured however you want them to be.

I have a very basic formula for informational/technical talks that appears to work reasonably well. It won’t necessarily guarantee that your talk will be of a high quality, but if you’re stuck for a structure then it will at least provide a starting point.

It’s probably best to use an example topic, so how about “A developers guide to carpentry” (apologies to the actual carpenters in the audience).

1. Why you should learn about the topic (5 minutes)

This is where you present a compelling argument for why the audience should care about this topic. Making these points requires that you have some intuition for the motivations of a typical member of your audience. If you’re a developer, this should be easy, because you’re a developer too.

For our carpentry talk, you might spend one or two minutes on each of the following bullet points:

Carpentry let’s you express your creativity by building objects with wood.
Being good with wood means you’ll be better at DIY projects at home.
Many of the skills are transferable e.g. to metalwork, hardware hacking and building robots, who doesn’t like building robots??

2. Some educational examples of things you’ll do/learn about (10 minutes)

This is the meat of your talk, where you go into detailed explanations about educational examples of things in your topic. For carpentry that might be:

Basic tools that carpenters use (1m)
Cutting (1m)
Joining (1m)
Building a plant pot (2m)
Building a chair (5m)

Here is where you give them a taste of what they have in store for them if you go deeper into this topic. If you found some interesting insight or factoid while doing your research, this is the place to share it.

3. Practical advice for getting better (5 minutes)

You finish off by giving the audience members tips on how they can learn more and become better carpenters. You might mention simple good habits for carpenters that you found made you better at working with wood, or perhaps recommend the absolute best book ever on introductory carpentry.

Do at least five full rehearsals

Actually delivering the talk will feature all sorts of complications. You’ll have trouble getting the microphone set up, your battery will run out, the wifi will intermittently cut out, you’ll have lights trained on you and there’ll be a guy in the third row who is talking and finds himself incapable of shutting up.

If on top of all that you don’t know your material well, your talk is going to be a very stressful experience for you. The point of rehearsing is not to be able to produce on cue like a robot. It’s instead to know your core material and have it close at hand in memory for delivering to your audience. Being able to produce your material at will means that you can focus on getting the small problems like laptop power and noisy audience members handled, safe in the knowledge that you’re ready to jump straight back into your material whenever you like.

Knowing your material back to front has one other key benefit: you can remix and adapt it to your audience on the fly. You can give that same presentation to an audience of less then twenty and have a lot more audience contribution, making it more of a discussion than a talk. You could also space that material out over a day interspersed with exercises and present it as a workshop.

When you’re rehearsing:

Time the rehearsals, and if you go over, edit the talk down to compensate.
Speak out loud. It feels weird when you start but just do it. Words flow together differently when they’re vocalised and saying the words out loud will help you keep them in memory.
Rehearse the entire talk. This is the only way you’ll get a feel for how the whole talk fits together.

The first couple of rehearsals will help you figure out your talk structure. You’ll get a feel for when the topic transitions are a little unnatural and will have ideas for making them better.

The two, three rehearsals after that are there for you to practice the talk delivery and edit out non-essential material.