How to bomb a technical talk
In the jargon of conference speakers, bombing means presenting a talk which does not go well: content is lost or poorly understood because of the way it is presented, the audience prepares to leave early and in general have an hard time. Scott Berkun points out in Confessions of a public speaker that honest feedback is the only way for a speaker to grow and improve his presentation skills; yet it's not rooted at all in our culture: have you ever seen a presentation ending without a round of applause?
This article is based on real world experience, and on the ratings I received after my first talk at a large, professional conference. If you're a presenter, it may help you avoid some faults; if you're a conference attendee, you may get a laugh out of it as you have certainly have sees these common errors over and over.
Use a flipover or a board in addition to your slides for expressing concepts, for three reasons:
- the people in the back won't be able to see clearly, and follow what you're talking about, unless they have 10/10 vision (unlikely for programmers);
- it gives you the ability to wander off from your predefined path, from what you have rehearsed to new, scary concepts. Why staying to your outline when you can expand a point randomly?
- the quality of drawings made in 10 seconds by showing your back to the audience is really good. Especially if you add text: uppercase words are really fast to write and give the presentation a university feeling.
In order to stay on time. forget interactivity: you lose entire minutes by making questions to the audience and requiring their participation. It does not matter if they're sleeping peacefully in their chairs. Jokes apart, we all know that interaction from the audience is needed from time to time to refresh their attention: yet triggering this interaction without falling into the trap of a question that no one answers is not simple and requires work.
If you're not speaking in your native language, be sure to bring your funny accent: speak fast in order to avoid comprehension. A low volume is your friend: that's why you have a microphone.
Voice is often neglected, but this diffused behavior is part of the A-presentation-is-a-slidedeck credo; I recently attended a workshop from McKinsey where many more points came up: not only the voice, but also posture, gestures, eye contact, even pauses. As programmers often we focus just on content, and on slides: I'm guilty. But content is unlikely to be our competitive advantage: by buying a book a member of the audience can get usually more content, of good quality. The challenge is in delivering the main points and making them stick, within the timeframe and without boring everyone to death.
Do not include code samples, even though the audience is mostly composed of programmers. I'm still uncertain on this point: I preferred to provide code out of slides, for example in Git repositories, since it's more readable, nicely formatted and can be reused and checked out quickly. Yet few, focused lines of code helped my points come across in previous presentations like Architecture and testability, even when not given in Italian.
Cram everything you know about the subject into the presentation, adding slides and small talk. Even if you originally already did the talk in 50' minutes and now you are required to go down to 45', just try going fast and omitting some details instead about dropping an entire minor concept to give you the right pace. It will also make sure you don't have time for pauses of some seconds to breathe, or to insert some humor that can lighten up the room.
Pass from general content to more specific examples: from pattern definitions to ORM configuration; this way at least one part of your talk will be useless for the audience, as it wanted either introductory material or advanced one. By trying to provide new information for everyone, you can really bore the experts in the crowd and confuse the people who are beginners in the topic.
By the way, it's difficult to assess the audience level of expertise beforehand: I often get experts staying after the presentation to discuss about advanced topics, and at the same time other people who just wanted an introduction stop following in the middle of the talk because the concepts started requiring prior knowledge. Another difficulty is abandoning your assumptions and embrace the teacher's mindset again: you're not facing your team, trained for six months, anymore; you're facing a crowd of developers from different backgrounds.
Thanks to everyone that provided feedback: the job of a speaker does not end with his talk and questions, but consists also in dealing with reactions and try to improve the next presentation.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)