Scott Hanselman

11 Top Tips for a Successful Technical Presentation

May 17, '08 Comments [42] Posted in Speaking
Sponsored By

image 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.

1. Have a Reset Strategy (One-Click)

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.

2. Know Your Affectations (Ssssssseriously)

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.

3. Know When To Move and When To Not Move (Red light!)

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.

4. For the Love of All That Is Holy, FONT SIZE, People (See that?)

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.

5. Speak their Language (Know the Audience)

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?

6. Be Utterly Prepared (No excuses)

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.

7. CONTENT, CONTENT, CONTENT (Have some)

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.

8. System Setup (Be unique, but don't be nuts)

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.

9. Speaking (Um…)

"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.

10. Advancing Slides (No lasers!)

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.

11. Care (deeply)

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?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Saturday, May 17, 2008 6:34:03 AM UTC
I try to zip/archive my deck+code ahead of time, and make it available for download before the presentation. Then I list this link on the welcome slide. This gives the early arrivers a chance to download the code. Few do ... but it's a nice touch.

This also upfront answers the all so common "will your slides and code be available" question.

As for your one click reset - this has also saved me a few times when my personal machine stopped working (or once was incompatible with the projector). Just download the code on a guest machine, spend 2 or 3 minutes getting setup, and - I was back in business.
Saturday, May 17, 2008 6:59:51 AM UTC
Thanks for the tips Scott.

I read a book that change my presentations, it's the "beyond bullet points by Cliff Atkinson". When I did a presentation in the style Cliff write in the book, I got several good feeback like, Interesting presention style I like it etc.
Saturday, May 17, 2008 7:03:22 AM UTC
Nice Post, well done. Thank you.
Saturday, May 17, 2008 8:13:05 AM UTC
I always try to learn by watching other people. Over numerous presentations I have attended, I have always noted things that I must avoid in my presentations. One of them is presenter talking to him/herself during demos. I find this to be very annoying because it disconnects the audience immediately and they feel left out. Also, while doing a live demo things at times do not worked as planned. For example the code which compiled ten thousand times at home refuses to build at a demo. In such cases I make it a joint learning exercise and involve my audience to participate in resolving the issue. I am still learning and improving my public speaking by watching others. These were just my 2 cents.
Saturday, May 17, 2008 8:16:16 AM UTC
Very interesting and useful post, thanks! May be you could also post your time-management tips? It seems like you are even better at that!
Konstantin
Saturday, May 17, 2008 8:33:07 AM UTC
Precise as always, I love your tips :-)
Saturday, May 17, 2008 10:27:25 AM UTC
Beyond Bullet Points is a great book indeed, so it Presentation Zen.
They both insist on using a less textual and more visual approach that respects how your audience learn.
The best advice I can offer on creating effective presentations: tell people STORIES they can identify with.

Take MVC. You may start showing a concrete problem you faced with webforms, say testability (or lack of separation of concerns, or its leaky abstractions, etc) in one of your applications. Tell them the frustration you felt and why you cared. Then your dilemma. You heard about MVC and you are unsure if it will alleviate your pain or just bring tons of other problems. Should I go MVC, should I not? Go deep, explain some fundamental bits of it. Then a turning point. You are still learning and evaluating when something brutal happens: your current application fails and lack of unit testing on the UI is something you can't live with anymore. Your team decides unanimously: it's MVC! What problems did you face? What were the first obstacles? Did you succeed or failed? How about consequences and lessons learned? I believe, you can explain technology through personal discovery and action. Now, THAT could be the basis for a truly memorable presentation, wouldn't you agree?
Saturday, May 17, 2008 12:09:00 PM UTC
Great tips! Many things you mentioned I wasn't aware of! This will help me a lot for my next speech next week.. theoretically. But I'll try to do my best!

Thanks!
Saturday, May 17, 2008 1:09:20 PM UTC
Talking about a BSOD, I just had one during a presentation :(. I give about one presentation a week, and this was the first time that ever happened to me. I guess there's not much you can do about that, can you...?

What I also always do:
-prep my second laptop, and have it in my car
-upload slides and demo's to webmail or something like that
-always use the presenter (I have the Logitech Presenter and have the Microsoft Presenter Mouse that I only use as mouse. The latter one has issues with signals, the Logitech is more precise)

Saturday, May 17, 2008 2:04:28 PM UTC
Very pragmatic and useful tips. I think most technical people have an inner problem speaking and presenting in public because the majority are introverts, but that shouldn't stop them from excelling at something they're not very comfortable in.

A while back I wrote about 8 Simple Tips To Improve Your Presentation Skills. I hope it will be a good complement to your own tips.

Thanks!
Saturday, May 17, 2008 2:38:48 PM UTC
I always find that seeing someone give a talk well is a good way to learn. Also seeing a talk given poorly as a demonstration of what not to do is a learning experience.

That's why when you and I give a talk together, it's a true learning experience because we embody both of these teaching patterns. You cover the the former and I cover the latter. :)
Saturday, May 17, 2008 4:17:39 PM UTC
I couldn't agree more on point 10. It's distracting to the audience when the presenter is doing a foot race back and forth from the screen to his keyboard. A while back I invested in a Targus presenters mouse, the AMP01US. In addition to the forward/back buttons, it has a laser and trackball so I can actually manipulate the mouse and do some simple demos (opening menus, running apps, etc) without having to run back to the computer. As a presenter it was one of the greatest investments I've made.

It's quite liberating to not be stuck at my computer, and be able to stand by the screen. I recall one venue where the screen was on one side of the stage, but the podium was clear on the other, a good 30 feet away. That little mouse is a lifesaver.

Sucks batteries though, so as a Twitter friend (PlatinumBay) just reminded me always be sure to carry spare batteries for your mouse. I use rechargeable enegizers, carry several sets, so I before every presentation I just slip in a fresh set so I know I won't have any problems.

I highly encourage anyone who does presentations to invest in some sort of device, whether it be the MS 8000 Scott mentioned, the AMP01US, or even a low end 30 dollar device that just advances slides. Anything that will let you step away from the podium will help you connect to the audience, and you will definitely be happier too.
Saturday, May 17, 2008 4:34:50 PM UTC
Scott, these are great tips. I have also noticed that the audience (especially developers) feel more comfortable asking questions while you show them source code and do a live demo rather than showing videos/screenshots

Speaking of things going wrong [true story]: Don't forget your laptop adapter at home and realize you have 40% battery on the machine, power paranoia interferes with the presentation!
Saturday, May 17, 2008 5:37:24 PM UTC
Good points, Scott.

I learned public speaking in the Canadian Military and there is a surprising amount of overlap with their training and your advice. They called affectations and ums word whispers: the little things people say while they're retrieving the next thought. I say "Ok?" a lot. By far the worst are um and uh.

The thing is, as soon as you're aware of word whispers, you can't not hear them, when you speak and especially when others speak.

That's why it's best to practice what you're saying. Write it out and practice, practice, practice. When you've practiced the presentation, the content is there in your brain and it'll come out quite easily with a minimum of word whispers. Then don't bring notes to the talk, they'll distract you from speaking naturally to the audience. The only time I'd allow someone to not write it out is if it's something they've been doing to for at least a few months every day.

Another basic tip that is so hard to do is to look at the laptop and trust that what's on the laptop is on the screen. Nothing distracts me more than a presenter who is looking at the screen more than the audience.
Saturday, May 17, 2008 6:42:59 PM UTC
Dodge the bullets, care about narrative, kill your darlings.
Saturday, May 17, 2008 8:03:45 PM UTC
One thing people usually do NOT do is change their voice. Monotone is the death knell of attention in any presentation!

This kind of fits into some of the categories above but I think it deserves a bullet point of its own. Even altering your voice level to an extreme like throwing a raised voice hollar out to the crowd, even utilizing a mumble can even make people pay attention sometimes (in rare occasions).

The raised voice works very well when there are several one after another points that are brought up in rapid fire. This can easily happen speaking on technical topics.

I've actually noticed mumbling can be a good comic recourse when there are some necessary steps that are tedious in a presentation. Like I said above though, this is something that must be done with extreme care as to not distract, the point being to add levity to a topic.

Both of these are things that Balmer, Jobs, and other have done numerous times to present the technical topics of computers in an exiting light, for the not so technical populace. Generally I've seen it work well with techy topics for the techie hard core too. :)

Just my 2 cents.
Saturday, May 17, 2008 10:00:57 PM UTC
When I worked in Radio I would record my voice every time I opened the mike and be my own critic after the show.

Good post and I hope you passed the audition.
Saturday, May 17, 2008 10:14:32 PM UTC
One of the things I've been trying to do is to make sure each slide only has one or two concepts on it. That means I have a lot more slides, but it keeps people from "reading ahead" - I think people tend to get bored if they already know the next 5 points you're going to make because you put them in a bulleted list.

Another thing is to watch the audience. I've seen a lot of presenters who don't seem to be aware that their audience is falling asleep or breaking eye contact during a particularly boring part of the proesentation - it should be a cue to either move on or change up how you're presenting.

I still have a lot of trouble with unexpected glitches in my presentation though. Every time I Alt+Tab to Eclipse and it decides to go out to lunch I just get totally confounded.
Saturday, May 17, 2008 10:25:43 PM UTC
Great and useful tips. Glad to hear you tips, since they reminded me of some past tips I had pick up on some presentation and public speaking seminars. Sometimes you have to hear things several times before one makes it ones own. I'm about to create my first blog and will keep your tips in mine.
Sunday, May 18, 2008 12:04:35 AM UTC
Like you Scott I've given a lot of talks. One of my craziest moments came a little over a year ago when I gave a talk and unplugged the projector! I was walking from a spot to a spot I had picked out for effect and on my way back to the laptop I tripped on the projector cord in the floor (never noticed it before) and unplugged the projector. If you know projectors, yeah.... they don't like being just cut off and not cooled down. It wouldn't turn back on. I was dead. LIke you said, KNOW YOUR DEMOS AND CONTENT. Once I realized it wasn't going to come back on, I grabbed a dry eraser pen and started drawing and writing on the white board. Everyone had a good laugh and I still think they managed to get something out of it in the end.
Sunday, May 18, 2008 8:45:54 AM UTC

Very good post. I have seen you present before a few times and I noticed you are "trying" to be a good presenter. :)

Another point is: do not depend on availability of the web. Make local copies of the web pages you are going to show. If the web is not available during the presentation, switch to local copies. Or just use them from the start. They load faster and have the assurance of availability.

Abdu
Sunday, May 18, 2008 12:29:08 PM UTC
That's a great post. Another tip would be to test run your presentations to a group of peers and have them critique your presentations afterward. It will help identify weak or missing areas and it help you to adjust the content to match the time allotted for the presentation.
Monday, May 19, 2008 4:40:40 AM UTC
The tip I'd add, when using Visual Studio, is to CLOSE (as in gone, click the little 'x') all panels that you won't be using (Properties, Error list, etc). Auto-hide the other panels that you'll occasionally be using (Project explorer, toolbox) , so that during the demo, the entire window so devoted to the source code.
Monday, May 19, 2008 9:13:49 AM UTC
Great advices Scott.
I've been doing presentations and trainings to our foreign customers, but I am absolutely NOT a professional public speaker. I'm more a "oh well, I'll invent something tomorrow before the presentation starts" type.

But the two things that I would add to your list are (depending on the audience, of course):

1. Make them smile. Without exaggerating, sometimes a little joke about yourself, or your product, or the world in general, is good to keep the audience in a good mood to listen to you, IF you have a good sense of humor. Besides, it's a good way to see who's asleep...

2. Accept your faults (and the ones of your team, too). You, oh mighty XYZ evangelist speaker, are NOT a programmer god, your program has bugs, and is still missing some key features that your audience was expecting. Delivering a 100% good product is impossible, you know it, they know it, so don't try to BS them... Over the years, I've found out that talking freely with your end-users during presentations about the problems of your product is always good for your relationships in the long term. Of course, this is only valid if you've actually ALREADY SOLD them your product ;-)

BTW, my overused word during presentations is "basically".
Monday, May 19, 2008 9:59:08 AM UTC
Great post, Scott. This is why you are where you are today: you give a damn. About your audience, about your content, about sharing with others and trying to improve our often backward industry.

"YOU are the content, and your slides are your Table of Contents". Love that one.
Andrew
Monday, May 19, 2008 11:03:45 AM UTC
test
cheeto
Monday, May 19, 2008 11:49:19 AM UTC
I have to disagree on "any [...] proportionally spaced font [...] is NOT appropriate for code demonstrations, period, full stop".

While monospaced fonts do have their place whenever text has to be linied up on character boundaries across multiple lines, they have a major disadvantage for .NET code with its typical long identifier names: they tend to use much horizontal space. This may not be a problem on a widescreen TFT, but on a typical 1024x768 presentation beamer, using a monospaced font in readable size, will force the presenter to scroll the editor window horizontally sooner or later (at least when showing "real world code" using proper identifier names).

A bit of scrolling is not a problem, but I have watched many presentations where I almost got motion sickness. It makes me mad knowing that in most cases switching to a proportional font would have reduced the amount of scrolling significantly, without reducing readability.
I do agree that Arial is bad for source code (problem: lowercase L vs. uppercase i), but Tahoma or Verdana are definitely ok (they have serifs for the uppercase i)
Roland
Monday, May 19, 2008 2:00:55 PM UTC
http://www.milindspandit.org/blog/?p=264
Monday, May 19, 2008 3:20:02 PM UTC
The reason "green on black" works is the eye "sees" green better than other colors. I don't remember where I saw this, but that's the reason that military "night vision" stuff is all green. Unfortunately I don't have a link to any study to back this up, but I remember reading / seeing this somewhere.
Chad
Monday, May 19, 2008 6:14:42 PM UTC
I've had a lot of experience with giving presentations in a variety of settings and I've been to hundreds of them as well. Here's my thoughts on the issue, something I call "How to give a presentation to people who can read"
http://agilology.blogspot.com/2008/03/how-to-give-presentation-to-people-who.html
Monday, May 19, 2008 9:04:09 PM UTC
Do not ask Phil Haack in the middle of the presentatin to open the Stack when he is not ready for that!!
Tuesday, May 20, 2008 3:41:45 AM UTC
More on speech affectations:
"Spontaneous speech is filled with disfluencies—unwanted pauses, elongated segments, fillers (such as uh and um), editing expressions (such as I mean and you know), word fragments, self-corrections, and repeated words. Most disfluencies seem to reflect planning problems. When speakers cannot formulate an entire utterance at once, they may suspend their speech and introduce a pause or filler before going on. And when speakers change their minds about what they are saying, they may suspend their speech and then add to, delete, or replace words they have already produced." -- Repeating words in spontaneous speech. Herbert H. Clark and Thomas Wasow, COGNITIVE PSYCHOLOGY 37, 201–242 (1998)
Tuesday, May 20, 2008 3:38:56 PM UTC
Scott,
Great tips, especially about the "One-Click-Reset."
I often conduct training courses, where we have multiple instructors to keep the class lively, and the students intrested. The problem we run into is the other instructors are standing in the back of the room, if the speaker, mis-speakes, or mis-understands a question, there is a tendence for a senior instructor at the back of the room to interupt and correct the statement. We've found that this reduces the credibility of the speaker, and ultimately lowers the confidence of the students. Its much better to wait until the next transistion, and have the instructor who is going on to give a carefully worded "re-statement of the issue." This way the first instructor is able to finish their module without the interuptions, and the new speaker actually has more credibility from the start.
Tuesday, May 20, 2008 4:08:27 PM UTC
Re: #2

An affectation is the act of behaving or talking in a way that is not natural or genuine. I wouldn't describe a lisp in that way (unless your Mel Blanc), and I certainly don't know how you would change it. I had a pronounced lisp as a child, but was fortunate enough to get speech therapy while in grade school. Even so, like you, I still have a slight lisp. So, like, um, how do you deal with it?
Sean S
Wednesday, May 21, 2008 12:37:36 PM UTC
My best tip is having the latest edition of XMLSpy installed of course :) Besides that, this is a great post to review before any technical presentation. Thanks to Scott and the comments!!!
Friday, May 23, 2008 3:00:38 PM UTC
My suggestions I would add:

Don't write to much code. Either put it in snippets (in VS), or just have a copy of code snippets in textpad or such.

Have a separate project of your demo that you know compiles. When all else fails you can pull up your working copy.

Don't be afraid to tell the audience you don't know. I happily admit that I would need to ask google if I'm not sure what the answer to a question is.

Black box parts of code that don't matter. Some presenters feel like they need to explain what every line of code does. Focus on the parts of code that matter to the subject matter your teaching. For example I give a talk on writing cmdlets for powershell. The cmdlets I present are very simple, because the point of the presentation is to teach about cmdlets, not the cool thing the cmdlet is actually doing.

As soon as possible write down notes to yourself on how you could do better. Revise your slide deck every time you present (or almost every time at least).
Tuesday, May 27, 2008 1:52:39 PM UTC
Great collection of tips. Just watched your Mix MVC presentation you did a great job. Wish I could have been there.
Monday, June 02, 2008 11:47:21 AM UTC
These are wonderful suggestions. For people that would like to join a group that have the support of 10 - 30 people in helping people learn about public speaking and leadership, I would also suggest locating a Toastmaster's group in your area. When you join the group, you are asked to follow a series of 10 speeches to aid you in learning the skills that were listed. The group also supplies a mentor to help you achieve the goals that you would like.
Amy
Thursday, June 05, 2008 1:13:15 PM UTC
Great tips! Some I never really thought about but make sense.
Friday, June 20, 2008 3:31:31 PM UTC
Looks like someone liked your post so much they ripped it off...or maybe you wrote this:

http://howto.wired.com/wiki/Make_a_Presentation_Like_Al_Gore

Roma
Monday, June 23, 2008 4:18:03 PM UTC
I really love your post about technical presentations. I work for the Optical Society of America and I was wondering if you knew anyone who would be a fantastic speaker for delivering a 1 hr interactive session about Successful Technical Presentations? I would think you'd be ideal, aside from the fact that your area of interest is computers. What do you think? Any suggestions? Would it fly if you did it? What is your speaker's fee?

Best regards,
KiKi
klital@osa.org
Monday, June 23, 2008 4:21:17 PM UTC
Thanks for your great post! I work for the Optical Society of America and we are looking for a person who can speak to an audience of optics and photonics grad students about improving their technical presentation skills. I'm not sure if you would be interested in doing this or if you know someone who would, but we would reimburse travel costs and supply some kind of speaker's fee. Please let me know if you are interested.
Best regards,
KiKi
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.