A Technical Presenter’s Journey Part 7: The Four Rs

Today’s post is brought to us by Al Tenhundfeld over at tenhundfeld.org. Thanks Al!

Justin Etheredge’s ongoing series of posts on technical presenting has inspired me to finish this post I’ve had in limbo for a while.

Over the last three weeks I’ve given as many presentations at community events. Overall, I feel they went adequately — not great but good enough. At this point in my presentation skill continuum, my goal is merely not to fail. If you’re not a naturally engaging speaker or storyteller, the journey to giving fantastic presentations will probably be long and overcome only through a lot of practice, and it’s not really a state I’m qualified to coach towards. However, I can give advice on not failing miserably. I’m learning there are many subtleties to becoming great, but becoming adequate just takes a little effort and a simple formula.

The Four Rs of Not Failing

1. Research
2. Rehearse
3. Rehearse
4. Relax

1. Research Your Topic

When giving a technical presentation, few things will get you ticket on the fail train as fast as not really knowing your material. This problem can present itself in various ways. Most important, you need to feel that you’re qualified to present the material; if you don’t feel confident, your presentation will be doomed as your nervous ticks emerge and the audience starts daydreaming. You need to understand why people care about your topic. (This is the foundation of engaging the audience.) Lastly, you need to be able to anticipate the questions people will have. I don’t mean that you need to be the world’s foremost expert on your topic, but you need to have a good working knowledge of your topic. You need to understand how people are actually using it in the real world. If you’ve been using a technology on a real project, you’ve probably hit most of the pain points; if you haven’t, I recommend watching webcasts of how other people are presenting the topic via PDC, Mix, etc.

I’m not going to discuss crafting your presentation. That’s a huge topic with lots of good resources.

2. Rehearse

After you’re confident with your topic and have a rough draft of your presentation, rehearsing is the next critical step. When giving technical presentations, you have some challenges most slide-only business presentations don’t. When you only have slides, you can run through each slide, telling a nice little story with a high degree of certainty about the flow and timing of your presentation. When you start interspersing technical demonstrations, you introduce a heap of variability.

Each demo is a unit of work. It needs to be tested and rehearsed independently, and after you feel good about each one, you must run through all of them in order, i.e., integration tests. I’ve had numerous problems where a demo worked fine in isolation, but in my real presentation something went wrong: an environmental side effect, forgetting to reset a shared resource, etc. And this isn’t even including hardware issues. Demos might suddenly start running much faster or slower than they did when rehearsing; the network might flake out. If things can go wrong, they will — the more you rehearse, the more likely you are to find those edge case problems.

Ideally, you should have the entire environment for your demo in a virtual machine backed up to removable storage. If something goes very wrong on demo day, you can just use/borrow a different laptop. I don’t always do this, but you’re taking a risk if you choose not to.

As I rehearse each section of the presentation, I like to make bullet points for each slide and detailed notes for my technical demonstration. I usually end up not looking at any notes, but the act of creation is the important part. Translating your thoughts into concrete words will cement the main points in your memory.

3. REHEARSE

Seriously, you’re probably not rehearsing enough. Talking through the micro issues is not enough. Having working demos and a detailed script is not enough. You need to rehearse the entire presentation from start to finish, with no breaks and no edits. This is good for getting a realistic measure of your presentation’s running time, important if you’re in a timeboxed setting like a CodeCamp. And this is really the only way to see the total flow of your presentation. If you’re like most technical presenters, you obsess over the small things, spending hours on getting the code for an 8 minute demonstration perfect, but you neglect the bigger picture. I have to continually remind myself that most people aren’t going to care about (or much less remember) the details of the demonstrations; even if you’ve done a fantastic job, some of the audience might remember a bullet or two about each demo.

I’ve started doing a complete rehearsal in a room by myself with a projector and a camera. This probably sounds like overkill to many people, but I’ve found it to be extremely valuable. You quickly see your nervous ticks, saying “uh” to fill every gap, fiddling with your water bottle or repeatedly using certain phrases. You’ll notice if you’re talking too fast without enough enunciation. Important to technical demos, you’ll get a feel for how you’re transitioning between slides and demos.

There’s a famous quotation from Maya Angelou:

I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.

I find profundity in this sentiment, and I think it applies to presentations as well. Everyone will remember the impression you made on them, many will remember the story you told, and a few who care about your topic might actually remember a technical detail or two. If you haven’t rehearsed the entire story from front to back, you are skimping on the second most important ingredient.

4. Relax

A calm, casual composure is the point of all this research and rehearsing. When it is time to give your presentation, you shouldn’t even need to think about what you’re doing. You’re just having a friendly conversation with the audience. When I’m in front of a group of peers, the last thing I want to worry about is sticking to a script or trying to remember interesting things about my topic. I just want to relax, tell a nice story, share some cool nerdy things, and have a good time. For me, over-the-top preparation is the only way to achieve this goal.

Conclusion

I came upon this formula in part from my experience speaking in front of clients, CodeCamps, and local user groups and in part from watching other speakers and performers.

I’m a software developer. I have received no training to perform in front of people, but you know what, there’s a whole profession of people who do this day-in day-out. They’re called actors; you might have heard of them. I was recently watching Charlie Rose on PBS, and his guest was Michael Caine. I enjoy Caine’s work as an actor, and I really appreciate how he talks about his craft. During this interview he was talking about what he likes in directors.  I’ve included an excerpt from the interview below:

MICHAEL CAINE:  What I do is I work, one of the basic principles of 
Stanislavski which is called the method which is not looking at the floor 
and mumbling and scratching your bum.  That’s not the method.  What it is 
the first basic principal of it is the rehearsal is the work and the 
performance is the relaxation.  So I’ve already done everything before you 
say action.  I’ve said that line a thousand times before you ever, you 
know.  And so we rehearse it, obviously rehearse it with other actor to see 
what he’s going to do.  Once I’m ready and I do it, there is a moment -- 
you maybe do two takes or three takes but by that time there is a moment 
when I’ve done it the way I think it should be done and then after that I 
do get a little ticked off if we keep going.

That’s a fantastic perspective: rehearsal is the work and the performance is the relaxation. And that’s pretty much my whole recipe: research, rehearse, rehearse, relax. This advice is geared towards giving presentations at community events, where the goal is to be informative. If you ‘re giving a different type of technical presentation, like a sales demo or executive stakeholder demo, YMMV.

Along with structuring the presentation, I haven’t covered many important topics, e.g., knowing your audience, slidedeck design, body language, etc. There are many different ways to approach each of those topics and many recipes for success. But if you’re just getting started in the world of presenting, those topics will probably just distract you from the core issues you need to work on.

Technical presentations, especially those with demonstrations, have a mess of complexities and potential risks. I cannot guarantee you’ll be a smashing success, but I am confident that if you go through this routine, your presentation will be adequate. You will not fail miserably, and that’s a good start. Obviously you can succeed without following this formula; I’ve seen people give rousing impromptu presentations with zero focused preparation. I’ve also seen many people fall flat on their face by preparing too little; trust me when I say that adequate (not failing) is better than many presentations I’ve seen throughout the years.

Please let me know if you use any of the ideas from this post. I’m always looking for ways to mature my thoughts on and approach to presenting.