Handling a glitch during a presentation

You know the drill, and you're prepared for your talk. You know your audience, know your slides, and know your venue. But you can’t prepare for everything. And you can’t prevent everything. Bad things happen, apparently randomly, to good talks.

What you can do is to put yourself in a position to be able to handle surprise problems with flexibility and grace, and to go on with th

I gave a talk this week that I’ve given before. It was tweaked to the audience, prepared but not rehearsed, and well organized. I was familiar with the slides. I had assessed the room the night before the talk and had actually stood on the stage (a handy tip for making sure there aren’t any surprises when you step out to give your presentation). 2 hours before the talk I had connected my Mac to the projector and made sure there weren’t any issues. It all worked.

Houston, we are all systems go and ready for launch.

Speaker, speaker, break, speaker. Then it’s my turn. I walk up, connect my Mac to the projector, and the synch is wrong. Slides look muddy, whites are yellow, and there is a slight jitteriness on the image.

Well, dang.

Steve the introducer-guy starts my intro while I fiddle with the screen; I figure I’ve got 45 seconds to get it working. I futz. I fiddle. No difference. Intro is finished.

Decision time

So right now I could continue to fiddle. Other speakers have done that before me. I have seen this glitch once before (also with an Epson projector: note to self, remember to curse Epson when I am endowed with magical powers), and it resolved after much fiddling, connecting, and disconnecting. I might be able to fix this.

But, the slides are readable. Colors are wrong, and I’m not happy with that, but the audience can easily read them and the problem isn’t distracting to anyone but me.

I decide to go ahead with the presentation. Continuing to fiddle will be disrespectful of the audience’s time, and draw further attention to this problem. Most groups are sympathetic to a technical glitch, it’s happened to everyone. But the longer you work the problem the more of it sticks to you. The idea here is to get in, get it “good enough,” and get on with the talk.

Was it just me, or did that go OK?

I started out a little flustered. It really is important not to apologize at the start of your talk; you might get sympathy, but not respect. I didn’t exactly apologize, but I did stammer something about this not having happened in rehearsal. I don’t know why. Crap was just leaping out of my mouth.

I got a hold of myself right after that fell out, though, and plowed into the talk. The audience was engaged, and the talk mostly landed. Afterwards a dozen or so people made their way up to talk more about the topic or to tell me that they enjoyed the talk. Of course all I could think of was how ugly it looked.

What’s going on here?

Presenting is a performance, and a lot of performance happens inside your head. Everything did not go as planned, and a little of that ickiness stuck to me during the talk. It’s like if you’re runnning a race you’ve trained hard for, it’s on TV and your girlfriend is going to see you, and you show up with mismatched socks. It doesn’t really matter too much, but it niggles at you.

The content was solid, and the message was one the audience was interested in. These things engaged the audience’s attention, and are ultimately what let to a positive reception.

Defensive presentations

As it turns out, my presentations are also designed to insulate me in small ways against these kind of problems. Here are some of the structural things in my presentation that helped people focus on me and the content, rather than the problem.

First, my slides use a basic black and white color scheme: white text with a very dark gray gradient background. The room lighting was medium, so this color scheme worked fine (it is almost unreadable in a bright room, though, so if you don’t know what the lighting is ahead of time, go with black text on a white background).

I use color for pop, not to hold the audience’s attention on the screen. I want their eyes on me, not the screen. Although the colors were muddied by the projector, the only thing that was lost was the pop for emphasis; the primary information was there and perfectly readable.

Second, I used the Lessig Style for this talk (info here). With this style there are lots of slides - I had 115 in 30 minutes - but each one only has a single image or phrase on it. So there isn’t a lot to grab your attention on any one slide, and the primary feature of the talk is motion through the slide deck, not what’s on any one slide. This worked in my favor this time, since people weren’t looking at a slide long enough to wonder why the first work was slowly oscillating back and forth like a projector synch belly dancer.

Third (and last), I try to make my slides fun. There isn’t a lot of text, and I tend to pick non-traiditional images and objects to trigger me to talk about a concept rather than cramming the whole concept in text on a slide. As a result my presentations are usually different from everyone else’s, and so more fun to look at it. People cut you slack when your slides are fun.

Don’t focus on the problem

Twice during the presentation I referenced the synch problem and resulting bad image on the screen. This was a mistake.

Drawing attention to a problem is never smart. In fact, several people after the talk made a point to ask me to show them what the problem was: they hadn’t seen what the slides were supposed to look like, so the problem wasn’t obvious to them. My references distracted them from the talk and triggered them to see a problem they hadn’t noticed. I lost points with these people only because I drew attention to the problem.

Preparing for the worst

In the end, you have to prep. Know your audience, know your slides, and know your venue. But you can’t prepare for everything. And you can’t prevent everything. Bad things happen, apparently randomly, to good talks.

What you can do is to put yourself in a position to be able to handle surprise problems with flexibility and grace, and to go on with the show.

Copyright © 2007 IDG Communications, Inc.

How to choose a low-code development platform