This article outlines the steps I follow to prepare my technical talks, including notes on slide design, engaging with the audience, how to prepare the delivery, and how to manage the Q&A.

How I prepare a technical talk

I have a lot of fun giving talks at conferences. I am not the best speaker ever and I am far from being a prestiged speaker. However, I have had enough positive feedback from enough talks to claim with some confidence that I am a decent speaker.

The article will be split into five sections outlining my thoughts on:

1. slide design;
2. audience engagement;
3. talk delivery;
4. how to practice; and
5. managing Q&A.

I will also include some notes on how I personally prepare the content for my talks and I will close this article with a very important note regarding the fact that, obviously, all of this is subjective.

Slide design

Most presenters use a slide deck as the medium for the content of their presentation. My audience will spend a great deal of time looking at my slide deck, so it is important that my slide deck is a tool that helps me deliver an excellent technical talk, and not something that hinders my performance.

When creating my slide deck I try to follow these guidelines:

• Keep text to a minimum: no walls of text. No long paragraphs. No huge sentences. This is a common piece of advice and yet everyone disrespects this. I really try to keep text to a minimum.
• Bullet points only: to help with the above, I try to only include text formatted as a list of short bullet points.
• Large font size: I try to use a huge font size. No, it won't be too big. Also, if the font size is huge I can't fit a lot of text in the slide, so that's a bonus.
• My audience either listens or reads: my audience can't multitask. If they are looking at my slides, reading, they are not listening to me.
• If it's in my slide, they will read it: or try to. Everything that shows up on my slides will distract my audience. If it's in a small font, I'll lose time while the audience tries really hard to read what I included in a small font size.
• No animations: or only very simple ones. If things move a lot, I'll distract my audience and if I distract them it will be hard to get their attention back.
• Code samples: if you are showing code samples,
  • simplify the code as much as possible. It is ok to ellide surrounding code if it is not absolutely essential to have that piece of code on the screen.
  • increase the font size. The font size should be especially large for code samples.
  • use high-contrast highlighting and preferably a light theme. I'm a dark mode person but code samples should ideally be in a light theme. This is because in many settings the projector/screen/room lighting is just not good enough for code in a dark theme.
  • take the points above extra seriously if you are live coding.

Audience engagement

If my audience isn't engaged, they won't listen to me. That's it. And there's no point in giving a talk if no one is paying attention.

• Actively engage my audience: make an effort to interact with my audience. Small interactions pay off greatly.
• Shows of hands: ask questions that can be answered with a show of hands. The physical movement keeps the audience awake.
• Basic questions: I can ask really simple questions to increase the chance of getting a correct answer from the audience, although getting an incorrect answer is better than getting no answer at all.
• Ask questions to which I know the answer: this means I get to interact with the audience without losing control of the narrative. I do this quite often.

Talk delivery

The way I deliver my talk can make or break a great talk. I obviously need to “know my stuff” and my talk should be built around great content. But having great content doesn't automatically mean my talk will be great.

(You have no idea how many terrible talks with outstanding and interesting content I've sat through... It's always painful.)

• My talk doesn't need to be a circus: I look for small things I can do to improve my delivery but don't go with over-the-top theatrics.
• Use humour: humour is great, even if I'm not a comedian. A simple joke here and there is a great addition to a talk.
• Live coding: everyone I listen to recommends against live coding. I love doing live coding but I'm aware that it is a high-risk/high-reward kind of thing. I make sure to practice a lot and have a backup plan in case anything fails. Tip: Internet can fail at a tech conference. I've seen it.
• 20% of the show-off gets 80% of the results: again, minimal flair can often achieve great results. I just want to make sure my talk is not super dry.
• Keep my voice in check: manage my rhythm and my tone. Don't go so fast no one understands what I am saying. Hit more than one note with my voice.
• Have fun: if I'm having fun, I will pass that on to my audience. If I'm genuinely enjoying my time on stage, it really does increase the chance that my audience will enjoy my talk.

How to practice

Have you ever been in a talk where the speaker is constantly surprised by their own slides? I don't want to be that person. That's why I make sure to practice my talk so that I can give my whole presentation smoothly.

• Practice repeatedly: I go over my talk more than once. Everyone knows practice makes perfect and when it comes to giving talks, it really shows.
• Record myself giving the talk: when I'm at a point where I feel comfortable with my delivery, I record myself and then play it back to watch it and critique myself. Watching myself will give me a more faithful representation of what the audience will get and I will realise that I don't sound as good as when I'm just inside my head.
• Practice the talk standing up: simulate the actual experience as closely as possible. I won't be sitting down when I give my talk, so why am I practicing sitting down?
• Don't script my talk word for word: if I do, I'll (try) to memorise the exact script and if I forget a word or sentence, I will get stuck.
• Learn the key points and their order: instead of scripting my talk fully, I make sure I know the overall key points of my talk and the order in which I'm supposed to go through them. When practicing my talk, I go through those key points but use different wordings and sentences. I also experiment with different examples.
• Keep speaker notes in the slides or in a printout: it's not cheating, it's preparation. My speaker notes shouldn't be the full script of my talk. They should contain the key points of each section or slide so I can quickly check if I'm forgetting something. It's ok to have speaker notes and to check them but it is not ok to spend a painfully long silent amount of time reading them to look for the thing I just forgot.
• Practice the timing: I time myself and check the time as I go through the main sections of my talk to get accustomed to the ideal timing. This will make it easier to keep track of my rhythm when I'm doing the actual presentation.

I find that I tend to speed up a bit when giving the actual talk, either because I talk faster than when I practiced or because I forget to mention one thing or another in some sections. Provided I practiced the timing well enough I will be able to spend more time in some other section of the talk to make up for that.

It's also common for me to forget a secondary point or a specific example because I don't script my talk fully, but instead just memorise the key points I need to go through. This is usually ok because I know I forgot something but the audience does not. And again, I get the flexibility to then spend some more time in another section to make up for it.

Managing Q&A

The Q&A section of my talk doesn't have to be daunting and there are some great tips to consider for when I'm doing live Q&A at the end of my talk:

• Be comfortable with not knowing: it's ok not to have all the answers. Intelligent people say they don't know; they don't make up answers. If someone asks a question I don't have an answer for, I say I don't know and offer to follow-up after the talk.
• Suggest private conversation in complex/off-topic Q&A: avoid derailing the Q&A. If someone starts going off-topic or asking really complex, niche, or contrived, questions, I offer to follow-up after the talk, so that other members of the audience have the opportunity to ask their questions.
• Douchebag questions/remarks: if someone walks up to the microphone and makes a douchebag remark or asks a douchebag question, the audience will also understand it's a douchebag remark/question. It's ok to politely dismiss those and my audience won't blame me for it.

Content preparation

When I'm preparing a talk I always start with the content. I follow more or less the same workflow every time but I don't have a list of guidelines or suggestions. Instead, I will just share what I do.

After picking a topic for my talk the first thing I do is spend a lot of time thinking about it. When walking on the street. When taking public transportation. On the toilet. In queues. I just fry brain cells thinking about that topic. Coming up with examples related to the topic. Analogies. Related concepts or ideas. Anything and everything that's around the topic. This typically yields a lot of different things I could include in my talk, but at this point all I have is a big blob of ideas.

After I have a big blob of ideas, I sit down to sort them. I try to order some of the ideas in a reasonable way that leads the audience to my desired conclusion. In this step I do not necessarily use all of the things I thought about in the previous step.

After I have the rough order in which I want to cover the main ideas/examples/concepts of my talk, I write about them. I don't script my talks, but I typically write a blog article that I use as a reference for my talk. As I'm writing the article, I get to test if the ideas I selected and the order I laid them out makes sense. As I'm writing the article, I get to check if the examples are good and if the analogies make sense.

I only start working on my slides after writing the blog article.

All of this is subjective

I've shared with you most of the things I think about when I prepare a talk. I try to follow the things I jotted down here. Some of them, I manage to follow quite nicely. Some others are still things I aspire to be able to do well in the future.

It is important to understand that most of these guidelines are quite subjective. These guidelines work well for me and you can try them out for yourself, but they won't necessarily work for you. I know good speakers who follow similar guidelines and I know good speakers who do the complete opposite of some of the things I say here. You can experiment and draw inspiration from the workflows of others, but in the end you have to find what works for you.

I appreciate you taking the time to go through this article. I'd be interested in hearing about your personal experience as a speaker, so please leave a comment below or reach out to me to share your own recommendations and your workflow.

Become a better Python 🐍 developer 🚀

+35 chapters. +400 pages. Hundreds of examples. Over 30,000 readers!

My book “Pydon'ts” teaches you how to write elegant, expressive, and Pythonic code, to help you become a better developer. >>> Download it here 🐍🚀.