The Developer Advocacy Handbook

If you find this helpful, you can buy me a coffee.

Delivering presentations tips: timekeeping and more

Mind the gap

Talks and presentations are a great tool. They allow you to bring to an audience what excites you in an engaging and personal manner. An audience that gives you immediate feedback – a lot of it in the form of body language and reactions. To me, It is one of the most enjoyable and interactive parts of being a developer advocate.

Fact: The start of any great presentation is excitement about the subject matter. If you don't have that you might as well not be out there.

We already covered that a few times in this handbook. In this chapter I want to cover a different problem of presenting. Keeping time and - more importantly – keeping the audience interested.

The following information revolves around presentations at conferences. Presentations that are your slot in the program and stand alone. Not those introducing a workshop or during a company meeting. Many of the things I will cover here are applicable to those, too, but there are different nuances to take into consideration.

How will I fit all of this in X minutes?

As someone who starts out presenting, you will freak out about time keeping – a lot. That's natural and also OK. We all do that. People who just started presenting fall into two categories. Those who rehearse every second of the talk and get derailed by disruptions and those that appear far too fast in their delivery.

Fact: We tend to run up stairs rather than down them. The reason is that stressful and tiring tasks appear easier when you get through them quicker.

That's also the reason why the delivery of your talk will always be faster than the rehearsal or how you planned it. The adrenaline rush you get from presenting on stage does that to you. That's OK. It makes you human, approachable and brings the audience to your side. You did the thing we all are scared of – presenting to a group – and you are still scared of it. This makes you an honest, technical presenter – not a slick and perfect actor or politician.

Warning: When you get more into the routine of presenting, this automatic speeding up can become dangerous. The excitement doesn't wane – all you do is getting used to being fast.

That's why over time, your decks become larger and you are tempted to add more and more to your talks. You got time, so you might as well use that time, right? People should get something for their money and more is always better, right? Not always…

Less is more

Don't fall into that trap. A great talk makes only a few points all revolving around one central theme. That's why conferences focused on presenting have short talks. The sixteen to eighteen minutes limit TED imposes on talks is not a trick to get more content. It is a great limit as this is the time an audience is alert and able to take in things. It also forces the presenters to think about their talks more: you have a limited time to make your point. This means you will remove as much cruft and fluff as you can. And you pick the more punchy and juicy bits of information.

This is something to remember: start with a single point you want to make. This doesn't need to be a sound bite (although these are important). It can be many things:

Start with your point and then add the rest around it. Much like a good story has a build-up, a climax and an aftermath, so should your presentations. In essence, your focus should be what do I want people to remember of my talk?. This means you need to try to get into the heads of the audience a bit.

You know what you are talking about. Try to remember what was the main "A-hah!" moment that got you to there. This is your starting point. There is a reason why you are giving a presentation. The story you want to tell about the topic of your talk is that reason. Not the topic itself. You sell the topic - you don't have to own all the information. This is important. There are a lot of presenters out there that tell you all the steps to take to achieve a goal. But you’ll remember those that inspired you to learn more about the subject in your own way.

Your talk is only extremely important to you

There are a few things we need to consider when we talk about technical presentations to audiences at conferences:

Your job as a presenter is to make a topic interesting for people to try it out themselves. You open the door, you lead the way, and then they can spread out and find their own way around.

This is the true art of presenting. Stage time isn't show and tell time. This is what video trainings, workshops, tutorials or one on one trainings are about. Stage time at technical events is "here is why this is something worth your time looking into". Or "here is the state of research - help us" time. Not "I know and I am so excited I will show you everything I found" time.

This can be tough to avoid as it is fun to show off on stage. It feels good to share what you had to do to get somewhere. It is great to show how effective using a certain tool or way of working makes you.

Warning: It is important to remember that people are not you, and everybody has a different way of learning and working. Showing off what works for you and how it makes you better can come across as condescending or arrogant. Remember that the audience most likely know their stuff, too. And they want to show off that they do. That's why you will get aggressive feedback on social media during and after your talk when you came across as too "in your face" with your product or your technical knowledge.

Map out more information

The simplest way to keep on time and use the time you have to bring across the memorable messages is to delegate the information. Instead of explaining everything yourself, you point to resources people can look up in their free time. You can reference a few things this way:

One issue far too many people worry about is not being technical enough. We all hate sales pitches - there’s no doubt about it. A presentation as a format has a lot of teaching benefits in comparison to coding exercises. That’s why you shouldn’t feel bad for using a slide deck instead of opening the Terminal as the tool of your presentation. Which brings me to the most likely thing to eat into your time budget: code exercises and live demos.

Live coding?

I’ve had many discussions about this with other people doing developer outreach. We see live coding as the most amazing level of awesomeness as a technical presenter. It shows that you are still a coder. It shows you walk the walk and not only talk the talk. It means that everybody can repeat what you showed.

Except, it doesn’t. Don’t get me wrong, I’ve seen amazing live coding presentations. And they are always a big success with the audience. Some presenters manage to make code a performance and keep it entertaining and exciting. Those are exceptional people though, or the talk and the live code has been extremely well prepared.

When asking the same excited audience members a few hours later what the code was about or how the presenter solved a certain problem you get a different picture. Live coding is exciting, but it also assumes that the people in the audience work like you and use the same tools you do. Many a time I’ve seen audience reactions getting off-track. People talked on Twitter about the Terminal setup or the code editor the presenter used rather than listening and reflecting on the topic of the talk. By coding on stage, you allow people to get distracted by their pet setups and ways to work and to show those off. It can be a major distraction. Or it can even mean that people don't listen to you at all - after all you don't use their environment.

Live coding has a lot of unknowns that can derail your talk and eat into your time allotment. A lot of things can and will go wrong:

A lot of live coding is the “here, anyone can do this in one minute” pitch, which can come across as tiring. As developers, we get promised things that make our lives easier all the time. We also keep seeing them fail. And we’ve seen a lot of “one minute demos” of things we never, ever had to in our jobs afterwards.

Warning: If it feels too simple to do, it either isn’t worth doing or it is insulting to our jobs as developers. We’re experts, and expert tools should make us build higher quality products - not make us redundant.

That said, if you are firm in what you do and the conference is a technical one where people expect things to break as they are experimental - go wild. I’m not here to stop you from being as creative as you can be in your own, personal way.

Consider doing screencasts of code and/or product demos and talk over them. The reason is that talks should be repeatable and their content reusable. Using a screencast, you can speed up the loading or compilation parts of the video and you know the length of the exercise. You can concentrate on coding and on stage you can concentrate on giving a live commentary. Doing both is hard because typing something different than you say is not a natural thing to do.

Avoid questions

One of the worst things to do during a presentation is to allow for questions. I know, earlier in the book I said that’s a good thing. But that wasn’t exclusively about conference presentations. While offering the option to ask questions may seem like a great service to the audience and makes things appear more interactive, there is not much benefit to it. In a presentation that is part of a workshop to introduce a part of the workshop, that’s fine. At a conference, where you’re on stage and you have an allotted amount of time, it is nothing but distracting:

Make it obvious that there will be time for questions after the talk. Tell people where to find you during the conference and how to contact you. Re-assure people that your talk will have a lot of information to come so that there is a good chance their questions will get answered. In essence, show people that this is a planned talk with a fixed length and they will be much more receptive and prick up their ears.

Things to cut

There are a few things we consider good style to have in slide decks, but are on closer inspection not as useful. They can work for you, but I found cutting them had no ill effects in my talks:

Talk fillers

Once you are happy with your talk and you realise you have nothing to remove, what can you put in to add value and fill up the rest of the time? There are a few things that can be important:

Planning Your Talk Summary

Plan your talk around a central theme and single learning point you want to get across. Add more around it to tell a story. That way you can still take things out should you get less time to speak as your predecessor used up too much. Your time is limited, the audience is not listening to every word you say. Make it worth your and their while by having great things to say, materials that help keeping the pace and avoid those that can cost a lot of time when they go wrong. Murphy is watching you. Cheat him by being prepared and offering longer Q&A if you need to.

Next: Things not to say on stage