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.


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.


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.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (2)

  1. I work for Peachpit Press and thought you and your readers might be interested in knowing that Garr Reynolds just released his first online streaming video, Presentation Zen: The Video, where he expands on the ideas presented in his book and blog. More info can be found here:


  2. One thing that really can make you fail to deliver an adequate level presentation in my experience is finding the right words. While preparing a presentation it is important to think through (or better yet, talk yourself through) the presentation you’ve prepared and see where you get lost for words. This is probably a more common problem when you are presenting in a different language than english as all the techy terminology is english.

    I was doing a short introductory presentation on CoffeeScript and had prepared the slides for an international audience (that is all text was in english) while I was supposed to deliver the presentation in swedish (which is my native language).

    I realised a few hours before it was time to go on stage that I hadn’t worked out the flow of the presentation in my native language, so I started going through the speech slide by slide trying to find the right wording for what I had planned to present.

    It didn’t seem to work very well but when it was time to enter the stage and start the presentation it all just came together and the speech felt natural and well prepared, and the words just came out. I don’t really know how that happened as it was really failing the hours before. To conclude this comment: The two rehearse Rs in this post can not be overstated.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All