Hints for Giving a Good Talk
- Know thy audience and watch thy jargon
- Keep the big picture in mind
- Tell me a story, don’t read me an article
- Pace yourself
- What did you just say again?
- There will be questions…
Know thy audience and watch thy jargon
Know your audience! At typical REU/SURF presentations, the audience consists of a wide variety of people from different disciplines. Roughly, the structure of your talk should reflect the following goals: (a) hook everyone (including those not in your area) on your topic/problem; (b) impress the experts with your specific work; (c) wrap up and recapture the attention of the non-experts. The fraction of your talk devoted to each of these depends on the level of sophistication of your audience.
Framing the problem can be a challenge. Are there popular-press or “real-world” examples you can appeal to in order to illustrate what you’re doing? Even examples from Star Trek can be useful, since a lot of technology areas are rapidly approaching the abilities envisioned in that venerable show. Graphics, photos, and short video clips are also useful. Your project advisor can probably help you find something appropriate.
Beware of jargon, which covers both terms and concepts. Some people don’t know what public-key cryptography is; others are specialists and just want to know which cryptosystem you used. Some people aren’t familiar with the concept of separating a user interface from a device or application; plan to explain it if needed.
Keep the big picture in mind
What is the high level view of what’s going on? You need to motivate the overall project to an audience who might be thoroughly unfamiliar with it. In a SURF talk, it might take up to 1/3 of the talk to motivate the problem and be sure everyone understands (at least at a high level) why it’s useful, interesting, etc. This is time well spent: if people don’t understand the ultimate goal, they probably won’t pay attention to what you did.
How is the big picture divided into subproblems, and where do you fit in? Now that the big picture is clear, what are the specific subproblem challenges? Which part of which subproblem are you working on? Some of this will necessarily get into details that not everyone in the audience can follow.
If your efforts succeed, what will you have demonstrated? Another way to ask this is: what is the “research question” (or questions) being addressed here? In other words, ten years from now, when the hardware, software, etc. have all changed and the computers of the day make today’s computers look like Tinkertoys, what fundamental nugget of an idea will still be considered relevant and applicable? This is often very hard to identify, and it may be that your own piece of the project contributes only a small part toward forming that Big Idea, but research is a building that has to be built one painful brick at a time. (Ask any Ph.D. student.)
Tell me a story, don’t read me an article
Rehearse your talk enough that you don’t need paper notes (or, at most, minimal notes – two or three 3×5 index cards for the whole talk). If you make eye contact, engage your audience, and tell them a story, they will pay attention. Try not to read from notes; they can read a paper as well as anyone. Having a speaker bring the material to life is what makes a talk different and potentially a better avenue for communicating your work to a lay audience.
Don’t be afraid to use humor. If a funny picture, animation, joke, etc. is appropriate, it keeps the audience interested. But don’t fall into the extremely annoying trap of using these gratuitously; it distracts the audience and gives the impression that you are using these to cover a lack of competence with the material.
You won’t have time to say everything you want. The higher level the talk, the less detail you’ll have time for. A time-tested rule of thumb is: 2 minutes per slide. This sounds conservative, but it is very well borne out on average. Therefore, exlcuding the title/outline and conclusion slides, you should have half as many slides as you have minutes to speak.
Find a couple of key “timepoints” in the talk (“By the time I get to this slide, I should be n minutes into the talk”). Once again, rehearsal is key to debugging this. Remember, if you run out of material early, you are still prepared with a level of detail deeper than your talk, so you can use the extra time to elaborate on a particular point of interest to you; but if you are running short of time, you won’t be able to communicate everything you want to say, and your audience will not come away with a representative picture of what you did or why they should care.
What did you just say again?
Especially if the middle part of your talk is aimed at technical experts, be sure you recap towards the end what the overall problem was and what your contribution was. Plan on 1-2 slides for this. People best remember the beginning and the end, so make sure these are rock solid. (Ask anyone who has written a Broadway musical if you don’t believe this.) It may be appropriate to include “future work” here – things left to be done (some of which may have been discovered as a result of your work, which is always good) and new issues that came up as a result of your work.
There will be questions…
People will ask about stuff not in your talk. The main preparation/rehearsal, then, is to know your material at one level of detail deeper than your slides. Usually you cannot predict the questions; so, although you should make sure you can explain every point on your slides in additional detail if necessary, do not expect that those are the only questions you will get. People remember how well you handled your questions, since it demonstrates real familiarity with your material (anyone can rehearse and deliver a prepared talk on a topic they know little about).