Five Tips for Technical Presenters
The other day, I went digging through my notes from and old conference (Software Development West ‘03) in search of the answer to a software design question. I didn’t find what I was looking for, but instead I came across some of my margin notes critiquing various presentations. You see, I was giving a lot of presentations myself back then, almost one a week. I gave speeches at user groups and at our company’s weekly “tech talks.” I also used to pinch-hit for our company’s trainers from time to time. So, whenever I was in an audience, I had a habit of paying attention to style as much as substance.
So, for those of you who are tapped from time to time to give a presentation, here are the tips I gleaned from my observations at that conference:
Avoid Ambiguous Examples: When Hillsdale and Bodkin introduced Aspect-Oriented programming to the SD West ’03 crowd, it was well-received. Their only slip-up was the example they used. It was a little drawing program that dealt with lines and points that were combined to make triangles, rectangles, etc.. Unfortunately, the word “point” is a key term for aspect oriented programming (AspectJ), referring to a point in the program code. So, the word came up quite often throughout the talk. Now, it wasn’t terribly hard to discern which of the two meanings each utterance took, but there definitely was some extra work on the part of the listener, and it was a unnecessarily distracting.
Let Macros Do the Typing: When giving a live demonstration of software development, consider programming macros to do the bulk of the typing for you. Josh Kerievsky had the right idea when he used a version control system to keep track of snapshots of a test-driven development example (for his talk, “Evolutionary Design with Java, Testing, Refactoring & Patterns”). Unfortunately, the time it took to compare and/or restore each snapshot was unwieldy. If not macros, then, at least, have a text file open that contains copies of the longer snippets of code, so that you can copy and paste. Nothing is more disheartening than to see a room full of audience members who, in the case of a large conference like this one, each paid thousands of dollars to be there, have their time wasted while the presenter types in text (and then fumbles over typos).
Present a Collection of “Mini” Papers: Ken Schwaber and Mary Poppendieck tag-teamed a presentation about various sub-topics of agile development methodologies. Their PowerPoints included a new title page every time they switched off — as if the next portion of the presentation was a completely separate talk. I don’t know if it was planned that way, but I’ve found since that organizing my own speeches like that it sure makes it easy to reuse the material later. Putting together a presentation in that manner accommodates being able to adjust for time, adjusting for speaking partner availability, and adjusting for audience relevance.
Avoid Multiple Handouts: When preparing handouts, I always make sure they are all stapled together (one packet per person). As my observations from this conference reminded me, trying to make sure each person gets one of each of multiple handouts never works and wastes a lot of time. (Note: This tip does not necessarily apply to situations where attendees are expected to bring their own printouts.)
Lastly, Get to the Point Quickly: Presenting the background material shouldn’t take longer than 5-10 minutes. If not, then perhaps the topic is under classified (beginner, intermediate, advanced, guru), or the necessary prerequisites are not correctly identified. If more than 10 minutes worth of background material is really necessary, then consider spreading it throughout the lecture, so that each piece of relevant background information is presented right before it’s actually needed. At the very least, include an agenda slide up front that declares how long it will take to get to the meat.
One corollary to this tip: Jokes and funny stories longer than one-liners should be avoided. (Unless you happen to be a professional stand-up comedian at night, it would be best to stick to your core competency.) Levity is great. Brevity is better.
Read more: Productivity