Presenting a Technical Talk

There is a lot of literature on public speaking, but most of it is general public speaking advice and is not geared towards presenting technical topics.  Although researchers need to master general presentation skills as well, I found that Joey Asher’s book, Even a Geek Can Speak, has a lot of good tips on how to present complex technical topics to a general audience.  These skills are useful for academics, who often have to present their research to people outside of their immediate area.  For example, although your audience at a conference talk will be domain experts, almost every other situation where you will deliver a talk (department-wide presentations, job talks, presentations to industry) entails presenting to a significant fraction of people who are not well-versed in your topic.

Presenting a good technical talk involves several different aspects.  Preparation requires (1) careful determination of your audience and your purpose for delivering a talk and (2) ample practice.  The talk itself typically involves both (1) presentation of visual aids and (2) delivery of the talk itself.  We’ll explore each of these aspects in depth below.

Determine Your Audience and Purpose

Academia presents many opportunities to present your research in a variety of settings, and these presentations can have many purposes.  Your purpose and audience determines the talk’s content—including how you motivate your work, the level of detail that you choose to include or omit, whether you show graphs or simply summarize results, and so forth.  Therefore, your first goal should be to determine your purpose and your audience.  You must connect with your audience to deliver an effective talk, and the ways that you connect to your audience will differ depending on your purpose and your audience.

Consider the following purposes for giving a talk, and how you might tailor your approach depending on differing purposes (and audiences):

• Encourage other researchers to read your paper(s), or at least appreciate your work. Many published papers ultimately entail a presentation of the paper at a conference.   In these cases, your purpose may be to encourage other researchers in your field to read your paper.  The talk is, in essence, an advertisement for the paper.  Your goal and purpose is to convince other researchers in your area that you have done something intellectually deep and interesting, and possibly to get them to build on your results.  In a conference talk, your foremost aim is to help other researchers understand and appreciate your work, and to encourage them to read the paper for more details.  Distilling complex research contributions into a short conference talk can be extremely challenging; for this reason, these types of talks require significant iteration.
• Find collaborators.  You may wish to present a piece of work to researchers across disciplines to encourage other researchers to work with you.  For example, you may be working on a particular problem and find that you need to enlist the help of a domain expert in another area.  Sometimes, presenting your work to the experts in that area is a way to “cast a net” to find a collaborator who appreciates your problem and shares your passion.  In this type of talk, your goal is to make your content as accessible as possible to researchers in that area.  If you are presenting to researchers in another specific area (e.g., if you are a networking researcher presenting to theoreticians), you will need to tailor your vocabulary to the audience (avoiding domain-specific jargon at all costs), and it can also help to draw analogies to concepts or techniques in the area that your audience is more familiar with (e.g., a networking researcher may be able to abstract the details of underlying protocol implementations and present a problem in terms of a simple graph).
• Obtain feedback.  In the early stages of working on a particular research problem, you may want to give a talk to obtain feedback on your problem formulation, your approach or solution, or some other aspect of your work.  Designing a talk to obtain the feedback that you want requires engaging the audience on your problem so that they understand what you are working on and care enough about the problem to give you feedback on it.  In this type of talk, your audience may typically be a smaller group of trusted researchers, such as other students and faculty members in your research group, or a small community of researchers who may convene for a workshop that is focused on a niche topic.  You may be presenting to other colleagues with whom you may have pre-existing relationships or trust.  You may also deliver these talks in more intimate settings (e.g., research group meetings, small workshops).  These talks need not be completely polished, but they still need to be coherent and clear—if your audience cannot understand your thought process or cannot appreciate the importance of your problem, they may not be motivated to help, or the feedback that they provide may be completely off-target.

The “Message Objective”: Help the talk listeners achieve their goals.  While each of these scenarios has a different audience and requires a different approach to the talk, all of them require “connecting” with the audience.  Connecting with an audience first requires determining why someone is listening to your talk in the first place.  Typically every audience member has a reason or goal for attending the talk.  A listener’s goal may be to learn more about the topic area (at a conference); to assess you, your research, or your teaching capability (at a job talk); to find new collaborators (at a workshop or working meeting); or to give you feedback (at a practice talk).  In each case, you want to help the listener achieve their goals.  Otherwise, they will feel like they are “not getting anything out of your talk” and quickly tune out.  If you can connect your talk with the listener’s goals, you will have an easier time keeping your audience engaged.

Every talk should have a message objective, which has two components: (1) persuading the audience to do something (read your paper, work with you, give you feedback); and (2) explaining what’s in it for them.  For example, your message objective might be “By working with me on this problem, you’ll get to work on a practical problem in an under-explored area.” or “By downloading my software, you’ll be able to solve the software troubleshooting problems that you’ve been having so much frustration with.”  or “By reading my paper, you’ll learn techniques that you could apply to your own research.” or “By giving me a job, you will gain a great colleague.”  There are a variety of message objectives, but every talk should have one.

Practice, Practice, Practice

Never give any talk without some form of practice.  Typically, you should deliver your practice talk to some of your colleagues.  For “lower stakes” presentations (e.g., working meetings), you may be able to get away with a quick run-through by yourself, but as a general rule, you should always practice.  Any talk represents you, your work, your advisor, and your institution, so it is generally a good idea to incorporate as much practice as you can practically achieve.

For “high-stakes” talks (e.g., job talks, conference talks), where you must communicate the value of your work to an audience with a variety of backgrounds, biases, or both, it is critical to hone your message and delivery.  Talks at conferences are, in some sense, “previews” of what your job talk will eventually become, and they contribute to your reputation as a researcher.  People remember clearly delivered talks; on the other hand, if your talk is not clear, the best-case scenario is that they forget the talk (and that you delivered it).

My own rule of thumb is that if I can mentally go through the talk in my head—in terms of knowing slide order, and roughly how I will start each slide—then my delivery will be smooth.  If I can’t mentally “rehearse” my slide order, I know I’m not that well-prepared.

Practice makes more. Practicing is absolutely essential, but practicing alone is not enough—feedback and iteration is essential.  The old adage “practice makes perfect” isn’t quite right.  If  you practice the wrong habits repeatedly, you’ll merely solidify bad habits.  Therefore, it’s best to practice with other listeners in the room, to determine if your talk needs revisions and course corrections.  If possible, try to have people listen to your practice talk who share the background and biases of the audience that you’ll eventually present to.  If you are preparing a department-wide colloquium or job talk, packing the room with only researchers in your area is not likely to yield the best feedback; rather, you want people from outside your area to also listen to the talk, to simulate the environment, questions, and reactions that you will receive at the talk itself.

Practice.  Then, practice some more.  Depending on your purpose and audience, you may need to practice a lot.  You will not get this right on the first “take”, and, just as you would revise a paper, revising a talk to match the audience and your purpose takes iteration.   Just as you would obtain feedback on a paper draft, rewrite it based on feedback, and then read it again, you must re-deliver your talk after implementing feedback.  In doing so, you may find that some suggestions didn’t work that well, or that you need to refine your implementation of certain suggestions.  Also, every revision disrupts your level of comfort with the talk, because content and flow keeps changing.   Practice talks help restore comfort and confidence with revised slides and material.

Don’t let the lack of an audience prevent you from getting feedback.  Although it is always better to practice delivering a talk in person, in front of a live audience, sometimes circumstances don’t allow it.  Scheduling practice talks can be difficult sometimes, particularly with busy, overcommitted faculty members.  You may happen to be busy or traveling around the time of the conference, and schedules may not line up.  In these trying circumstances, though, you can still do better than simply practicing by yourself (which does not give you the same type of “performance” practice) or mailing around copies of slides (which can often be unintelligible—or hard to interpret or react to—without the appropriate “audio track”).  In these circumstances, I recommend Josh Reich’s “Delay Tolerant Talk Preparation“.

Visuals

A significant portion of your talk preparation will include preparing the appropriate visuals.  The point of visuals should be to assist you in your delivery of material, but the focus should remain on you, your speaking, and the work.  Slides should only serve as visuals to help your delivery; they are there to illustrate, clarify, solidify, or corroborate what you are saying.  Anything that distracts from you or what you are saying is not productive.

Keep it simple and spartan.  Some presentations have flashy graphics, animations, colors, and design elements.  Generally speaking, none of these “frills” matter, and they can actually backfire.  I remember attending one particular conference talk that had particularly flashy animations (zooms, flyovers of network graphs, etc.).  After the talk, nobody was talking about the work; rather, people were discussing how flashy the talk was.  I find that black, sans serif text on a white background with minimal animation works well.  Similarly, keep figures and plots as simple as possible while still conveying the point.  People are bad at multitasking; if they are reading your slide (or otherwise trying to digest it), they are almost certainly not listening to what you have to say.  Keep your visuals simple, so that people can return to paying attention to what have to say as quickly as possible.

Don’t use text when an appropriate figure will do.  If a picture is worth a thousand words, then the limited real estate of a slide suggests that you should use figures whenever possible.  That said, the keyword is “appropriate” figure.  Figures should be as simple as possible.  They should omit details of the concept that you are not going to describe, or are not central to the idea you are presenting.  The goal of a figure is illustration, not necessarily accuracy.  For example, when presenting a network architecture, it may be reasonable to leave out certain nodes, edges, or system components that aren’t central to the idea.

Don’t use a graph when an appropriate phrase will do. Sometimes a graph is a great way to illustrate a point, but presenting graphs is not “free”—they require significant audience effort and bandwidth to digest, so you should always ask yourself if a simple summary of the result will do (especially if the audience can find the details and graphs in the paper).  Writing “our system reduced median latency by 20%” might convey a point much more clearly and efficiently than a complicated graph like a cumulative distribution function, particularly if your audience is not used to reading that type of graph.  Remember that for every graph you include, you need to explain what the graph is, what data or experiment was used to present it, what the axes mean, and how to read it.  If I must include a plot, I always put a box on the slide with an arrow pointing to the part of the graph that I want people to look at that conveys the main result.  If the result is a reduction in median latency by 20%, for example, draw an arrow on the slide with a text box that states the main result.  This way, even if people don’t understand how to read the graph, they might still be able to digest the main result.

Beware small fonts and strange colors.  Fonts should always be at least 24 point font.  As far as colors are concerned, beware the projector.  Every projector is different, and certain colors do not show up well.  Also, some audience members may be color blind.  Therefore, take care in choosing colors that project well, and try to design your slides so that understanding them does not depend on the ability to decipher color.  For example, lines on a graph should not only have different colors, but also different markers for the data points on the lines.   White text on black backgrounds is also generally a bad idea: Black is the absence of light, and projectors are designed to project light. Therefore, black is never truly black, and on some projectors, poor contrast can make white text very tough to read.  Also, people are generally used to reading black text on white backgrounds (books, magazines, etc.), and inverting this mode is distracting at best.

Delivery

Practice.  See above.  It’s worth mentioning again.  A smooth delivery depends on lots of practice.  As you gain more comfort with your talk, filler words (“um”, “like”, “you see”, and so forth) will disappear.

Tell a story.  The human mind is very good at processing and remembering stories.  People love stories and are much more likely to stay engaged if you tell a good one.  Stories always have a beginning, middle, and and end.  A good story also typically also has a “dramatic arc”, which may build anticipation, contain surprises in the plot, and otherwise manipulate the reader’s emotions.

• The beginning of your talk is straightforward: it has a short (and easily repeatable) summary of the topic of the talk and your message objective.  (“This talk is about [topic]… By the end of the talk, [message objective]…”).
• The middle of the talk should start with a “hook” that draws the audience in and helps them identify with your topic or problem.  Tell an anecdote.  Relate your work to a current event.  Present a surprising statistic.  Ask a question.  Do something concrete to engage your listeners within the first minute, or you may never get them back.
• At the end of the talk, restate your message objective and leave them with no more than three things that you want them to remember from the talk. If you have one thing you particularly want the audience to remember, tell them.  Also, tell them what you want them to do as a result of listening to the talk.  Do you want them to contact you? Read the paper? Try out your software? Give you feedback?  If you don’t tell people what you want them to do, they won’t do it.  Also, make it easy for them to do it.  When answering questions at the end of the talk, leave your conclusion slide up with the 1–3 takeaway points, and “instructions” for what you want them to do (e.g., if you want them to download code, provide a URL; if you want them to contact you, provide an email address).

Slow down.  Nobody knows your topic as well as you do.   In a technical talk, people are not only listening to what you are saying, they are processing the information as you present it, typically learning it for the first time.  Talk slowly.  The temptation to race is pretty significant with slides because you aren’t bound to discuss everything that’s on a slide, and you may even forget to explain something on a slide if you are going too fast (in fact, I find that using slides in classroom lectures is much less effective than writing on a whiteboard, which forces me to slow down my delivery).

In addition to cognitive reasons for slowing down, acoustics also play a role.  In a large room with your voice being piped through a microphone, echoes and delays are at play, and speaking too quickly can obscure your delivery.  My general rule of thumb is that each slide should take about 1-2 minutes.  If you are progressing through slides more quickly than that, you’re going too fast.  If you feel as though you are speaking too slowly, you are probably going at about the right pace.

Breathe.  Remember to regularly take deep breaths.  This will slow you down, but it will also help you gain some comfort with silence.  It can be terrifying to stand in front of a group without sound coming out of your mouth, so a second of silence can feel like an eternity.  However, people appreciate a slower pace, and unless your silence is erratic or unexpected, it will likely improve your delivery.  Breathing is also a useful tool for eliminating filler words such as “um”.  The next time you are not sure what to say next in a talk, try: (1) pausing; (2) breathing in deeply.  It takes some practice to breathe in rather than using a filler word, but its effects are magical: with no change to actual content (and no additional practice), your delivery sounds pensive and thoughtful, rather than bumbling and unrehearsed.

Use vocal energy.  Volume adds emphasis.  Whispering (assuming you can still be heard) can act like a magnet, drawing people in.  Speed can energize.  A slower pace can inspire wonder or cause people to pay closer attention.  Pauses are useful for emphasis.   Avoid a monotone presentation.  Some parts of a presentation are clearly more important than others—the beginning where you get people interested, the main result, the “sync points” where you draw in audience members whose attention may have drifted—use vocal energy to keep the audience on track.

Get the little stuff out of the way.  Getting comfortable with the room in advance can help you relax, as well, so that you don’t have to worry about the “little things”.  If possible, go stand on the podium before you give your talk so you can get comfortable with “the view” that you will have when giving the talk.  Make sure that your laptop works with the display to avoid last-minute panics.  Always have a last resort: Put a backup copy of your slides on the Web in a commonly readable format (e.g., PDF), so that, if all else fails, you can quickly load them up on someone else’s laptop.

Relax and have fun.  Remember that, if you are presenting your own research, you know your topic better than anyone else in the room.  Relax and stay confident.  Most importantly, have fun.  With the appropriate preparation, giving talks can be quite a lot of fun.  It’s a way to advertise your work, meet new people, educate, and increase the impact of your work.  It can also be a celebration of an excellent piece of work.  Make the most of every opportunity!