Short technical presentations

Why it matters

Technical people present more often than they expect. Stand-ups, sprint demos, lab meetings, design reviews, safety briefings and client calls are all short presentations. Most of them last a few minutes, not an hour. Doing them well gets your work noticed, gets decisions made and builds trust. Doing them badly wastes everyone's time, even when the work behind them is excellent.

You do not need to be a natural performer. A short technical update is a skill with a clear structure, and it improves quickly with practice.

The core idea: one message, three parts

Before you open any slide software, finish this sentence: "When I finish, I want my audience to know ______ and to ______." If you cannot finish it in one breath, your talk is not ready yet.

Then build a three-part talk around that message:

1. Start with the point (about 30 seconds). What is this update about, and what is the headline? "The new sensor firmware cut false alarms by 60%, and I'd like approval to roll it out to all lines."
2. Give the evidence (about 2 minutes). Two or three supporting points, no more. What you did, what you found and what it means. One visual that shows the key result.
3. Close with the ask or next step (about 30 seconds). Repeat the headline and say what you need: a decision, feedback, help or nothing ("no action needed, just keeping you informed").

This structure is sometimes summarized as "tell them what you'll tell them, tell them, tell them what you told them". In a short update, the repetition helps people who drifted off for a moment.

Worked example: a 3-minute update

Here is a script outline for a junior data analyst presenting at a weekly team meeting.

OPENING (30 s)
"I looked into why support tickets rose in September. Short answer:
most of the increase came from one confusing screen in the new
billing page. I'd like us to prioritise a fix."

EVIDENCE (2 min)
1. Tickets went from about 420 in August to 610 in September (+45%).
2. 150 of the 190 extra tickets mention "invoice" or "billing date".
3. They started the day the new billing page shipped (Sept 3).
   [ONE VISUAL: weekly ticket count, with the release date marked]

CLOSE (30 s)
"So roughly 80% of the increase traces to the billing page. The ask:
can design and front-end look at that screen this sprint? I'll share
the ticket list after this meeting."

Notice that the numbers are rounded and easy to hear. Listeners cannot reread a sentence, so "about 420" works better than "421.7 on average".

One good visual

For a short update, one clear visual usually beats ten slides. Make it easy to read from the back of the room or on a small video-call window:

• One idea per visual. A single chart, diagram or photo.
• A title that states the finding, not the topic. "False alarms fell 60% after the firmware update" is better than "False alarm data".
• Large text (if people have to squint, it is too small) and only a few words.
• Label axes and units. Highlight the one bar or line that matters, and grey out the rest.
• No dense tables or code walls. If people need the detail, share it afterwards.

Delivery basics

• Practise out loud at least twice, timing yourself. Most people run long the first time.
• Speak a little slower than feels natural, and pause after key numbers.
• Look at people (or at the camera on a video call), not at your slides.
• Have notes, not a script. A few keywords per section are enough. Reading word for word sounds flat.
• Handle questions calmly. Repeat or rephrase the question so everyone hears it. If you do not know the answer, say so: "I don't know yet. I'll check and send it to you today." That builds more trust than guessing.

Nerves are normal. Preparation is the best cure: knowing your first 30 seconds by heart gets you past the hardest part.

Common mistakes

• Starting with background instead of the point, so people are lost before the headline.
• Too many slides and too many numbers for the time available.
• Reading the slides aloud with your back to the audience.
• Jargon your audience does not share. A design review with managers needs different words than one with engineers.
• No clear ask, so the meeting moves on and nothing happens.
• Going over time. Running short is never a problem; running long always is.

Quick recap

• Decide your one message and your ask before you build anything.
• Point first (30 s), evidence (2 min), close with the ask (30 s).
• One visual with a title that states the finding.
• Practise out loud, time it, and answer questions honestly.

Try it

Open the Do tab. You will plan, rehearse and record a 3-minute update with one visual.