Knowing how to communicate your work is an important skill for an engineer to have. Unfortunately, communication skills, both written and oral, are very often neglected in technical jobs. The attitude that strong technical skills are sufficient, and in particular for software engineers that code says it all, is rather prevalent.
Not everyone is a great communicator, and I won’t claim that I’m a great communicator either, but I have given a good number of presentations throughout my career, and I have learned a few lessons, sometimes with live hiccups. I strongly believe that a lot of the mediocre talks I’ve attended could have been way better with a bit of guidance. My goal with this post is to share some guidelines on what I do to prepare for talks, and shed some light on the art of giving technical presentations.
This post is not supposed to be a lecture on how to prepare presentations. I want instead to share some experience that might help engineers at any stage of their careers to prepare their talks. As my experience is primarily with software development, my talks have been about that, when not about algorithms. The examples are oriented towards my experience, but the guidelines should be general and applicable across areas.
Even though using Powerpoint slides isn’t the only way to give a talk as one could, for example, use a whiteboard, I’ll assume that you have to prepare a Powerpoint slide deck as it is currently the prevalent way to present.
Before you start with your deck
You have a talk to give and you must know what it is about by now. Perhaps you proposed a talk to a conference that got accepted or you’re told at work to give a presentation. Plan what story you want to tell and build a flow for yourself or perhaps use tools like a mind map to help you structure message and flow.
For example, say that you have developed a new library for processing log messages that makes debugging much easier, and you are going to talk about it. There is some motivation for doing such a library and you want to tell your audience about it before you even go talk about the library itself. You should also consider explaining even if briefly your understanding of logging so that you are on the same page with your audience. At some point, you should describe the library and how to use it, and conclude with your experience using it. The flow consists precisely of organizing all these parts in the way that you are going to explain them during your presentation.
Let’s elaborate on a few relevant points.
Know the topic well
Very often you are in the position to give a presentation because you are a person who knows a lot about the talk topic or perhaps it is time to deliver that conference talk. There are other cases in which you have to give a talk to represent your team, and you don’t necessarily know everything in detail. Try to learn as much as possible as part of preparing, even before you start thinking about your slide deck. If you don’t know what you have to talk about well, then odds are that your presentation won’t be great.
Even if you know the topic well, perhaps you don’t know the related work that well. Try to learn as much about that as possible so that you’re ready to answer questions like “How does your stuff compare with X?”. You can address such questions implicitly or explicitly in your slides, or perhaps leave for someone in the audience to ask about it. It is important that you know the answer, though.
Know your audience
Try to understand who you’ll be talking to before you go prepare the slides. Presenting to a small group of experts is not the same as presenting to a group of people who know little about your topic or even not the same as presenting at a conference, where you can have a pretty diverse group. Depending on your audience, you’ll be selecting a different way to present your topic and even the content that you’ll be presenting.
Presenting to a knowledgeable audience means that you need to spend less time on context and on the basics. As your audience moves towards less knowledgeable in the spectrum, you need to spend more time on context and basics.
A presentation should have roughly three main parts: context, main body and conclusion.
Every talk needs to start with giving some context. The title is typically the first indicator to the audience of what the talk is about, but in the initial slides, it is critical to say more about what you want to cover and set it up so that your audience follows the presentation. For an audience with mixed expertise, which is very often the case, it is important to give enough detail so that as many people as possible, ideally everyone, can follow. Of course, spending too much time with context and background both uses precious talk time and gets knowledgeable people bored; it is important to strike a balance, so think about the content carefully.
In a technical talk, it is also critical that you clearly state what problem you are trying to solve. If I start telling you about a new protocol without telling you why I even need a new protocol, then it won’t be clear to you whether the protocol is satisfying all properties it needs to. A crispy problem statement helps your audience understand your work.
Once you have some context and likely a problem statement, the next step is to determine how to explain the main content of the presentation. The main advice to give here is to calibrate the amount of content with the time you have to explain. Trying to squeeze too much into little time is likely to result in a talk that is hard to follow. It is often better to explain less, and make it understandable so that the audience learns something new.
Finally, make sure to conclude with at least a few takeaway bullets, say 3-5. With all the distractions one has these days (cell phone apps, laptop), a significant part of the audience will look elsewhere occasionally. Even if they don’t, we can’t expect the audience to grasp 100% of what the speaker explained. The closing slides give the presenter a chance to remind the audience of key messages. A more sophisticated conclusion section tries to bring together aspects discussed in the main body and elaborate on them. For example, after presenting some performance results, conclude what kind of impact it can have on future systems.
How to start
The beginning of a presentation is possibly the most awkward moment of a presentation. You are in front of your audience and all of a sudden you are talking to them. What you say and show in the beginning of the presentation is important to engage the audience. My suggestion is to start slow and high level. Introduce yourself and make sure to connect the title to what you are going to be talking about. It is very typical that presenters start with some intuition about why the problem you address in the presentation is relevant. In our toy logging library example, it could be about the amount of time, effort and money spent on debugging.
Getting to the slides
At this point, you have a pretty good idea of what flow to implement, and it is time to project that flow onto slides. Here are a few things to keep in mind.
It is very important to prepare the content according to how long your talk slot is. If you are given 15 minutes, and you don’t think about time, you might end up having content for an hour. The result is likely to be frustrating for you, for your audience or both. In conferences, for example, the session chair will typically warn you towards the end of the slot, and will eventually cut you off if you can’t finish on time. It is very important to be respectful of the time constraints, especially for presentations involving a large audience or that are part of a program involving multiple presentations.
A rule of thumb that I hear frequently is 2 slides for every 3 minutes. That doesn’t really work for me, but it may work for you. If it doesn’t work for you, then it is important that you find some guidance on how many slides you should be putting together. In my slides, I tend to think of sections, and try to calibrate time by thinking about how much time I need in each section and how many sections I need to cover.
Slides are both for you and your audience
Slides serve basically two purposes: to remind the presenter of the flow and to support what the presenter is already saying. When preparing slides, it is better to not make them too busy. A lot of words in a slide will make the audience spend a good amount of time reading and not paying attention to you. The same for very busy diagrams. I have a separate note on animations below.
My advice here is to plan the content of slides both to help you remember the flow and what you planned on saying
Transitions are important
It is very important to connect the speech between slides, otherwise the presentation might end up feeling like a collection of disjoint points. I give quite a bit of importance to the slide transitions, and when rehearsing for a presentation, I try to make sure that I know clearly what the key points to say are.
For example, you have the last slide about general logging and what you were missing in existing libraries. The next slide starts talking about the library itself, so if you do not explain the transition, it might sound awkward to the audience the abrupt change of topics.
Graphics are important
I acknowledge that this point is somewhat arguable. A good presentation shouldn’t be based on good graphics alone. If you spend all your time doing awesome drawings, but when you get to stage you can’t deliver a convincing argument, then it won’t help much. As I see it, having good graphics shows that you’ve put effort to prepare a good presentation rather that simply doing some ugly diagrams quickly. They make the presentation visually appealing and combined with a good speech increase the chances of a more engaging talk.
It is important to say that there is a bit of taste involved when I say “good graphics”. I find slides that are heavily colored or visually too busy not great.
Animations and transition effects
I never use transition effects and I try to avoid Powerpoint animations whenever I can. I dislike transition effects, I feel that they add nothing to a presentation, except for distraction. As for animations, I avoid Powerpoint animations as much as possible, and often I implement animations as a sequence of slides, rather than one animated slide. I find the way of assembling non-trivial animations distracting as I end up spending a lot of time simply engineering an animation.
Incrementally building a scenario, independent of how I implement it, is a powerful way of conveying an idea. Instead of throwing a complex picture at your audience in a single shot, building that picture incrementally enables a better understanding of the scenario or concept that you are trying to show.
Talk day is approaching – How to prepare
You have your deck ready and now you need to make sure you know how to deliver the presentation. Here are a few hints:
Don’t read out slides
Reading slides is not a good way to present. The people in the audience should be able to read by themselves, so what is it that you are adding as a presenter by reading slides out loud? The slide deck is there to support what you have to say, and not the other way around.
Knowing what you have to say well doesn’t mean memorizing every word you have to say. If you try to do that and you get nervous, then odds are that you’ll forget and will get more nervous, which in turn will make you forget and mumble more. Even if you are able to remember it all and you don’t get nervous, it will sound stiff and maybe a bit robotic. Don’t memorize the whole speech.
Instead of memorizing your whole speech, try to memorize the message you want to deliver, like the key points and how to connect concepts. Those key elements are the core of your presentation, so make sure to know them well and do not forget to deliver them.
Work on the transitions
Slides typically have different titles and content, so they may feel disconnected when skimming through deck, but part of your role as a presenter is to get the audience to make sense of it all and explain how concepts connect. What you say between slides is what connects them. Make sure that you know what to say to connect slides well and make the presentation feel connected.
Deck is ready and rehearsed, and you are now in from of your audience.
Enjoy being on stage
It is really important that you feel comfortable presenting. By being comfortable, you deliver a better presentation and project confidence to the audience. When I started giving talks, I used to tell myself a lot prior to talks that giving talks is a lot of fun. It helped me to be less nervous. If you are comfortable on stage, then the chances of delivering a successful talk are higher. If it doesn’t come naturally to you, find a a way to convince yourself that it is fun.
Keep track of time
You have made sure to prepare the right number of slides and you have a released a few times. Because I don’t memorize my speeches, the time I take to deliver a talk varies each time I give it. To make sure that I’m within the time slot I’ve been assigned, I pay attention to the computer clock or whatever other time reference available in front of me. I use the sections I mentioned above as references in the presentation, and I tend to check the time at section boundaries to give me a sense of whether I’m going too fast or too slow. In general, make sure you have a visible time reference.
If you have to give a demo as part of your presentations, then make sure to keep it within the time limit you’ve been given. Live demos are tricky as you are dealing with computer systems, and we know that they break much more easily than we would like. It is good practice to think ahead of time how to react in the case the demo doesn’t work. You may want to have a recorded video as a backup plan.
If your talk was engaging enough, then you’ll surely get some questions. Try to anticipate some of the questions and prepare to answer them. Answering questions well is part of delivering a successful talk. Decide ahead of time whether you want to leave time for questions (perhaps your host will enforce it).
Giving a talk is an opportunity to tell some audience your story, so take it seriously. If you are just getting into giving technical presentations, then the above might sound overwhelming. The first few talks require a good amount of preparation, so make sure you do spend that time to put it together. Over time, with more presentations, some of the points above will come naturally and you’ll even learn your own lessons. Keep in mind that your audience is dedicating some of their time to listen to you, so make sure that it is worth their time and that you convey your message.