In particular if you have done a few talks already and you start feeling comfortable, it can be tempting to think you could just wing it and skip the rehearsal for your next one. After all, it can feel weird to be alone in your room and speak aloud all by yourself. I highly recommend to not fall for that — rehearsing a talk is absolutely vital for making it successful. It will help you to develop a consistent line of argument and identify any things you otherwise may forget to mention. Only proper rehearsing will give you that natural flow you want to have for a talk.

Also, it will help you with the right timing of your talk: you don’t want to finish 20 min ahead of time, nor reach the end of your presentation slot with half of your slides remaining. If this happens, it usually means folks haven’t rehearsed once and it’s not a good position to be in. For a new talk, I usually will do three rehearsal runs before presenting it at an event. I will also do a rehearsal run if I repeat an earlier talk after some months, as it’s too easy to forget some important point otherwise.

When doing a rehearsal, it’s a good idea to note down some key timestamps, such as when you transition to a demo. This will come in handy for instance for identifying sections you could shorten if you realize the talk is too long in its initial form.

How to start a talk well could be an entire topic for its own post. After all, the first few seconds decide whether folks will be excited about your talk and pay attention, or rather pack out their laptop and check their emails. What I’ve found to work well for me is starting with a mission. I.e. I’ll often present a specific problem and make the case for how listening to that talk will help to address that problem. Needless to say that the problem should be relevant to the audience, i.e. its key to motivate why and how it matters to them, and how learning about the solution will benefit them. Don’t focus on the thing you want to talk about, focus on a challenge your audience has and how your talk will help them to overcome that.

Another approach is to present the key learnings (for instance three, see below) which the audience will make during the talk. While this may sound similar to an agenda slide, the framing is different: it’s taking the perspective of the listener and what’s in it for them by sticking through your session. Don’t lead with your personal introduction; if you’re known in the field, people don’t care. And if you’re not, well, they probably also won’t care. In any case, telling much about yourself is not what will attract people to your talk. I usually have a very brief intro slide after discussing the mission or key learnings.

Good talks tell a story, i.e. there’s a meaningful progression in terms of what you tell, starting with some setting and context, perhaps with some challenge or drama ("And this is when our main production server failed"), and of course a happy ending ("With the new solution we can fail-over to a stand-by in less than a second").

Now it doesn’t literally have to be a story (although it can be, as for instance in my talk To the Moon and Beyond With Java 17 APIs!), but you should make sure that there is a logical order of the things you discuss, for instance in a temporal or causal sense, and you should avoid jumping forth and back between different things. The latter for instance can happen due to insufficient rehearsal, forcing you to make a specific point too late during the talk, as you forgot to bring it at the right moment. Also, for each discussion point and slide there should be a very specific reason for having it in your deck. I.e. it should form a cohesive unit, rather than being a collection of random unrelated talking points.

Other storytelling techniques can be employed to great effect as well, such as doing a quick wrap-up when finishing a key section of your session, or adding little "side quests" for things you really want to mention but which are not strictly related to the main storyline.

In terms of crafting a story, I try to start early and collect input over a longer period of time, typically using a mind map. This allows you to identify and gather the most interesting aspects of a given topic, also touching on points which perhaps came up in a revelation you had a while ago. You’ll be less likely to have that breadth of contents at your disposal when starting the day before the presentation. This is not to say that you should use every single bit of information you’ve collected, but starting from a broad foundation allows you to select the most relevant and insightful bits.

As mentioned at the beginning, one of my pet peeves is presenters turning their back (or side) to the audience and looking towards their slides projected next to them. This creates a big disconnect with your audience. The same applies to the slides on the laptop in front of you, avoid looking at them as much as you can. Instead, try to have as much eye contact with the audience as possible, it makes a huge difference in terms of perception and quality of your talk. Putting a sticker onto your screen can be a helpful reminder. Only if you actually speak to the audience, it will be an engaging and immersive experience for them. It’s extra bad if you don’t use a microphone, say at a local meet-up, as it means people will be able to understand you much worse.

Now why are folks actually looking at their slides? I think it’s generally an expression of feeling a bit insecure or uncomfortable, and in particular the concern to forget to mention an important point. To me, the only viable solution here is that you really need to memorize what you want to say, in which case you’ll be able to make your points without having to read anything from your slides. Your slides are not your speaker notes!

In terms of what should be on slides, this again could be a topic for its own blog post. In general, the less words the better. Note I’m not suggesting you need to go image-only slides TED talk style, but you should minimize the amount of text on slides as much as possible. The reason being that folks will either listen to you or read what’s on your slides, but hardly both. Which means that either your effort for putting the text on the slides is wasted (bad), or folks don’t actually get what you’re telling them (worse). So if you think you’ve removed enough, remove some more. And then some more. This also allows you to make the font size big enough, so that folks actually can read those few items which remain.

What I personally like to have on slides the most is diagrams, charts, sketches, and the like. Anything visual really. Which also brings up one exception to the "Don’t look at your slides" rule: if you actually explain a visual, elaborating a particular part for instance, then shortly turning towards the slide and pointing to some element of it can make sense.

On a related note, I recommend not relying on having access to your speaker notes during a talk. While technically it may be possible to show the notes on your laptop and the actual slides on the projector, this will fall apart when you do a live demo, where you really need to work with a mirrored set-up. Think of speaker notes as of cheat sheets back in school: the value is in writing them, not in reading them. By the time you’ll present your talk, you’ll have memorized what’s on your notes. Make use of them for developing the story line for each slide, and of course they will also be useful when coming back to a talk after a few months.

I don’t see that one done wrong too often, but it’s worth pointing out: a talk should actually match its audience. So if for instance you talk to users of some technology, focussing on use cases of it makes sense, or on how to run it in production etc. Whereas this audience probably won’t care as much about implementation details (as much as you may want to talk about how you solved that one tricky technical challenge using some clever approach). If, on the other hand, you present about the same technology to a conference geared towards builders of tech in that space, diving into those gory details would be highly attractive for the audience.

That’s why I focus heavily on use cases when talking about Debezium at developer conferences. Whereas when I had the opportunity to present on Debezium and change data capture (CDC) during an online talk series of Carnegie Mellon’s database group, I centered the talk around implementation challenges and improvements databases could make to better support CDC use cases.

Key here is expectation management: make sure you know what kind of audience you’re going to speak to and adjust your talk accordingly. Oftentimes, the same basic talk can work well for different settings and audiences, just with framing things the right way and putting the focus on the right parts, for instance by swapping a few slides in and out.

Over time I’ve become a big believer in the rule of three; for instance, have three main learnings or ideas for a talk. If it’s a talk about a new product release, share three key features. On one slide, have three main points to discuss. When you share examples, give three of them. And so on.

Why three? It hits the sweet spot of providing representative information and data, letting you enough time to sufficiently dive into each of them, and not being too extensive or repetitive. Your audience can digest only so much input in a given session, so they’ll be better served if you tell them about three things which they can take in and remember, instead of telling them about ten things which they all quickly forget or even miss to begin with.

Live demos can be a great addition to any technology-centered conference talk. Actually showing how the thing you discuss works can be an eye-opener and be truly impressive. Not so much though if the demo gods aren’t with you. And we’ve all been there: poor network at the conference venue doesn’t let you download that one container image you’re missing, you have a compile error in your code and in the heat of the moment you can’t find out what’s wrong, etc.

Trying to analyze problems in front of a conference audience can be very stressful, and frankly speaking, it’s quickly getting boring or even weird for the audience. So you always should have a fallback plan in case things don’t go as expected with your demo. My go-to strategy is to have a pre-recorded video of the demo which I can play back, instead of wasting minutes trying to solve any issues. I’ll still live-comment that video, which makes it a bit more interactive rather than collectively listening to my pre-recorded voice. For instance I can pause the video and expand on some specific point.

Some personal habits are really hard to change. One example: I tend to speak fast, very fast, during talks. I’m well aware of that, listeners told me, a coach told me, I saw it myself in recordings. But it’s somehow impossible for me to change it. If I really force myself hard to speak slower, it will work for a while, but typically I’ll be back to my usual speed after a while.

So I’ve decided to not fight against this any longer and just live with it. The reason being that I feel the high pace also gives me some energy and flow which I hope becomes apparent to the audience. I believe viewers (and I) are better off with me doing a passionate talk which may be a bit too fast, instead of one which has a slower pace but lacks the right amount of energy.

I think that’s generally applicable: You don’t like talking about concepts, but love showing how things work in action? Then shorten the former and make more room for a live demo. You enjoy discussing live questions? Make more time for the Q&A. This all is to say, instead of excessively focussing on things you perceive as your weak sides, rather leverage your strong suites.

(Yes, the irony of this being part of a post focussing on avoiding basic mistakes is not lost on me.)

I’ve found it works great if you circle back to a point you made earlier during a talk. The most apparent way of doing this is coming back to the mission statement you set out for the talk at the beginning. You should be able to make the point that the things you presented actually satisfy that original mission. Or you have some sort of catch phrase to which you cycle back a few times, repetition can help to drive home a point. Just don’t overdo it, as it can become annoying otherwise. Personally, I like the notion of circling back as it provides some means of closure which is a pleasant sensation.

And that’s it, ten basic tips for making your next talk suck a bit less. You probably won’t get an invitation for doing your first TED talk just by applying them, but they may help you with your next tech conference or meet-up presentation. As a presenter, you should think of yourself as a service provider to the audience: they pay with their time (and usually a fair amount of money) to attend your talk, so you should put in the effort to make sure they have a great time and experience.

What are your presentation tips and tricks? Let me know in the comments below!

Many thanks to Hans-Peter Grahsl, Marta Paes, and Robin Moffatt for their feedback while writing this blog post!