Skip to main content

Conference talk pet peeves

I'm sitting here at SenSys 2010 in Zurich and listening to some pretty interesting -- and also some pretty dull -- talks on the latest research in sensor networks. Now seems like an appropriate time for a blog post I've been saving for a while -- some of the things that really annoy me when I'm listening to a talk. Of course, I'm sometimes guilty of these myself, and I'm not the best speaker either. But I guess I have license to gripe as a listener.

There are lots of tips on there on how to give a good talk. David Patterson's "How to give a bad talk" is a great summary of what NOT to do. Some of these things are fairly obvious, like not cramming too much text on one slide, but others I see happen again and again when I'm listening to talks at a conference.

The dreaded outline slide: Nearly every 25-minute talk in a systems conference has the same format. Why do speakers feel compelled to give the mandatory outline slide --
"First, I'll give the motivation and background for this work. Next, I'll describe the design of FooZappr, our syetem for efficient frobnotzing of asynchronous boondoggles. Next, I'll describe the implementation of FooZappr. Then, I will present evaluation, and finally, related work and conclusions..."
After having seen several hundred such talks I have this memorized by now, so I don't think it is a good use of time. An outline slide is sometimes a good idea for a longer talk, but it should have some content -- guideposts for the audience, or highlights of the major ideas. This is rarely needed for a short conference talk.

Reading the slides: The number one thing that drives me up the wall is when the speaker simply reads the text on the slide, or essentially says the same thing in slightly different words than what is printed on the bullets. This is lazy, and suggests that the talk hasn't been rehearsed at all. It's also the fastest way to bore the audience. Most members of the audience have two parallel reception channels: visual and auditory -- so I try to use both at once and provide (slightly) redundant information across the two channels in case of loss (e.g., tuning out the slide).

No sense of design: It can be physically painful to watch an entire talk crammed full of multiple fonts, clashing colors, inconsistent use of graphics, and that awful PowerPoint clip art (you know the ones: skinny stick figures scratching their heads). Modern presentation software, including PowerPoint, lets you design beautiful and visually compelling talks -- use it! If you insist on coming up with your own template, at least use the colors and fonts in a minimal and consistent way. I tend to use the Harvard crimson banners on my slides and the same color for highlight text. A grad student once complemented me on the beautiful font choice in my talk -- it was Helvetica. You shouldn't spend too much time on this, after all, if your slides look good but have terrible content, it's not worth it.

No sense of humor: I've lost count of how many conference talks I've heard that are nothing more than dry recitations of the technical content of the paper. No attempt is made at humor anywhere in the talk - not a joke to warm up the audience, or at least a visual joke somewhere in the slides to wake people up a bit. A conference talk is entertainment (albeit an obscure kind of entertainment for an incredibly dorky audience) -- the speaker should at least make some effort to make the talk interesting and delightful. Most conference attendees spent hundreds of dollars (thousands if you include travel) for the privilege of listening to your talk, so you owe it to them to deliver it well. This is not to say that you should overload the talk with jokes, but breaking up the presentation with a bit of levity never hurt anyone.

Keep in mind that a conference talk is meant to be an advertisement for your paper. You do not have to cram every technical detail in there. What will the audience remember about your talk? I'll never forget Neil Spring's talk on ScriptRoute where he used a bunch of ridiculous custom Flash animations.

Of course, the talk delivery matters tremendously. If you're one of those dull, monotonic speakers or have a thick accent, you are probably not going to get a reputation as a good speaker. If you sound totally bored by your talk, the audience will be too. Some grad students are surprised that this matters so much and think it shouldn't -- but if you're planning on pursuing an academic career, you have to give a LOT of talks. So you should get good at it.

"Let's take that offline." This is a frequent response to a question that the speaker doesn't want to answer. I've heard speakers jump immediately to this rather than make any attempt whatsoever of answering. This has become far too socially acceptable at conferences and I think questioners (and session chairs) should push back. It is occasionally OK to take a discussion offline if it is going to be a lengthy discussion or there's clearly no agreement between the speaker and questioner, but I think speakers should be expected to answer questions posed after the talk.

Finally, with digital cameras there's an increasing trend of audience members taking photos of every talk slide (sometimes for every talk). Here at SenSys there's someone who is taking a video of every talk on his cell phone. I find this fairly obnoxious, especially when the photographer insists on using a flash and leaving on the camera's shutter "beep". If you want my slides, just ask me and I'll send you the PPT. I also think it's rude to take a video of a talk without asking the speaker's permission.


  1. I was actually surprised to hear a senior researcher advising to repeat everything you say on the slides, "because anyway people are not listening and only pay attention every 5' ". But this was here in France, and I think non-fluency of english makes that the speaker wants to ensure that the part of the audience that does not understand him gets the message.

  2. I think I understand the underlying point you are trying to make with three of these points, but I disagree with the conclusions and advice, or at least with where the emphasis was placed.

    Reading the slides

    If the speaker does not verbally state the text in the slide during their speech, I have trouble "syncing" between the two sources of information, and it's as if I am trying to listen to two different speeches at once. I think that the purpose of text on slides is to remind listeners what is the most important couple of points of the slide in case they miss it in the explanation. Obviously reading nothing but the text on the slides is bad, but if one follows your advice on keeping the amount of text small, then reading nothing but the text would lead to a four-minute talk. I think it is perfectly acceptable to put four minutes worth of total text into the slides, read precisely that text as you get to it, and spend the rest of the time filling in the details, with the text up there to remind the audience what the main points are in case they doze off for 30 seconds. I don't think this is lazy or at all conflicts with the advice to rehearse the talk.

    No sense of design
    Certainly an innate sense of design can help improve a talk. But if you don't have a sense of design, you can still be a good scientist, do good work, give good talks, and have decent slides by keeping them simple. An excellent talk is still excellent even if it is backed by black-text-on-white-background slides with figures and tables pasted in. The fact that you can tell the difference between one Powerpoint feature, the clip art, and the other Powerpoint features that let you "design beautiful and visually compelling talks" means you have an innate sense of design that not everyone has. I think the presence of the Microsoft stick figures can be attributed to people with no sense of design, like me, caving in to pressure to add snazzy design to our spartan slides, but not having the graphic design talent to do this well.

    No sense of humor
    I've heard this one about teaching as well. Just like the design stuff, if you are a natural stand-up comedian, that's a great skill and you should use it in your career just like any other skill. But some people, like me, are no good with planned jokes. I can be funny in a group if it is spontaneous, but I have learned that whenever I plant a joke into a talk or a lecture, it bombs. The lesson I learned is, don't use humor if it doesn't work. I imagine the real point you wanted to make is, "Don't give a boring talk". But humor is not the only antidote for boredom. The best antidote for boredom is to give a talk that everyone in the room can follow. I only learned very slowly over the years how to do that, and I don't have any simple rules to follow to achieve that. But for me personally, I think that I get it done without any planned jokes.

  3. It could be worse... In some fields, the speaker stands at the front of the room and reads the paper verbatim.

  4. And, the purpose of the talk is to get people to read the paper.

  5. To quote a (slightly cynical) former colleague: the purpose of the talk is to get people to *cite* the paper.

  6. In my experience, the use of an outline slide (with its well-known structure) is often helpful for people who are feeling nervous. It allows them taking a slow(er) start...

  7. I'll soon be presenting a paper at a conference for the first time. Your blog will surely help.
    Thanks in advance.

  8. "An excellent talk is still excellent even if it is backed by black-text-on-white-background slides with figures and tables pasted in."

    I don't think this comment contradicts Matt's "no sense of design" point. Heck, black-and-white IS a good design! Its not particularly bold or original, but (imo) it still looks nice.

  9. Also, if I can suggest another point...

    Stick to the time limit! Not only is it annoying when a talk runs long, but it makes your talk suck because you end up zooming through the second half. The session chairs here are actually pretty lax - at NSDI they really cracked the whip and kept people on schedule (which I appreciated!).

  10. A grad student once complemented me on the beautiful font choice in my talk -- it was Helvetica.

    That's nerd talk used for hitting on other nerds. So, was she (or was it a he) cute? :)

    On a more serious note, I find that the things mentioned above are more or less condiments. I mean, if the presenter is basically saying he's trashed my work, I'm going to be fuming and clinging onto his every word, thinking about what I'll say when I come up with a better algorithm / system / etc. Wait, I'm still joking. I think.

    Anyway, if our opinions of a researcher are influenced by how he / she presents, that's a slippery slope which unfortunately I think networking today is slipping further down on. Like anonymous above said, even if the presenter reads his / her paper aloud word-by-word, that should still be ok. What matters is the work which took months, not the presentation which takes minutes. On a similar note, what matters is that the work has significant impact, not that the researcher has lots of papers.

  11. Anon - "What matters is the work which took months, not the presentation which takes minutes." I could not disagree more. BOTH the work AND the presentation matter, tremendously. If you are unable to give a good talk on your work, you are unlikely to be successful in an academic career. Giving a bad talk at a conference can kill any hopes a grad student might have of getting good faculty job interviews - same goes if you give a bad talk during the interview. If you think this only matters for academics, think again. The most embarrassing talk I saw at a conference was from a fairly well-respected industrial lab where the person had clearly not practiced the talk AT ALL - made even more embarrassing by the fact that this was the award paper at the conference. People remember this kind of thing. Maybe you think it shouldn't matter, but the bottom line is that effectively communicating your work is just as important as the work you do.

  12. If you are unable to give a good talk on your work, you are unlikely to be successful in an academic career. Giving a bad talk at a conference can kill any hopes a grad student might have of getting good faculty job interviews - same goes if you give a bad talk during the interview. If you think this only matters for academics, think again.

    Hmm, I think of it this way. Say there is a brilliant mind trapped within a less useful body, say Stephen Hawking. And the body is an impediment to making a good presentation. Of course for whichever organization planning to hire Prof Hawking (this is an example of course), because he is so good at being a physicist, they're likely to overlook the fact that he is probably not going to be as impressive a public speaker as say John Stewart. But, really, who cares about his public speaking?

    On the other hand, I guess having such skills will help when one isn't as good a researcher as others: we use public speaking to 'shore up' our resumes. But in those instances, we're no longer looking at the 'best of the best', other... political factors get in the way. One might argue and say, "Well, that's because all of us are the best-of-the-bestest". In which case my reply would be: are we falling deeper into the mode of cultivating politicians rather than good scientists? And the answer clearly MUST be: we must first and foremost consider the intellectual prowess of the researcher. If all else is equal, then and only then should icings on the cake, like good presentation skills, come into the picture.

  13. Actually not everyone would email you the ppt. You would be surprised.

    If you look at MSR people very few post ppts on their websites and a lot of them are not so responsive when you ask for the slides.

  14. I think my #1 pet peeve is "papers which are wrong." There were a couple of those at this conference (there've been a few previous years, too), where you wonder what the PC was thinking...

  15. For the previous anonymous:

    ... and they precisely were...?
    If you are sure they were wrong, please point them out clearly.
    In the end, you are an anonymous, you risk nothing!
    Otherwise, sorry, but you are just wasting your time...

  16. Anon re: comparison to Stephen Hawking. You can't be serious. How many people in this world are as evidently brilliant as Stephen Hawking? Note that he made his career not just by being a great physicist; he has also published popular books (e.g., "A Brief History of Time") which falls very much in the same category as being able to deliver a good presentation. I challenge you to name one successful academic computer scientist (or any other scientist, for that matter) who is incapable of giving a good talk, or presenting their work in some other manner.

    Anon re: "Not everyone will email you the PPT." This does not make it OK to take videos of the talks at conferences. You're not entitled to take home a copy of the presentation; you paid the conference registration fee, you get to listen to the talks, and you get the proceedings. Amateur conference videography without the speaker's consent is pretty obnoxious.

  17. Actually in fundamental sciences, there are legions of bad speakers whose work is very influential. Maths would be a primary source of examples, just go to your math department seminars some day and you will see. Theoretical computer science is a bit better but not always.
    The major issue with your post is that you didn't mention talk structure, content or idea organization at all, just how the presentation is delivered. I do not challenge the fact that this can be a recipe for your personal success in many industries and even academic fields, but it does not mean you have made an interesting contribution.
    And it's too bad if this becomes your only way to judge an academic talk or the reason why you'll "spent hundreds of dollars" to travel to the conference. I would have said meeting your colleagues and discussing ideas as the primary reason to do that.


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…