I am preparing a technical presentation for my team.
Audience : Our team
Topic : Introduction to a new technology
So I want to know about the primary necessary things for a good technical presentation and also DOs and DON'Ts for the same.

some of my concerns are,
1. Whether to have slides or not (if needed then how many of them)
2. Coding a sample during presentation or preparing it before going for the presentation
3. Maximum duration of an technical presentation

What is your thoughts on technical presentations from your past experience either as a presenter or as a listener.

+20  A: 

If you are planning to demo code at a presentation, I always prefer to have a working copy of the code you plan to write/demo already there in a text editor, so that you can copy straight into IDE in the event of a) time constraints and b) total disaster or c) memory loss and dry mouth syndrom ;-)

Oh, and don't try and cover too much - if your demo is too lengthy or ambitious, you will lose a few people. Keep live code demos pretty simple.

Good luck with it!

+41  A: 


  • Read what is written on the slides, the audience reads it much faster than you.
  • Put your hands in your pockets.
  • Put long text. Keep it small, If you put long text people will lose more time reading it than actually listening to you.
  • Play with small objects in your hands. It's a sign of being nervous.
  • Don't use extended examples.


  • Keep it in topics and subtopics, you'll be explaining the content.
  • Use small examples.
  • Images and diagrams, as this helps for the audience to get a better flow of what you're saying.
  • If you put code in try to keep it simple, for example if you put a complex XML or something, most people won't even try to start reading it.
  • Use real world off-topic examples to help your viewers keep focus, as you can exit from the "technical" part for 1 minute in order conquer their attention again.
i can add don't use bullet points. that forces you to present things in a much more creative way.
+14  A: 

Personally I quite like flicking between PPT and the IDE, spending most of the time in the IDE. I've been caught out before coming up with examples on the fly - even if you're going to code in front of people, know what you're going to do first. (On the other hand, be prepared to experiment and try things suggested by the audience too.)

Most importantly: know your stuff. Don't try to present something you only read about the night before. You will be caught out, and you won't be adding much value. The best presentations I've been to have been the ones where you can ask the presenter to go into more depth about just about anything on the topic, and they can do so. On a related point, try to leave plenty of time for questions and be ready to adapt the presentation to what the audience find interesting.

Jon Skeet
"know what you're going to do first" -- as in dry run the entire presentation, step-by-step, to be sure it absolutely works with no questions or surprises.
+1  A: 

Powerpoint slides can be helpful to keep you on track and organized. However, I've gleaned the following tips:

  • Use the ppt slides as a very basic outline and do most of the presentation as hands-on or "demo" showing the actual tech whenever possible

  • Keep it short and/or provide breaks frequently

  • Use screenshots and other media in the slides when possible to create more interest and clarify any visual concepts

  • Avoid getting caught up in extreme details unless necessary to the presentation, and make sure there are companion documents or example files available to participants so they aren't as concerned with minutia beyond the scope of the presentation

  • Plan time for questions, and don't create too many slides. I've seen people with over a hundred slides prepared for a technical briefing, and it always ends badly. Summarize briefly and use appendices for additional documentation; treat it much like a classroom lecture where the salient points are presented but extensive research is left for outside the class.


As usual, the right answer is "It depends". The first things to identify are:

  • Target: Is my audience already aware of this technology or not? This will lead your introduction and your... (see the next point)
  • Scope: Is it an overview or an in-deep presentation? This will impact on your duration.
  • When: Is it in the moring, the afternoon, after lunch? Depending of the answer, be aware on how reactive your audience will be.
  • Reactivity: Are you well prepared to answer "on-the-fly" question, or do you prefer to put all the questions at the end, to summarize a bit.
  • What's next: Is there a plan to use what you presented after? If so, a quick prototyping may help getting interest.
+1  A: 

I always find it useful to take a 'handout-style' printout of all the slides on paper. This way each page printed out will have about 9 slides on it. So when you are giving your presentation you can keep looking at the printed paper to see what slides are next. This way you know exactly whats coming up in the next slide and you can pace your talk accordingly.

My tech writing background taught me that handouts during a presentation are bad because the audience just sits and reads your handouts and ignores what you have to say. That's been my experience when using handouts as well.
Bob Somers
+1  A: 
  1. Slides (not necessary PPT) are must have. It would be even better if you could distribute print-outs before the meeting (don't forget to recycle them later) as they will help people follow your presentations.
  2. You should have a sample which works already as a back-up plan and some templates or work in progress which you could finish during the presentation
  3. An hour is usually a good time for a presentation. You could do up to 2 but this is the absolute limit. So keep it within 1 - 1.5 hours

EDIT based on the comments feedback: One important thing I forgot to mention is that your PTT/print-outs should not contain your presentation. They should contain the gist of your presentation and help you to save time and effort talking about some minor details which are easier to write than to explain. You have to be able to make your presentation more than just reading from the slides.If you will not then the comments to this post are perfectly valid - just hand out the prints and go away.

Ilya Kochetov
_NEVER_ distribute print-outs BEFORE. If so, they won't pay attention to the presentation itself, ether looking at the paper sheet, either believing that it doesn't matter if they may read it after.
Second that. I also never caught the point for hand-outs in general.If you wnat to give them something to watch it again at home, distribute the ppt.
Thirded. If the printout contains the same information as the presentation, you are no longer necessary.
Dave DuPlantis
Perfectly put, Dave. Same goes for any props that are used during the presentation. If they can stand on their own, you're not adding value by being there.
Andrew Edgecombe
Does handouts make sense in a presentation for a small team?
Instead of handout make the presentation slides available afterwards.
Petteri Hietavirta
If you're doing it for a small team, I'd say you might mention that if anyone want's a copy of the slides you'd be happy to make one for them. But definitely NEVER give out handouts before (or during) the presentation.
Bob Somers
+1  A: 
+2  A: 

Well, being it is for your team (I'm assuming an internal presentation) and also supposing it's a small number of people(?) then I would suggest a more casual approach unless your environment dictates a formal presentation/delivery.

Consider your audience. Is it an all technical audience? IOf you have a mix of technical and non-technical people, it's a good idea to start at a high level (conceptual) and then move into the more technical realms.

Powerpoint slides can be helpful if they are appropriate, if they illustrate a concept or help underpin a point you are trying to make. Don't read from them, they should be used to jog your memory as you discuss your presentation.

Is it a one way street? Are you going to look for audience participation? This can be handy in livening up the event. If people feel like they are part of a presentation, it can make people feel more at ease (and likely they'll walk away with some valuable knowledge).

Beware the demo gods! Keep fully finished solutions/samples ready in case it fails on the day. Worst case scenario: screen cap a working solution. Don't try to fix a broken example in front of people, it just looks bad. Apologise, present your fallback (finished demo/screen shots) and move on.

Finally, Regarding presentation delivery, here's a few "generic" tips:

  1. Try to establish eye contact with the audience,
  2. speak clearly and ensure everyone can hear you.
  3. Know your material (don't be surprised by content),
  4. Rehearse or at least walk through any technical demonstrations in advance,
  5. Use a "clean" Windows profile (if on Windows),
  6. Ensure Outlook and IM programs are closed (nothing worse than an ill-timed IM message)
  7. Ask for questions/invite comment (perhaps at the end if it is convenient)
  8. Provide handouts if it adds value (at the end, not the beginning)
  9. Add humour if it is possible, it livens the mood of the audience if delivered properly a. Ensure your sense of humour is appropriate :)
  10. Ensure you have an introduction, a middle and a clear summary
Be careful with handouts: you don't want the audience reading the handout instead of following the presentation.
Dave DuPlantis
I'd do handouts at the end of the presentation
+6  A: 


  • forget entertainment

This is my only advice. Many interesting and especially technical presentations fail on this regard to entertain the listener just enough to keep them listening actively. Entertainment can come in forms of anecdotes, war stories, puns and jokes.

If you can get a laugh or smile from your audience every couple minutes, they are much more willing to follow you through dryer parts of your presentation, and keep listening to the end. You need this as a brain teaser and to avoid brain shutdown due to information overflow.

And if you follow this advice, i have another one for you:


  • make a fool out of yourself :)
+5  A: 

My 2c worth on presentations:

  1. Provide people with a written handout to go with any slides or other presentation materials you use. Add any code snippets or other supporting materials to the handout. The handout can also have supplementary written material that is not directly presented in the seminar. Also, leave plenty of space for notes on the handouts.

  2. Have a whiteboard in the room so you can do ad-hoc diagramming or sidelines. Powerpoint is inflexible as the presentation cannot be changed quickly enough to adapt on the fly. An alternative means of ad-hoc presentation is useful.

  3. Keep the powerpoint slides brief and in summary. If you want to add more detailed written pieces, add them on the handout described in (1). Read some of the articles on Death by Powerpoint that turn up in a Google search on the topic.

  4. Try to rehearse your presentation beforehand if possible.

Many people get nervous when doing public speaking. If you find a need to bring up your presentation skills you could do a course or join an organisation like Toastmasters. I have never been to Toastmasters or Tecorians but I do have friends who were quite active in these organisations and swear by them as a means of building up self confidence in this sort of situation.

I have found that clear communication (both written and verbal) has been a very useful skill. While I have a reasonable body of technical skills I find that I get the most positive feedback from clarity of communication.

+4  A: 

In my experience, the most important do

  • Practice beforehand! Yes, it's weird to stand in the middle of an empty room talking to your monitor. But it works.

Most important don't:

  • Do not put more than a few words on a slide;

    People often mention the magic rule: “no more than six bullet points”. Bullsh*t. If you're struggeling to eliminate a seventh bullet point, you're doing it wrong: put each bullet point on a separate slide instead!

Finally, watch the following demonstration and be inspired!

OSCON 2005 keynote: Identity 2.0 by Dick Hardt

Konrad Rudolph
+1  A: 
  • I agree that your presentation should not take longer than one hour. Whatever comes after will very likely be lost for much of your audience.

  • Do not try to outsmart your audience. They already assume that you know more than them on the presentation subject. If you keep showing off, you will just make a fool of yourself and they will lose interest.

  • Do not let anybody else show off either. If your presentation is interactive in nature, maybe somebody will try to take the chance to just display their vast knowledge in front of an audience. If necessary, ask them to wait till the end of the presentation.

  • If your level is too high, your audience will not understand you; If it is too low, they will get bored. In any case, they will lose interest. So watch your audience reactions and act accordingly.

+16  A: 

DO read Kathy Sierra's advice on presentations (eg. this)

DO Work out what you're trying to achieve and what you're trying to get across to your audience. And in working that out, make sure that it's at a level suitable for the audience. Too far in either direction is bad.

DO Think before launching into Powerpoint. Do you really need it? Depending on your material your presentation can be much more dynamic and engaging with a big pad full of butchers paper.

DO If you do go down the butchers paper route, make sure that you prepare your "pages" first. Do all of your drawings and writing in pencil on your paper before the presentation. During the presentation do all of your drawing afresh in texta. You can also leave yourself notes or prompts - the rest of the audience won't see them, and it won't spoil the feeling of sponteneity.

DO Do some (if not all) of your drawings during the presentation. Static drawings (as are so often used in Powerpoint presentations) lose the dimension of time - it is much easier to disseminate information about the progression of ideas if you're able to lead the audience without overwhelming them with fancy glitz and flashing things.

DON'T (as a rule) use lists of bullet points. Often people will present a list of bullet points, and start reading through them. The problem is that the audience is usually distracted by reading the points (since you gave them all at once) and won't listen to you while they're doing it.

DO Practice - good presenters (eg. Steve Jobs) claim to use a 10:1 ratio between preparation and the presentation itself.

And, on the subject of Steve Jobs - DO check out this, for a good analysis of slide styles.

(addendum): A short time after this question was posted someone gave me this link to tips on presenting to small audiences.

Andrew Edgecombe
+3  A: 

I presented at WorldComp this past summer and saw a few good presentations and some amazingly bad ones. It bugged me to the point of writing a brief blog article about it.

Things to Do

  • Know your audience and tailor your talk accordingly
  • Be concise
  • Plan one or two goals for your audience and work to meet only those goals (in the education biz, they call these "learning outcomes")
  • Know where you're presenting and what your equipment will be
  • Share your passion
  • Practice your talk

Things to Avoid

  • Reading your slides word for word
  • Turning your back on the audience
  • Reading from a script
  • Giving a wall of math
  • Skipping around a lot
  • Overusing gimmicks

The most important thing by far is to practice your talk. Practice, practice, practice, practice.

+8  A: 

Even before having seen Guy Kawasaki's write, I was following an approximation of his 10/20/30 rule.

"Ten is the optimal number of slides in a PowerPoint presentation because a normal human being cannot comprehend more than ten concepts in a meeting"

"You should give your ten slides in twenty minutes. Sure, you have an hour time slot, but you’re using a Windows laptop, so it will take forty minutes to make it work with the projector."

"they think that more text is more convincing. Total bozosity. Force yourself to use no font smaller than thirty points. I guarantee it will make your presentations better because it requires you to find the most salient points and to know how to explain them well."

I like the 30. The other two numbers are horse manure as general advice.
Konrad Rudolph
I don't think they are. Keep it short (the 10 rule) and allow plenty of time for questions (the 20 rule). Both of those are completely overlooked by most people.
Bob Somers

Here's a question of my own.

I do a lot of sketching during many of my presentations. Nothing fancy, blocks, arrows, lines, circles, etc.

I'd like to do them live on the screen, or at least semi-live, on a screenshot.

The feature list I've set up is below. Does anyone know of any software, free or otherwise, that would help me in this regard for Windows? I know of ZoomIt, but it is very basic, and I have some specific features in mind that it doesn't do.

  • When activated, take a screenshot, effectively freezing the on-screen display
  • Let me draw on the screen
  • Can change colors and pen-width
  • Lines, arrows, circles, ellipses, rectangles
  • Possibly able to write text as well
  • Save the sketches to disk
  • If possible, recall older sketches. I imagine a flipbook-style, prev/next, etc.

Is there any such type of software out there?

Lasse V. Karlsen
+2  A: 

If you must use powerpoint, check out the many articles on how Steve Jobs uses keynote (ie, few words, just pictures to punctuate the message).

Failing that, follow Guy Kawasaki's 10-20-30 rule:

a PowerPoint presentation should have ten slides, last no more than twenty minutes, and contain no font smaller than thirty points.

Adam Davis
+1  A: 

In case of live coding:

  • Prepare
  • Have everything written down so you can copy-paste if you run into typos (especially when showing off your command line skill with sed or regexp etc...)
  • Check the keyboard layout on the demo machine. Finding [ { } ] # from German layout can be a little bit tricky after US layout.
Petteri Hietavirta

Here's a good public speaking book:

Used copies are about $2!

Mark Harrison
+2  A: 

Check out Scott Hanselman's 11 Tips for a Successful Technical Presentation. The man is a genius, and a magician when it comes to presentations (check out his ASP.NET MVC Preview presentation video from Mix `08).


I recommend these tips (from senior faculty at Berkeley's EECS dept.): ("Ten Commandments" at the end)


Use laser pointers sparingly, or not at all!

Never use them if people are connected by internet tools, they can't see what you are pointing at.

Never use the laser pointers to highlight words or sentences.

The only valid use OK with me is to point to a specific area of a diagram or picture.

I would be happy if people never used these devices while giving presentations.

-- Mike


For any presentation, I think that the best advices are:

  • Tell a story
  • Be passionate about it

For hints about how to build a good presentation, take a look at Presentation Zen blog.

+1  A: 

Scott Hanselman has a good blog post on this:

Kyle B.

Check out comedian Don McMillan on PowerPoint Abuse

Funny and informative.


One thing I haven't seen is specificity. Try to come up with at least one specific reason why this is worth pursuing; ideally, each member of your audience should come away with at least one specific good feeling about this. In an introduction to new technology for your team, you should know what sorts of things annoy your team, so show how the new tech handles at least one of those things a lot better.

This probably means not covering everything, but that's OK for an introduction. You want to give your audience incentive to learn more, and to pay attention because they don't want to miss another goodie.

David Thornley

manager tools have a good podcast on slide prep. i believe their golden rule is never have more than 3 points per slide (+ no graphs)

in terms of presentation delivery, be sure to use your loud voice and speak slowly

in terms of 'room rules' - dont allow any individual laptops (expect programmers to complain)

as far as the format of the meeting, i have written an article on tech briefing sessions, you may find something useful in it to augment your current format:


one more thing, crack jokes, even bad ones (as long as they are appropriate to the work place) - the best presenters i have seen are always supurb story tellers and have a good sense of humor