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 central piece of advice, from which all the bits below may be derived, is this: the audience is always right. This talk may be about you and your work, but the people evaluating its quality are the audience. MYour 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'

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. 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. When building or editing your talk, critically ask yourself: "does my audience understand this point?" "Does my audience care about this point?"
• 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 audiences are often more heterogeneous than you might think. For example, for a thesis proposal presentation, your audience includes people from disciplines as diverse as natural language processing, computation theory, optimization theory, 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, for example).
• 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.

Presentation Style and Audience Interaction

• 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.
• 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 the ownership that the person asking a question or making a comment has over their ideas. 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.
• Make sure all key audience members are there. For a proposal or defense, this includes your committee members and a member of the departmental Graduate Exams Committee. Make sure that your committee and exam committee member are all there on time. Jadrian didn't have an exam committee member at all, and was fortunate that one came serendipitously. Ben Raphael was late, but knew and had had some issues with traffic that would have been difficult to avoid.
• Avoid excessive sales/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 committee understand enough of the technical parts that they can draw on their collective wisdom to give advice.
• Answer questions with care. Rephrase the question, to make sure you are understanding the question that is being asked. During the presentation, try to answer briefly. Only go into a longer answer if the point brings up something you were going to present or something that you are willing to drop part of your planned presentation to include. With the committee alone, longer responses are good.

I think I explained that I aimed my talk at the wrong audience: I designed it for a general audience, not for CS people (and in particular, not for CS faculty who are very critically evaluating my work, plans for future work, and ability to work seriously). For the most part, your talk was aimed exactly right, but at some points I think it was also aimed at a *different* wrong audience than mine was: you're talking as though you were at ISMRM, rather than the CIT.

Nobody in the CIT cares about double PGSE. Nobody in the CIT knows what diffusion MRI or macaques are. Nobody in the CIT knows the clinical or research neuroscience context for the kinds of tools you're building, nor the problems you're trying to solve with them. In some cases (double PGSE), this means you don't have to bother talking about certain things. In others (diffusion MRI, macaques, research context), this means you have to explain yourself *just enough* to motivate the work you're doing, explain the data you're working with, define central terms, and make people feel like they understand enough to ask intelligent questions about *your work*, which is the true focus of the event. This may mean simplifying or leaving things out that someone in an ISMRM audience would feel were necessary to discuss, or mentioning things that an ISMRM-er would feel were unnecessary. But you're not at ISMRM; you're in the CIT.

Second thing:

In working with David, planning our research, and discussing our research with each other, we conceive of it as a sequence of experiments that we learn things from, where each experiment develops into or informs the development of the next. It's intuitive for us to explain our research in this way, to show it as a sequence of intellectual developments. Based on the feedback to my proposal talk, however, I believe that presenting it to the department this way is a mistake.

Do you remember from my talk the "big picture" diagram that showed the multiple phases of my research, connected by arrows? Three projects involving macrostructure, two involving microstructure, and one that combined them. To me, the arrows indicate intellectual progress, the development of a set of research ideas. To the audience, I'm pretty sure they indicated a data flow, which confused a lot of people, and understandably so, because they're *not* data flows.

You use arrows in a similar way in a couple places, and I think they caused similar confusion in your practice talk tonight.

The lesson here, I think, is that you shouldn't worry a lot about explaining the intellectual framework of your research, how each experiment or contribution leads into the next. Instead, you should just present each research item as a separate entity (say, a numbered or bulleted list of research projects), and discuss the connections between them as a secondary point. Talk about each one as a more-or-less standalone research activity, as it must be in your publications. Introduce each one by explaining the problem it aims to solve, its inputs, its outputs, and how you'll prove your contribution. Then explain that introductory outline in more detail if necessary.

After you've gotten all of that out of the way, you can explain to the audience how your research forms a cohesive and flowing whole, but at first they want "just the facts". Anything else will confuse them at best, and possibly alienate them or make them think you're trying to be deceptive at worst.

Okay, so that's that. Here are my notes, with additional comments in brackets.

---

INTRO

Number your slides

Scale bars on micrographs

Awesome intro. Question slide ["how do we do this non-invasively?"] is a great idea.

[Discussion afterward indicated that it would help for you to include some more motivation early in your talk. Here's why we study the brain, here's how a researcher could use my tools. Show how your tools match step-by-step the same investigative procedure that you describe for traditional neuroanatomy and dissection on the slides with the black backgrounds.]

Practice your thesis statement so you can say it smoothly.

Overview based on thesis statement is good too.

[Also important to explain briefly what diffusion MRI data describe and what they look like.]

---

QUALITATIVE TOOLS

[Important to explain that tractography curves are a standard representation of the brain derived from diffusion MRI data, and that your quantitative tools take these curves as inputs. Define inputs (tractography curves) and outputs (manually selected sets of curves that correspond to an experimenter's tract of interest) for your contributions.]

Compare your TOI methods to the usual methods. Why is your technique easier? [Your audience doesn't know the state of the art or what people usually use. Introducing that quickly will make them understand why there's a need to improve these tools and why your technique is an improvement, even without you demonstrating it based on your experiments.]

Do you have anything stronger than expert feedback? Show charts. "Expert feedback" seems weak and anecdotal. [Some of your results are anecdotal; some are quantitative. Presented the way you currently have them, it looks like *all* your results are anecdotal. People will disregard the non-quantitative stuff for the most part, and that's okay. Be sure they get to see the stuff they won't disregard.]

---

QUANTITATIVE METHODS

[Clearly state that now you're working with diffusion MRI data in individual voxels, with the goal of recovering microstructure measures. Remember, what computer scientists understand is input -> (your transformation) -> output. Use pictures to show what an individual voxel looks like. This should make it clear that you're not talking about tractography curves anymore.]

[This could be a good place to put your ONE mention of double-PGSE, which you can just describe as an "alternate technique for diffusion MRI scanning that provides some additional information in its output" or something like that. After that, no need to mention double-PGSE again, though in your related-work comparison table you can leave references to the acquisition used in each process as long as they're de-emphasized.]

Single of "radii" is "radius"

Assumptions slide is great. Contrast to related models?

Explain q-value briefly [or leave out references to it if possible. You could instead just mention that some techniques use single-PGSE, which requires clinically infeasible acquisition times.]

Connection between citations and what you're talking about should be clear. If it's not obvious (that is, obvious to your audience without you explaining, referencing, or otherwise talking about it, which is

• extremely* rare) or explicit (that is, explicitly described by its

presentation on the slide or your oral explanation of it), leave it off the slide. [Same goes for figures.]

Related work slide is great. Move it [or copy it, per Steve's suggestion] to the beginning of this section.

Say the names of D and f. Those who care will want to know; everyone else will ignore.

[As Justin and Carleton mentioned, you should make sure your audience knows enough to understand the column headings of your related work table. Maybe structure your background around that?]

The traditional understanding of a model is that it is *fit* to data. [That is, right now you use some unusual verbs connecting your data to your model. We had a really long discussion about this. Your model exists independent of data; it is a list of variables. You fit the model to the data by some fitting/learning process in order to generate a model instance, which is a list of *values* for the variables. Just like class vs. object. Make this distinction absolutely clear in your talk. First discuss the model and how you developed it. Then discuss the fitting. Each is important, each is a contribution, and each is an independent concept.]

[Carleton brought up concerns about the term "Monte Carlo". Be careful; it means different and very specific things to different people. It's not central to your discussion, and in fact it sounds like you didn't even design the software to do the simulation. Just call it a physics simulation and explain *precisely* what the output from it looks like. If someone else wrote the software, tell us the name of the software. Leave the potentially dangerous term "Monte Carlo" out of it.]

Does your physics simulation take finite gradients into account? [This was a question that I wanted to ask as an audience member, not one you should address ahead of time. It's unlikely that anyone will ask. In this way it's similar to the question about why the hindered component of your model didn't incorporate angular dependence.]

What's "XOY plane" mean?

Ditch references to PGSE, and especially "experiments". The process of you designing the model doesn't require you to collect any data. ["Experiment" is another one of these terms that means different things to different people. Some clinicians call every scanner acquisition an "experiment". Nobody else uses the term this way. For everyone in your audience on Wednesday, a scan is a data acquisition, and that has to do with *fitting*, not the design of your model.]

"Simulation axon radius" should be "Simulation mean axon radius" on the X-axis of your various results bar-charts for the model that considers a gamma distribution of radii. [And, as we discussed at some length, just throwing all your tables at the audience serves only to confuse. Pick a couple good ones and explain what they tell us about your work *compared to your competition*. You want to reassure us that you do as good a job or better than all the related work you described in that nice table earlier on. If people want all the grisly details, they'll look up your papers or ask you.]

Where are the error bars?

---

QUANTITATIVE METHOD VALIDATION (PROPOSED WORK)

The vertical arrows are confusing. Number the three stages of your validation instead. [See my second point at the top of the email.]

"Solid" recordings?

Somehow clearly and explicitly specify, for each phase of validation, the following characteristics of your input data and the source of your "ground truth" for validation: in-vivo / ex-vivo; MRI / histology; human / monkey; values recorded in the literature / your work.

"Expensive" not "expansive"

Use a different term than "same brain". Step 2 is in the same brain too, so saying "same brain" for step 3 is confusing because it implies that step 2 is not.

What does "bonus" validation mean? Are you gonna do it or not? Be explicit and spin positively. [That is, cast it as "I will do (or would like to do) one of these things, the selection of which will depend on logistical issues. If the progress of my main research requires that I adjust my plans, I may have to skip this component." Right now you're saying, "I might do one of these, maybe, if it all works out", which, as Aggeliki pointed out, most of your audience will interpret to mean that you're just not gonna do it.]

---

Total talk time, with interruptions: 43 minutes.

[On the day before your talk, email everyone who's supposed to be there to remind them. On the day of your talk, show up at least an hour early to test your hardware, adjust the thermostat, adjust the projector, plug in your laptop, etc. Practice once or twice in the same room where you'll be giving the presentation.]

Good luck! I'm sure people will like your talk. See you Wednesday morning. =)