The Value of a Good Technical Demo

Guy Drut. From hurdler49

Guy and the Gold Medal

The French Olympic hurdler, Guy Drut, found himself in an unenviable position in the early summer of 1976. He was France’s only hope for a track-and-field medal, and the burden of carrying the nation’s pride on his shoulders was getting to him. Drut later told me that he had spoken on several occasions prior to the games with our long-time client Jean-Claude Killy and that he really felt he owed a part of his gold medal to Killy. He explained it as follows: “Jean-Claude told me that I was the only one who knew how to get my body and mind to their ultimate peak for the Olympic Games. He then told me that after I had done this that I should keep saying to myself, ‘I have done everything I can to get ready for this race and if I win, everything will be great, but if I don’t win my friends will still be my friends, my enemies will still be my enemies, and the world will still be the same.’ I repeated this sentence to myself before the qualifying heats and during the break between the semi-finals and finals. I kept saying the sentence over and over, and it blocked out everything else. I was still repeating it to myself when I went up to get my gold medal.

From the Fear of Failure passage in What They Don’t Teach You at Harvard Business School: Notes from a Street-smart Executive by Mark H. McCormack. Underlining is mine.

This isn’t the fear you’re looking for

Few of us have been in the starting blocks at the Olympics but for many of us a similar level of anxiety can be brought on at the thought of presenting a technical demo in front of our fellow engineers – even our friends and colleagues.

By repeating those words, Drut downplayed the consequences of failure and detached his anxiety from his situation. Every time I go up on stage, I say those same words, for the exact same reason.

Working out loud is a good thing

Every Wednesday morning for the last four years our entire technical staff gets together for Demos and an All Hands. Engineers sign up to give 5-minute demonstrations of new product functionality or internal tooling and then take questions from the audience. After the Demos we move on to announcements and awards. Over the last four years we’ve done upwards of 440. I’ve watched almost all of them.

For everyone who attends this session, it celebrates people and accomplishments; it drives alignment around mission, strategy and priorities; and finally, it provides a forum to ask and answer questions. (Thanks for that excellent article Gokul).

Each presenter needs to make the most of this opportunity because talking about your work is as important as the work itself. The challenge is to get so good at presenting a technical demo that others feel compelled to celebrate your work, change their outlook, and share your story. That means making it succinct, informative, and relevant.

The leap from paper to the stage is huge – the way our ideas sound in our head is not at all how they sound out loud. Here are five ways to elevate a mediocre technical demo to a great one.

1. A suitcase walks into a bar… The value of a good story

The Bar Test

Kevin Curtis from Unsplash

Steven Smith summarized a lesson from his ROTC training as the message received is the message. Meaning that if the audience doesn’t understand what you’re showing them, the problem is not with the audience.

There is a simple, lightweight, and effective litmus test of how your message will be received before you put effort into preparing a demo. It’s called the Bar Test and it comes from the design company IDEO. In an article from the First Round Review, Nicole Kahn explains how to craft a good presentation by first finding good story. Finding a good story means grabbing a colleague – ideally someone who is not intimately connected to your work – and verbalizing the intent of your presentation as if you were in a casual place – like a bar. Then look for the cues:

When you do this with your colleagues or friends and family, pay attention to the little things, Kahn says. “We look for when they lean in, or when they look away or reach for their phone. We look for nods and ‘uh huhs’ — we look for what surprises and delights. That’s how we figure out what’s sticky and resonating.

This is a cheap and effective way to find out if people understand you. Do it early, so you can iterate towards that ‘aha’ moment without any sunk costs.

The Oxygen Test / The Suitcase Test

Erwan Hesry on Unsplash

In 1940 Winston Churchill made a request to his cabinet for brevity in the interest of expediency.

To do our work we all have to read a mass of papers. Nearly all of them are too long. This wastes time, while energy has to be spent in looking for the essential points.

I ask my colleagues and their staffs to see to it that their Reports are shorter.

Reports drawn up on the lines I propose may at first seem rough as compared with the flat surface of officialese jargon. But the saving in time will be great, while the discipline of setting out the real points concisely will prove and aid to clearer thinking.

The same applies to presentations. All of us have a love of stories and we all have a short attention span.

Jeff Lawson calls this the Oxygen Test: review your points but only keep the essentials. The goal is to keep those only that are natural and indispensable, like oxygen.” 

I like a suitcase analogy: How many times have you gone on vacation and used everything in your suitcase? Next time, put everything you intend to pack onto your bed, then put only half of it back into your suitcase. I tried this and I still didn’t use all my stuff. After the Bar Test, take a page from Churchill and Jeff and be ruthless with what you bring (or keep) in your presentation.

2. Every writer needs an editor

Do you re-read your emails before hitting ‘send’? Do you ask for a code review before shipping? Do you write a unit test before shipping? Good. An editor or a sounding-board helps us see and hear the things we cannot. During each iteration of your presentation, like the Bar Test, grab a colleague and practice with them, and let them help you see the gaps.

3. Get post-presentation feedback

Before you present, ask a member of the audience you trust to provide you with candid feedback on how you did. If you find yourself in the audience and you care personally about the person presenting, then pay it forward by doing them a favour: take notes and afterwards follow-up with them with written, candid and constructive guidance, and encouragement to iterate on this experience as soon as possible.

Even better if you record the presentations so you can view yourself later.

4. Does anyone know what a ‘good technical demo’ looks like?

I loved the concept of Ben Horowitz’s “Good Product Manager / Bad Product Manager” because it sets expectations. His example inspired me to write “Good Presenter / Bad Presenter”. It is referenced on our Demo signup page.

“Production” means products that you’ve shipped and that customers are actively using today. A customer is the person or system whose pain you are trying to solve by shipping.

5. If it’s painful, do it often

Via Martin Fowler

James Clear writes about the difference between passive knowledge and active practice. Any software engineer can read about how to give a good technical demo, the only way to understand what it’s like to give a technical demo is to give one.

Introverted? Me too. Years of practice helped me overcome my unease of standing up in front of a crowd. Imposter syndrome? Me too. Remember you’re on stage to start a conversation about your understanding of a topic, not to speak as the world authority on the topic. Nervous? Me too. Find a mantra like Jean-Claude Killy’s to downplay the consequences of failure and detach your anxiety from the situation.

The next time you have the opportunity to speak in public, take it, and put in the effort to get across your accomplishments and ideas succinctly and emotionally so the people in your audience grab those ideas, remember them, and share them.


Thank you

To Neil for his demos, and to Lindsay for being my editor.

About the Author

Noel Pullen 200x200 Noel focuses on culture, employee engagement, technical community involvement, and training for Hootsuite’s technical groups. He loves to exchange ideas and would like to hear how you do these things at your organization. Get in touch via LinkedIn.