Start by deciding the purpose of your talk. In general, a technical talk has one of two purposes: to convey information, or to persuade people to take some action. Usually the second type of talk also must convey information, since technical decisions are normally based at least in part on facts. The purpose of an after-dinner talk at a programmerís association meeting might be to persuade the audience that it is important to think about the efficiency of the algorithms they design, and to show them some elementary techniques they can use to analyze their algorithms. The purpose of a talk at a business meeting might be to persuade management to fund a project or to purchase a piece of software. A talk at a professional conference is usually intended to report research results. You might be explaining an algorithm you developed or trying to persuade people to use a programming language you designed. Formulating a specific purpose helps a great deal in planning a good talk.

The amount and type of information you can convey in your talk depends in part on the nature of your audience. The most common mistake of inexperienced speakers is to give a talk for an audience that knows as much as they do about the subject. You must assume that nobody in the audience is as familiar with your subject as you are, and that most of them know far less about it than you do. Even experts in your field may not have given much thought recently to the particular aspect of it you are talking about.

If your audience is quite heterogeneous, the problem is more difficult. One approach is to pitch the talk to the lowest common denominator. This is usually a bad strategy, since you will bore the people you are trying to impress. It is always best to begin slowly, giving motivation and background material and relating your topic to subjects the audience is familiar with. This gives people a chance to get into a frame of mind that will allow them to follow the rest of your talk. Gradually increase the technical level of your talk until you have reached the point where you can convey the desired information. If you proceed in this way, it is acceptable to direct part of your talk to the experts, although normally this should be no more than a third to a fourth of the total. Everyone in the audience should come away with a firm idea of what your topic was and why it was important.

The second factor is the limited capacity people have for absorbing new information. You can expect a scientific audience to be able to assimilate technical information at a faster rate than business managers, but no audience has an unlimited capacity. Psychologists tell us that people can retain about seven items in short-term memory. The worst kind of technical talk starts with 15 slides crowded with definitions, each one dependent on all the previous ones, which the speaker simply reads to the audience. Everyone who is not already intimately familiar with the subject (probably everyone except the speaker) is lost by the middle of the first slide. The interesting results are on the last slide, in the form of a theorem that cannot be understood unless one has mastered all the definitions. Limit yourself to only a few definitions that are new to the audience. (It is helpful to review basic concepts you will use.) If possible, each definition should be illustrated by an example. It is most helpful if you have a running example that is used to illustrate all the concepts and also your results. That way the people who cannot follow all the technical details will still have a good idea of what you were talking about.

The presentation must be designed for the audience. At the research laboratory of a well-known company, a group of scientists were working on sophisticated parallel processing algorithms. They found the algorithms fascinating, and they wanted to share their enthusiasm with the managers. They decided to try to explain their work to the managers by showing how to use the algorithms to rig up a fancy alarm clock. They knew the managers would be able to understand the problem the alarm clock was designed to solve, and they hoped the managers would get some feeling for the kind of work that was going on. The scientists succeeded admirably in giving an explanation that a relative layman could follow. Unfortunately, the result of their talk was that the managers started asking why they were spending so much money on research into alarm clocks! The project had a lot of trouble getting money afterwards. The alarm clock example would have been an excellent choice for a talk with a different purpose. The managers wanted to know why they should support the project, not how the algorithms worked.

With your basic purpose and the nature of your audience in mind, decide what specific topics you will cover, and in what order. Design the introduction carefully.

Actually listening to a technical talk is hard work. To get and keep peopleís attention, you have to persuade them that your talk is worth following. Explain what you will be talking about and why it is important. Relate it to the rest of the field. Try to find an example or an intuitive description that will get people interested. Once you have their attention, donít abuse it. Do not crowd too much into the body of your talk. If you are describing your Ph.D. thesis, the temptation to present every result is very strong. Normally, this is a bad idea. Pick out your best results and fit them into a logical narrative. If you can find a way to mention the rest, fine, but it is better to communicate only part of your material (the most important part) than to overwhelm people to the point where they tune you out.

Be careful with humor. Everyone has heard wonderful speakers who made masterful use of humor to make their talks interesting and lively. But for most speakers, humor is a risky proposition. One personís funny joke is another personís insult, exhibition of poor taste, or inane remark. If you decide to use humor, keep it low key. Above all, avoid humor that has any chance of being offensive. A good use of humor is often seen in talks about database algorithms, where people make up clever entries for the example database.

After you have made a rough choice of topics, prepare a detailed outline. Review each item in the outline in terms of your purpose. Consider whether a typical member of your audience will be able to keep up with you. Be sure the progression of ideas is logical; provide motivation for jumps in topic. If you have a long development leading up to an important result, be sure the audience knows where you are going. When your outline is complete, make a quick mental estimate to be sure that the amount of material you have is about right for the length of your talk.

Working from your detailed outline, plan the topics for your slides. Keep in mind the ``seven item ruleíí: you should not have more than about seven lines of text on a normal slide. Have at least one slide for each major point in your talk. The most common mistakes with slides are putting too much on one slide and the related error of making the writing on the slide too small. A good size for the print on an overhead projector slide is 1/2 inch. Do not try to put the whole talk on the slides. The audience will be gazing at your slide part of the time while you are talking. You do not want the slide to have so much on it that it takes a long time to read, thereby distracting people from listening. It is better to summarize, in outline form, the point you will be making verbally. That way the slide reinforces the speech. Do not be afraid to use a lot of slides. One per minute is fine; more may be needed. Vary the format of your slides. Itís boring to see slide after slide with a heading and a list of points.

An alternative to changing slides is to use overlays on top of your original slide. These are often quite effective, especially to illustrate the changes in a data structure as an algorithm is carried out, and similar processes. On the other hand, do not adopt the common practice of covering part of the slide with a piece of paper and gradually uncovering it as you speak. Many people (myself included) find this annoying. Use more slides, or put a second slide on top of the first one, instead.

Color can help make slides attractive and interesting. One good technique is to give the main points in one (dark) color and subordinate points in a lighter color. It also helps to use color to highlight important words or formulas. Do not use color gratuitously, though; a purple slide with yellow letters will distract people from the subject matter. When the slides are ready, check that light colors can be seen easily.

Make sure the writing on your slides is neat and horizontal. Do not make the slides too ``busyíí; a simple slide is usually most effective. Try to think of uses for diagrams. If you are describing a system configuration, a slide with little pictures of the components with a descriptive label on each one is usually a great deal better than a list of items. A graph is usually superior to a table. A picture of a data structure is worth a thousand words. But do not use art gratuitously; slides with flowery borders look unprofessional.

Do not use unreadable slides. It is amazing how many people break this obvious rule. Normally, typewritten material (including computer output) makes a slide that is at best barely legible. The temptation to use such material is almost overwhelming, because the slides are so easy to produce. I can remember many talks where the speaker pointed to a slide full of tiny, unreadable printout and said, ``You probably canít read this, but...íí or where a speaker flashed a slide made from a listing on the screen, saying ``Here is what our code looks like.íí Avoid using such slides. If it is worth having a slide, it is worth taking the trouble to produce a decent one.

One of your topics may be an algorithm you have to explain. Except in unusual circumstances, it is a mistake to put the actual code on a slide (or worse, two or three slides). Give a high-level description of the algorithm and then illustrate it on an example. If the algorithm is very complex, it may help to explain a simpler related algorithm first.

If you are describing a software package with a lot of features, donít spend five minutes on each feature, like a talking manual. Instead, illustrate an interesting task that the package can perform, using a few of the most important features. Just mention the other features.

When the slides are finished, prepare notes to go with each one, to remind yourself of what you plan to say when that slide is on the screen. I like to put my notes on the pieces of paper I use to separate the slides. That way I can glance at them inconspicuously while I am changing the slide.

When the slides and notes are ready, practice your talk. Time yourself and make any necessary adjustments. You do not need to memorize your talk, but practice enough to avoid nervousness. When you like the talk, practice on a friend. Ask your friend to watch for distracting mannerisms, unclear explanations, illegible slides, and boring parts of the talk. Have your friend ask you questions.

Now you are ready for the talk. Bring some blank slides with you, along with some of the special pens that write on slides. That way you will be prepared if someone asks a question and you want to illustrate your answer. Make sure you have your slides in a safe place. (Some ink runs if it gets wet, or rubs off, so be careful with them.) If possible, get a look at the room set-up in advance and make sure the equipment is right. If there is a microphone, figure out how to put it on.

When you speak, face the audience and look at them. Be sure you donít stand in front of the light from the projector (at least 5% of all speakers do this). Point to the screen rather than the projector when you want to direct peopleís attention to one part of the slide.

Speak loudly and clearly. If the sound system starts to whine, cover the microphone briefly with your hand. You may have been holding the microphone too close to your mouth. Try to be as relaxed and natural as possibleóthis is where practice really pays off. Have fun!