Over five years ago I posted Tips for a Successful MSFT Presentation. Yesterday I watched the video of my Mix Presentation all the way through. It's always very painful to hear one's own voice but it's even worse to watch yourself. I never listen to my podcast and I avoid watching myself. It's like watching a person in parallel universe and it inspires self-loathing. However, if you are someone who values continuous improvement - and I am - you need to do the uncomfortable.
Here's my five-years-later Updated Tips for a Successful Technical Presentation.
If you're going to give a talk, you'll probably have to give it more than once. If you have demonstrations of any kind, have a "one-click" way to reset them. This might be a batch file or Powershell script that drops a modified database and reattaches a fresh one, or copies template files over ones you modify during your demo.
Personally, I'm sold on Virtual Machines. I have seven VMs on a small, fast portable USB drive that will let me do roughly 12 different presentations at the drop of a hat. You never know when you'll be called upon to give a demo. With a Virtual Machine I can turn on "Undo Disks" after I've prepared the talk, and my reset strategy is to just turn off the VM and select "Delete Changes." A little up-front preparation means one less thing for you to panic about the day of the talk.
I have a bit of a lisp, it seems. I also hold my shoulders a little higher than is natural which causes my neck to tighten up. I also pick a different word, without realizing it, and overuse it in every talk. This is similar to how Microsoft Employees overuse the word "so" (which is actually Northwestern Americans, not MSFTies) too much.
It's important to know YOUR affectations so you can change them. They may be weakening your talk. Don't try to remember them all, though. Just pick two or three and focus on replacing them with something less detracting. Don't overanalyze or beat yourself up, though. I've spoken hundreds of times over the last 15 years and I'm always taking two-steps forward and one step back. The point is to try, not to succeed absolutely.
One of the most powerful tips I ever received was this: "When you move, they look at you. When you stop, they look at the screen." Use this to your advantage. Don't pace randomly, idley or unconsciously. Don't rock back and forth on your heels. Also, empty your pockets if you tend to fiddle with lose change or your keys.
It just tears me up. It physically makes me ill. To give a presentation and utter the words "um, you probably won't be able to see this" does everyone in the room a disservice. Do NOT use the moment of the presentation as your time to do the font resizing.
Lucida Console, 14 to 18pt, Bold. Consider this my gift to you. This is the most readable, mono-spaced font out there. Courier of any flavor or Arial (or any other proportionally spaced font) is NOT appropriate for code demonstrations, period, full stop. Prepare your machine AHEAD OF TIME. Nothing disrespects an audience like making them wait while you ask "Can you see this 8 point font? No? Oh, let me change it while you wait." Setup every program you could possibly use, including all Command Prompt shortcuts, before you begin your presentation. That includes VS.NET, Notepad, XMLSpy, and any others, including any small utilities.
I've found that the most readable setup for Command Prompts is a Black Background and with the Foreground Text set to Kermit Green (ala "Green Screen." Yes, I was suspicious and disbelieving also, but believe it or not, it really works.) I set Command Prompts to Lucida Console, 14 to 18pt, Bold as well, with much success.
Also, set the font size to LARGEST in Internet Explorer and remember that there are accessibility features in IE that allow you to include your own Large Font CSS file for those web pages that force a small font via CSS.
Learn how to use ZoomIt and practice before-hand. It can be an incredibly powerful tool for calling out sections of the screen and making it so even the folks way in the back can see what's going on.
For simplicities' sake, I like to keep a separate user around call "BigFonty" (choose your own name). He's an Administrator on the local machine and he exists ONLY for the purposes of demonstrations. All the fonts are large for all programs, large icons, great colors, etc. It's the easiest way to set all these settings once and always have them easily available.
When I was in Malaysia for TechEd, I spent 3 full days exclusively with locals before the talk, I learned snippets of each of the languages, tried to understand their jokes and get an idea about what was important to people in Malaysia. American analogies, much humor, and certain "U.S. specific" English colloquialisms just didn't make any sense to them. When it came time to give the presentations, I better understood the Malaysian sense of timing, of tone and timbre, and I began each of my presentations by speaking in Bahasa Malaysia. I changed aspects of my slides to remove inappropriate content and add specific details that would be important to them.
I've used this same technique in a half-dozen countries with success. While this is an extreme example, the parallels with any audience are clear. If you're speaking to a room full of IT guys who work in the Automotive field, or the Banking industry, the fact that we are all programmers only gives you a small degree of shared experience. Remember no matter the technical topic, try to get into the mind of the audience and ask yourself, why are they here and what can I tell them that will not be a waste of their time. What would YOU want to hear (and HOW would you like to hear it) if you were sitting there?
Short of an unexpected BSOD (and even then, be ready) you should be prepared for ANYTHING. You should know EVERY inch of your demos and EXACTLY what can go wrong. Nothing kills your credibility more than an error that you DON'T understand. Errors and screw-ups happen ALL the time in Presentations. They can even INCREASE your credibility if you recover gracefully and EXPLAIN what happened. "Ah, this is a common mistake that I've made, and here's what you should watch for." Be prepared with phrases that will turn the unfortunate incident around and provide them useful information.
Every move, phrase, mistake, anecdote and slide should actually contain content. It should be meaningful. Your mistakes should teach them, your demos should teach them; even your shortcut keys, utilities and menu layout should teach them. A presentation isn't an opportunity to read your slides. I'll say that again. Don't READ your slides. I can read faster than you can talk.
Remember that most people can read silently to themselves 5 to 10 times faster that you can read to them out loud. Your job as a presenter is to read in between the lines, and provide them structure. Your slides should be treated as your outline – they are structure, scaffolding, nothing more. If you jam your slides full of details and dozens of bullets, you might as well take your content and write an article. It's difficult to listen to someone talk and read their slides at the same time – remember that when you design your content. YOU are the content, and your slides are your Table of Contents.
When you a presenting, remember that you are looked upon as an authority. Basically, you are innocent until proven guilty. It's great to have a personality and to be unique, but don't let your personal choice of editors or crazy color scheme obscure the good information you're presenting. I appreciate that you may like to use VI or emacs to view text files, but let's just say that sometimes Notepad has a calming effect on the audience.
I give Microsoft talks, usually, so I tend towards Visual Studio, but 99% of my talks use a limited number of tools. Basically Visual Studio, Notepad, the Command Prompt and a Browser.
Remember that while you may prefer things a certain way while your face is a foot away from the screen, it's very likely the wrong setup when 500 people are more than 100 feet away.
I really like to get Toolbars and things out of the way. I use F11 (Fullscreen) in the Browser a lot, as well as Visual Studio's Shift-Alt-Enter shortcut to FullScreen. Turn off unneeded flair and toolbars. Also, turn on line-numbering so you can refer to lines if you're presenting code.
"Volume and Diction," my High School Drama teacher said to me. Speak clearly, authoritatively, project your voice to the back of the room. The best speakers don't even need microphones. If you have a speaking affectation (I had a lisp growing up) or you tend to say, um, etc, or find yourself overusing a specific phrase ("a priori", "fantastic", "powerful", etc) take it upon yourself to NOTICE this mannerism and avoid it.
Practice multi-tasking. It seems silly to say, but although we can all multitask to a certain degree, when we hit a real snag in a presentation, many of us tend to freeze. Silence is deadly. Remember, since all eyes are on you, complete silence and apparent introspection says "I don't know know what I'm doing." When you need to get to a particular file, don't make the audience wait for you while you putter through explorer. Have shortcuts ready (and explain when you use them). Move fast and efficiently, but annotate your actions. You should continue to "color-commentate" your actions like a sports announcer. Don't allow "dead-air," unless it's silence for effect.
I always used to hate slide-advancers, you know, those little remotes with forward and backward buttons. Then I tried one and I'm hooked. I use the Microsoft Presenter Mouse 8000 and totally recommend it. It isn't just a great Bluetooth mouse, but flip it over and it's a great Powerpoint slide advancer.
Take a look at Al Gore's excellent presentation in "An Inconvenient Truth." It's seamless and flows. Now imagine him running over to his laptop to hit the spacebar each time he wanted to advance a slide. My presentations have gotten better as I've started incorporating this technique.
I really avoid presenting on topics that I don't care about. I avoid it like the Plague and I encourage you to do so as well. There's nothing more important that truly caring about your topic. If you care, it'll show. If you eschew all the other tips, at the very least care.
What are YOUR tips, Dear Reader? What tips, mantras or preparations have you used to make your presentations that much better?
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.