Speaking is not reading aloud
A written document can be reread; a talk cannot. The audience hears each sentence once, at your pace, while also looking at your slides. That changes how you should organise content. Repetition that would feel padded on paper helps in a talk, and detail that works in a table can overwhelm a room.
This article focuses on spoken delivery. For the written equivalent, see the guidance on technical reports; here the concern is what happens in the room or on the call.
Plan around one message
Before building slides, write down in one or two sentences what you want the audience to understand or decide by the end. Everything in the talk should serve that. If a slide does not, consider cutting it or moving it to a backup section you can show if asked.
Know the audience and time limit. A review with the project team can assume shared context; a talk for a mixed group of managers, other disciplines and customers cannot. If people from several backgrounds will be present, define key terms briefly the first time you use them and avoid acronyms that only your team knows.
A common structure that works for many talks is:
- the problem or question, and why it matters to this audience
- the approach, kept short
- the main results or findings
- what you recommend or what happens next
Open with the point of the talk rather than a long history of the project. People listen better when they know where you are heading.
Slide design that supports the speaker
Slides are visual aids, not a script. If the audience can read your whole talk off the screen, they will do that instead of listening.
- One idea per slide. A title that states the takeaway, such as “Vibration rises after the second bearing change”, is more useful than a topic label.
- Limit text. Short phrases and a single supporting image or chart are usually enough.
- Use readable sizes. Text should be legible from the back of the room. If you need to apologise for small print, the slide has too much on it.
- Keep a consistent layout. Matching fonts, colours and positions let the audience focus on content.
- Do not rely on colour alone. Some viewers cannot distinguish certain colour pairs, and projectors can wash colours out. Use labels, line styles or markers as well.
Avoid decorative animation. A simple build that reveals items as you discuss them can help, but effects for their own sake distract.
Explaining data live
Charts that work in a report can fail on a screen if you do not guide the audience through them. A reliable sequence is:
- Say what the chart shows: “This is temperature against time for the test run.”
- Explain the axes, including units.
- Point to what matters: “Notice the step at around ten minutes.”
- State what it means: “That is when the fan switched on.”
Do this in order, because audiences cannot interpret a graph and listen to the conclusion at the same time. Use a pointer or highlight so people know where to look. Simplify charts for presentation: remove gridlines and series that do not support your point, and enlarge labels. Choices about how to display information are covered under data visualization.
Be honest about uncertainty. If a result comes from few measurements or a rough estimate, say so. Giving a number with a note about how firm it is builds more trust than false precision. When you show a calculated figure, be ready to explain where it came from, since someone is likely to ask.
Pacing and delivery
Nervous speakers tend to rush. Slow down more than feels natural, and pause after important points and before changing topics. A short silence gives people time to absorb what you said.
Practise out loud, ideally with a timer and at least once in front of a colleague. Rehearsal shows where explanations are clumsy and where a slide has too much on it. A common planning guide is to allow roughly one to two minutes per content slide, but it depends on the slide, so test your own talk rather than relying on a rule.
Some practical habits:
- Face the audience, not the screen.
- Do not read slides verbatim; say something the slide does not.
- Keep notes brief, such as key phrases and transitions, rather than a full script.
- Give a short roadmap at the start and a summary of the main point at the end.
- Leave time for questions, and plan to finish slightly early rather than late.
For remote presentations, check your audio, share only the window you need, and ask for responses more actively, since you cannot see faces as easily. Familiarity with your remote engineering tools helps avoid fumbling during the talk.
Handling questions
Questions are often where mixed audiences show what they actually understood. Prepare for them by listing the five questions you least want to be asked and thinking through answers.
When a question comes:
- Listen to the end without interrupting.
- Repeat or rephrase it, so everyone hears it and you confirm you understood.
- Answer the question asked, briefly, and check whether it helped.
- If you do not know, say so, and offer to find out and follow up. Guessing in front of an audience is riskier than admitting a gap.
- For a hostile or off-topic question, acknowledge the concern and offer to discuss it afterwards.
Backup slides with detail, such as extra data or assumptions, are useful for questions you can anticipate. Treat challenges to your design or results as input rather than attack; much of the same mindset applies in design reviews.
After the talk
Share slides or a short written summary if the audience needs reference material, and note actions or decisions agreed. If feedback is offered, ask one or two people what was unclear. That information improves the next presentation more than self-critique alone.
Conventions differ between organisations and fields, so check whether a template, time limit or format is required before you start.