10 tips for academic talks

[article index] [] [@mattmight] [+mattmight] [rss]

Giving a good academic talk takes effort.

I'm not a master public speaker, and I've met my quota of bad academic talks. But, I'm better than I was when I started. And, I improve every year.

Since my own students are starting to give talks now, I thought I'd share what I've learned (the hard way) over the years:

  1. The audience determines the talk.
  2. Practice almost makes perfect.
  3. Nervous energy is exploitable.
  4. Every talk should motivate a problem.
  5. An academic talk is about an idea, not a paper.
  6. Slides must not overwhelm the viewer.
  7. Images and diagrams are better than text.
  8. Math's benefit must outweigh the loss of attention.
  9. Style matters.
  10. Questions are not random.

I've since found these insights and more in Even a Geek Can Speak. It's a short afternoon read. Anyone that does technical speaking should have it.


Update: A few of my talks are available online: [ICFP 2012] [Stanford 2011]

Audience

The biggest mistake academics make is misjudging their audience.

I've been to (many) talks where the talk itself was presented to one or two people in a room of hundreds.

(Disclaimer: I've given my fair share of these talks too.)

When preparing a talk, glance at the program for the event, or ask your host what you should expect of the audience in terms of background knowledge.

Aim appropriately.

When we speak on favored topics, our instinct is to gloss over concepts and details that once took us the better part of grad school to understand.

It feels awkward, or even insulting, to recap "introductory" material.

There's also a negative feedback mechanism in academic culture.

When you present to a broader audience, experts in your own specialty will claim to be annoyed and chastise you in public Q & A to stroke their egos.

Don't listen to them. You're not presenting to just them.

Always ask:

  • What needs to be understood to convey the big idea?
  • What can I expect the audience to already know?

Practice

Practice is the key to a "natural" delivery.

I have to practice ten times before I hit diminishing returns.

Keep in mind that you're not trying to memorize a talk. You're rehearsing its presentation. Memorizing a talk would take too much practice.

The good news is that not all practice has to be in front of a small group.

Practice a talk alone a lot, and then once or twice with a group.

The advantage of practicing with a small group is that it's harder to speak to a small group than a large audience.

Concentrate practice on your opening, since a smooth opening sets up a successful talk. The shower is a great place to practice openings.

Consider recording later practice talks, and listen to them for awkward transitions, slides that run too long or inadequate explanations.

If the transition from one topic to another is awkward, add a slide in the middle to make it more gradual. (Keynote transition animations can signal how abrupt the transition is going to be.)

If a slide runs long (more than 30-60 seconds), break it into multiple slides.

If you feel you're not explaining a concept well, first consider whether the concept is essential. If it's not, just cut it out. Otherwise, lengthen the explanation and add more slides.

Nerves

Public speaking is a common fear.

It is possible to eliminate that fear through extensive experience. But, until you get rid of it, you'll have to learn to exploit it.

Most folks get "nerves" or "the jitters" before a big talk because there is a natural fear of embarrassment.

The body misinterprets that fear as an existential crisis.

It releases adrenaline. Higher reasoning slows. Reactions go autonomic.

(That's why practice is critical: your talk must be instinct.)

Some adrenaline is good. Too much will leave you a chattering mess.

Understanding your biology allows you to take advantage of it.

You need to regulate and exploit your adrenaline.

Vigorous activity--I like doing push-ups--is an effective way to manage adrenaline. Even if you can't do many push-ups, you'll be able to crank them out right before you give a talk.

I once gave a TV interview on 45 minutes' notice. I hadn't shaved that day, and I needed to grab presentable clothes. I spent those 45 minutes literally running to get what I needed to go on camera.

When the reporter walked in, I felt exhausted.

When I saw the interview on TV, I was stunned: it was the most confident and natural-sounding TV interview I'd ever given.

If you're feeling nerves during the day of the talk, cut them off with music. I prefer "epic" music--the kind you find in soundtracks for battle scenes. Find music that works for you. If it has drums or bass that sync with a normal heartbeat, it can slow down a racing heart.

If you find your heart racing right before a talk, take a deep breath and hold it as long as you can. Exhale slowly and take another. Repeat until your heart slows down. (It has to slow down eventually.)

Over the past four years, I've given fifty public talks (and countless classroom lectures which don't count).

With each talk, my pre-talk nerves diminished.

As I was about to give the fourtieth talk, I noticed I didn't feel nervous.

After enough talks, the fear just goes away.

I say this as an introvert too shy to even call on the phone until college.

Motivation

Every talk needs motivation: Why should the audience grant you attention?

Avoid the standard cliches that everyone has heard.

I opened a recent talk on automating a technique in my research with:


(As adapted from Hilary Mason's shell-script goal.)

One of the best academic talks I have ever heard spent over half the alloted time motivating why something that was assumed to be a long-solved problem was not a solved problem.

None of the academic solutions had made a dent in practice.

I often have two motivations for my work--the "top-down" motivation and the "bottom-up" motivation.

A top-down motive is one that the taxpayer should care about: why some research ultimately solves a problem of societal importance.

These end with "safer software," "more efficient cars" and "cures cancer."

The bottom-up motive is an argument for the intellectual challenge of the problem or the elegance of its solution.

These motives sound like, "If we can do X via Y, and X is similar to Z, can we do Z via Y or something Y-like?" or "There are four possible combinations of two attributes, but so far we only have a name for three of those combinations; what is the fourth like?"

A bottom-up motivation situates the contribution to human knowledge.

Not every talk has to have both kinds of motivation, but thinking of a contribution in top-down and bottom-up terms helps find one to present to the target audience.

The idea

There's a misconception that an academic talk based on a paper has to be a lecture on what's in the paper.

It takes hours of thoughtful reading to digest the average paper in detail.

At best, a talk can catalyze that digestion; it cannot replace it.

The talk should present the same idea in the paper, but on its own terms.

After you've rehearsed your talk, ask the following questions:

  • Could a listener remember the motivation?
  • Could a listener state the main idea?
  • Could a listener summarize the talk in three sentences?
  • Could a motivated listener recreate the result in three weeks?
  • Would a listener know when to consult the paper?

Slides

PowerPoint has kneecapped public speaking.

People no longer "deliver a speech"; they "present slides."

PowerPoint encourages bad habits and even makes new ones possible.

Chief among them is visual infoglut.

In my earlier talks, I was no saint in this regard.

Sitting in the audience during other talks, I've realized that my brain shuts off when too much information is up on a slide.

Too much information means not much beyond three short bullet points.

I've since switched to a style where the majority of my slides contain at most a single line of text, or nothing but a diagram.

If I have to present a large diagram, I present it node by node and edge by edge, using the animation features of Keynote to avoid overwhelming.

I used to create slides like this:

These days, I would break this information into five or six slides.

Three years ago, I restricted my text to three short bullet points:

That's about as much information as I like to have on a slide.

But, the majority of my slides now contain only a single line; for example:

I'm not saying this is the only way to give a good talk, but I have found that constraining the information I have on a slide guarantees the audience can follow, and it forces me to structure the talk as a linear narrative.

It aids flow.

After you've rehearsed a talk, ask yourself:

  • Was there a slide where I spent too much time talking?
  • Was there a slide I could have done without?

Expand or cull as necessary.

Imagery

One of the good things about modern presentation software is that it enables imagery and diagrams that were not possible not long ago.

Wherever an image suffices to convey an idea, I prefer it to text.

But, images and diagrams can also become too complex.

I build up diagrams node by node and edge by edge using the animation facilities provided by the software.

Even for the following diagram, I used four slides connected by animations:

I've heard from psychologists that a diagram with seven components is about as large as you can get before viewers can't keep the whole diagram in their head. That seems true in my experience.

Visual symmetry allows mental compression, doubling the size of diagrams that viewers can attend to. It even aids comprehension.

A Tuftean trick is to avoid needless embellishment on charts.

For instance, in many cases, the shape of a plot matters much more than the specific values on the plot; that is, what's of interest is whether some agent is growing exponentially, linearly, quadratically, etc.

Whenever that is the case, I omit axes, scales and tick marks: I draw just the lines or bars themselves.

Math

The hardest part of giving a good technical talk is not using much math.

Mathematics is an expressive and precise language.

Even for experts, it takes time for a reader to parse and translate mathematics into internal mental concepts.

Because of the mental effort involved, reading mathematics disengages the reader from the speaker.

Mathematics must be used sparingly.

When I got to this slide in my first talk, I accidentally ended it:

Not only could I have defined the function "local-inlinable" in plain english (or with a diagram), the condition on thes slide takes minutes to unwind. I gave my audience 30 seconds.

Mentally, everyone abandoned ship.

These days, as a rule, I use animation to make sure that when I use math, I never introduce more than 4-7 symbols at a time.

Each equation receives its own slide.

Few people learn mathematics straight from formal definitions.

The mind is an engine for inferring the general from the specific.

Where possible, I define a concept in terms of a few examples, and let the reader's mind interpolate the general definition. It feels dirty, but it works!

I now ask the following questions of any math I use in a talk:

  1. Is understanding this math essential to the idea?
  2. Is there no way to use a diagram or analogy instead?
  3. Is there no way to use plain english instead?
  4. Is it infeasible to infer the concept with examples?

If the answer to all four questions is "Yes," I'll use math. If not, I don't.

I've found that I can cut out almost all of the mathematics from my talks.

The feedback from audiences has been positive.

Just to convince the audience that there is a formalism for the work, I sometimes have one slide at the end with most of the mathematics:

Style

Something that's surprised me is the degree to which an audience will soak in style and polish.

The choice of font, the lack of gratuitous visual adornment, the balancing of whitespace, and the effort to use intuition-guiding animations affects the feedback I get from the audience after a talk.

The effect is so pronounced that I switched from LaTeX to Keynote for preparing slides.

As a researcher in programming languages, I tend to have a reductionist attitude about languages: every class of problem should be solved by creating an expressive language for describing solutions.

Presentations are a strong counter-example to my viewpoint. It's much easier to create high-quality presentations in Keynote than in LaTeX.

I think the slideshow package in Racket holds a lot of promise for the linguistic development of high-impact presentations, but it's not there yet.

Questions

Q & A handling improves with experience.

I've managed to get better by anticipating questions.

By giving practice talks to small groups, you'll find a core set of questions.

Some answers belong in your talk, but those that require lengthier or off-topic diversions can be reserved for a special slide.

Twice, I've managed to anticipate not only the questions asked but also the questioner that asked them. I even prepare an answer slide that includes the likely questioner's name.

For handling unanticipated questions, buy time by reformulating the question as you understand it.

If an exchange lasts long or becomes hostile, thank the questioner and ask to move the discussion after the talk.

Miscellaneous tips

  • If you can open with short, clean, original and relevant humor, do it.

    I recently gave a public talk on information security and spoke after an FBI agent. The agent opened with a childhood story.

    I started my talk with, "I was also going to tell you a story about information security from my childhood, but I just realized I'm sitting next to an FBI agent, and I forgot to check the statute of limitations."

    Light-hearted self-deprecation usually works well.
  • Never use humor you haven't tested on a practice audience.
  • Video record your talks and watch them. It's painful but worth it.
  • Never use Comic Sans in a technical talk. I am a Comic Sans bigot. There are others.
  • Gesture with your whole body.
  • Step away from the podium.
  • Use the Kensington remote. It's sleek and ergonomic, and it's the only one without an easy to press "screw up my talk" button.
  • Pay attention to what you like and don't like in other presentations.
  • Code is the same as math in terms of mental effort. Use it sparingly.

Related posts

More resources

I recommend the following two short reads without hesitation:

Other academics have weighed in, too. I always recommend Simon Peyton-Jones's notes on how to give a talk.


[article index] [] [@mattmight] [+mattmight] [rss]