I’ve read a couple great blogs lately about handling failure during presentations (for example: Rands in Respose). The essence is that while you should prepare to succeed, your audience is more likely to remember how you handle failure when it (inevitably) happens.

Working with computers and giving presentations you will inevitably have a case where your hardware or software lets you down. If you’re giving tech demos or doing live coding, you are pushing these risks to the breaking point. When failure happens, you must be prepared to move forward with humor, engagement, and a minimal loss of impact. If you do so, your audience will likely not only forgive you but grant you positive favor.

I attended a Youth Group presentation today where several high school seniors were giving speeches and performing in front of a large audience. While everyone did great and the speeches and performances ranged from good to great, one young man stood out. He performed in the very first musical number, playing guitar and singing. In a critical part of the song where he was supposed to solo, the guitar microphone slipped out of the mic holder. He calmly stopped playing, clipped the mic back in, tossed a quick phrase to the girl playing piano behind him, and completed the solo without getting even slightly flustered. Amazing poise.

That’s how it’s done. I’ve seen many far more experienced presenters (and myself included) hit a technical snag and tunnel into the problem, instead staying engaged to the audience. I remember a time giving a presentation where I had a question about the difference between the way two components handled data ordering. I tried three attempts to answer this question (with no apparent success) and then (foolishly) thought I could quickly tweak an existing demo to show the answer.

I quickly discovered that I didn’t know the API as well as I thought and could not get the code even to compile. I ultimately bailed out but there was no saving face at that point. [I damn well worked through the solution that night though and understood where I was confused!]

I should have shut down the line of questioning after the second query from the guy and never tried to live code the answer. It was a good question and worth answering, but once you’ve given one good answer, there is rarely percentage in trying to satisfy one person in the middle of a talk. If it’s one person, ask them to talk to you at the end.

Sometimes more than one person is confused. In that case, you’re probably to blame and it’s worthwhile to clear up the confusion (and fix your talk later). Sometimes it’s hard to tell whether you’re in a 1-person or general problem – if so, poll the group. It’s quick to ask who else has the same question. No hands means move on, many hands means slow up.

Circling back to the young man from above, when it was his turn to present, he got up and engaged the audience directly with humor. He spoke not from the paper but to the audience, clearly ad-libbing some of the prepared speech, which told a story of searching and ultimately finding answers. At many levels, I found his presentation inspiring.