Technical Presentation

What it is

A technical presentation puts work or a decision in front of a room so that they can follow it and decide. It is not a tour of everything that was done; it is the shortest path from the audience’s context to the decision you want from them.

Why it matters

Presentations go wrong in two predictable ways. The first is the chronology — what we tried, what we found, what we tried next — which leaves the room forming an opinion before they know what they are being asked. The second is the depth that interests the presenter and exceeds what the audience can evaluate, so the discussion drifts to a detail and the decision does not happen. Both are fixed by deciding the decision first and building the slides backwards from it.

Core ideas

Name the decision before the first slide

One sentence at the top: what you want the room to decide or approve. If you cannot write it, the presentation is an update and should be an email.

Decision wanted: approve the schema change and a two-week migration
window, accepting a read-only period of about 20 minutes.

Five slides, in this order

Context, the options, the evidence, the recommendation, the ask. Anything else goes in an appendix you can be dragged into.

1 Context        what problem, whose, what it costs    (1 slide)
2 Options        two or three, with their real costs    (1 slide)
3 Evidence       the measurement or test behind them    (1-2 slides)
4 Recommendation what you propose and why
5 The ask        the decision, the cost, the date

One idea per slide, as a sentence in the title

The title states the finding; the body supports it. “Latency doubled after the queue change” is a slide; “Performance” is a chapter heading.

Show the artefact, not the process

The room needs to see the thing and its consequences, not the four weeks of exploration. Keep one slide of alternatives considered for the question someone will ask.

Rehearse the first ninety seconds out loud

That is where the room decides whether to listen. Say the decision, the recommendation and the ask in that order before anything else.

Practice

Build the five-slide outline for a real decision

Take a decision you need from a real audience and build the five slides, with the decision written above slide one.

Done when each slide title is a sentence stating a finding, and someone reading only the titles can follow the argument.

Present it and record the questions

Deliver the outline to a colleague, and write down every question they ask.

Done when: each question has either been answered in a slide or listed as material for the actual appendix.

Common mistakes

  • Chronological structure — the audience forms a position before hearing the ask; fix: start with the decision and the recommendation.
  • No stated ask — the meeting ends without anything decided; fix: name the decision, the cost and the date at the top and the end.
  • Topic titles instead of findings — the slides describe areas, not conclusions; fix: write each title as the sentence the slide proves.
  • Showing the exploration — the audience cannot evaluate the work and drifts to detail; fix: keep the process in an appendix.
  • Not rehearsing the opening — the first minute is rambling and attention is lost; fix: say the first ninety seconds out loud beforehand.

Go deeper