Give a talk

This page presents advice on how to give a successful talk. You will likely give many different types of talks during your time at Brown: informal elevator talks, social discussions at parties, fast-forwards during CS orientation, sciviz lunch talks (which have their own explicit evaluation rubric), poster presentations at conferences, full talks at conferences, research comps proposals and defenses, thesis proposals and defenses. Each of these requires some unique understanding, but all of them share many common points. The advice below generally concerns hour-long talks, but can be adapted to any talk.

The central piece of advice, from which all the bits below may be derived, is this: the audience is always right. A talk may be about you and your work, but its real purpose is to convey ideas to your audience and to gather feedback from them. Your audience wants you to be clear, concise, efficient, and respectful. They want to feel like they understand what you're talking about, and they don't want you to waste their time or confuse them. The audience's interpretation of the talk is the reality of the talk. If you make a point but fail to convey it to the audience, you haven't really made your point. So always think about your audience when designing and refining your talk, and try to anticipate what they'll be thinking while attending your talk.

Talk Structure and Content

• Know what your audience is and tailor your talk to this audience. Different audiences expect different talk structures, expect emphasis on different points, make different assumptions, know different background, etc. When building or editing your talk, critically ask yourself: "does my audience understand this point?" "Does my audience care about this point?" Leave out details that your audience doesn't care about (as they might serve only to confuse, distract, or take time away in your talk). Make sure to include details that your audience does care about.
  • Pro tip: your audience for a proposal or defense is the faculty. Each audience member therefore: has deep knowledge about a particular computer science subfield not necessarily related to yours, has a general knowledge of computer science, thinks about problems from a technical/algorithmic/data-oriented perspective, and is probably pretty geeky and detail-oriented. They will ask deep, probing, and potentially picky questions. Organize your talk to minimize confusion for this audience, and avoid irrelevant details that members of the audience might latch onto.
• Don't give the same talk to two different audiences. The point of a talk is to convey an idea to an audience. Each different audience has a different way of receiving ideas. This means that if you give a talk to two different audiences, it should not be the same talk, even if (to your mind) it's on the same subject.
• Understand the heterogeneity of your audience. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).
• Be careful about terminology that means different things to different communities. Either be very explicit about the definitions of your terms, use unambiguous plain-language terms, or just drop them entirely and figure out a different way to present your point. An example list of problematic terms includes "greedy", "Monte Carlo", "solve", "optimal", "energy", "experiment", "model", "fit". If you're certain of the composition of your audience, some jargon of this sort may be acceptable, but remember that audiences are often more heterogeneous than you might think.
• Clearly distinguish "figures" from "illustrations". A figure is a picture that relates in a concrete and preferably quantifiable way to the work or point that you're presenting. An illustration is a generic picture that is evocative of the concept you're discussing. Trouble arises when you use a picture that could be mistaken for a figure (for example, a bar chart) as an illustration. You may mean to present it as merely an example of a result that one might get, or a way that one might care to present a certain class of data, but if your audience identifies it as a figure instead, they will immediately start digging for details that will aid in its interpretation in terms of your work. This can almost fatally derail a talk. Try hard to reduce ambiguity by either removing irrelevant details from such illustrations (leave off axis labels on your bar chart, for example, and make it look as generic as possible) or by explicitly marking ambiguous illustrations for what they are.
• Use consistent symbols between slides. If a particular glyph, color, or figure means something specific in one slide, make sure it means the same thing in others. If you're talking about the same subject in two different slides, re-use symbols to clarify the connection between them.
• Don't overstate your case. Explicitly establish the assumptions built into your work and the scope of your hypotheses and conclusions. Think like a scientist or mathematician and be very conservative: unless you specify the scope of your statements, it may be assumed that they apply universally, which is almost always not the case.
• Don't understate your case. Don't state your hypotheses, conclusions, or contributions with such general language that they don't actually claim anything. Be specific about the work that you did (or will do) and point out (implicitly or explicitly) its novelty and significance.
• Tell us a story. Your work will be most engaging when your audience understands as quickly as possible its basic context or purpose. You can achieve this by giving a simple example problem that motivates your work, an example of how someone would use your work, or an example of what your work looks like. If you can get people to care about your work in thirty seconds, put those thirty seconds at the beginning of your talk.
• Clearly formulate a "problem statement" for each contribution. The truth may be messier, but for the purposes of presenting research, it's important to summarize any given contribution in terms of the problem it aims to solve, its data inputs and outputs, and how you prove your contribution. This gives your audience the understanding necessary to truly engage with your work and to think critically about it.
• Clearly establish novelty and significance. If your audience doesn't know the related work that you're trying to improve on, show it to them and make it clear why your work is an improvement. A comparison table is a great way to do this.
• Show concrete examples. Your audience will understand what you're doing better if they have a clear picture in their minds of the format of your data. Unless your audience is composed of people who have the same background as you, there will be some basic point that you have to explain before getting into the specifics of your work. If you work with medical images and you're talking to a non-medical audience, show an example image. If you work with visualizations and you're talking to a non-viz audience, show some canonical examples.
• Emphasize contributions, not design process. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.
• Number your slides. This way, audience members who want to ask questions about specific slides can note the slide number, to make the Q&A go more smoothly.

Preparation for Your Talk

• Email a day in advance all audience members who are supposed to be there, just to remind them. This includes (for a thesis defense, for example) your advisor, your committee members, and the member of the Graduate Exams Committee who you arranged to attend. Other people may have promised they would attend; email them separately. Make sure that all your essential audience members will arrive on time.
• Practice tricky sections. Memorize, if necessary, complicated terminology, slides with a lot of text, and complicated sequences of graphical transitions. Looking at your slides rather than your audience or stumbling over your words makes you look unprofessional.
• Practice in the same room where you will give your talk. Do it a couple times, and do it earlier in the day of your talk if possible.
• If you're using Skype, get a lapel mic. The mic on your laptop may not pick up your voice well enough from across the room.
• Arrive early to set up, an hour in advance if possible. Make sure your presentation is working right, that you've got all your materials on hand, that the projector works, etc.

Presentation Style and Audience Interaction

• Ask Skyped-in audience members to mute themselves. People listening on their laptops often make a lot of noise without realizing it, and this can be incredibly distracting amplified over the speakers during your talk. I've seen this fuck up several defenses. The person can un-mute themselves if they need to ask a question.
• Pace yourself. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!
• Finish on time. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.
• Avoid excessive marketing. Brooks: "Present to inform, not to impress; if you inform, you will impress." While it is important to avoid the question "who cares about this topic/problem?", it is also important to have your audience understand enough of the technical parts that they can draw on their collective wisdom to give advice.
• Show respect for audience comments. Note that this is different from having respect; you may have respect but still not convey it to your audience, which will alienate them from you. Here are some specific recommendations for how to convey respect:
  • Pause after every question so it's clear you're thinking.
  • Say the question back to the person who asked it (in your own words) to make sure you've got it right.
  • If a question isn't clear, say you don't understand and ask them to re-ask.
  • Never cut people off, unless you can tell the rest of the audience agrees they're rambling or wasting time, and even then, be careful.
  • End every answer with "did that answer your question?" or something similar, even (especially?) if your answer is just, "that's a good point; I'll think about it".
  • Answer briefly. Don't spend a long time waffling if a simple "yes", "no", or "I don't know" will do. Defer to the commenter when in doubt.
  • Answer the question asked; don't spiral off into a discussion of something else unless it serves a point you're about to make.
  • Be efficient with your time; if your answer creates a back-and-forth discussion, try to defer it to the Q&A session so you can end your talk on time.
  • Respect ownership of ideas. When an audience member makes a suggestion during your talk, they may feel protective of their idea; it's a gift they're giving you, but it's important that you acknowledge that it comes from them. Some presenters try to engage with audience suggestions by connecting them to the work they've done, but this may be counterproductive. In the eyes of the person making the suggestion, this may seem like you're trying to take their idea away from them and claim it as your own, or that you don't understand the significance of what they're saying. Your first priority should be to acknowledge the wisdom of your audience.
  • Generally speaking, keep in mind: the audience is always right.