Template

Technical design review template

Before building something large, the engineer who wrote the design walks others through it so problems are found on paper, not in production.

60 minutesFor The design's author, two or three senior engineers, and anyone who will run or depend on itAgenda room
Change the agenda first

The agenda, with a time for each part

  1. The problem and what limits us8 min
    • What exactly are we solving, and what can we not change?
  2. The proposed design15 min
    • How does a request travel through it, step by step?
  3. What else was considered10 min
    • What did you reject, and why?
  4. Questions and concerns17 min
    • What happens when this part fails?
    • What will this cost to run in a year?
  5. Decision and follow-ups10 min
    • Do we go ahead as written, with changes, or not yet?

How the notes read afterwards

A made-up example, so you can see the shape. In a real call each line carries the words that were said and who said them.

Problem. Reports take up to four minutes and time out for large customers.

Design. Build reports in the background and email a link when ready.

Rejected. A bigger database — it costs more each month and only moves the limit.

Decision. Go ahead, on condition there is a way to cancel a running report (Felix adds it to the design).

Running it well

Ways to change it

Written onlyFor smaller designs: comments in the document over three days, and a short call only if they disagree.
Across teamsInvite one person from each team the design touches, and give them the first questions.

When to skip it. For small changes that are easy to undo; code review is enough.

Questions

What is a technical design review?

A meeting where engineers examine a proposed design before it is built, to find problems, ask about failure cases and costs, and agree whether to go ahead.

What should a design document include?

The problem, the limits, the proposed design, the alternatives considered and why they were rejected, how it will be tested and run, and the open questions.

Who should attend a design review?

The author, a few experienced engineers, and people who will operate or depend on the system.

What happens in the room

Everybody joins from the link, with no account. The agenda sits beside the call and each item fills in with what was said about it, under the name of the person who said it.

More templates

Security reviewBefore something new goes live: what data it touches, how it could be attacked or misused, what protects it today, and what must be fixed before launch.On-call handoverThe fifteen minutes when one engineer hands the pager to the next: what broke, what is still open, and what to watch this week.Bug triageGo through the new bugs, decide how serious and how urgent each one is, give each an owner — and close the old ones nobody will ever fix.Product discovery reviewThe team shows what it learned from customers this cycle — interviews, tests, numbers — and decides which ideas are worth building, which need more evidence, and which to drop.Design critiqueA designer shows work in progress and the group says, against the goal, what works and what does not — so the design gets better before anyone builds it.Feature kickoffBefore work starts on a feature: everyone who will build, test, launch and support it hears why it matters, what done looks like, and what is deliberately left out.Launch planning meetingA few weeks before a launch: who hears about it, in what order, through which channels, what each team must have ready, and the one date everyone works back from.Beta feedback sessionA conversation with a customer using something before it is finished: what they used it for, where they got stuck, what they would miss if it went away.

All 162 templates →

Try Meetful

Meetings that take their own notes

Free video meetings in the browser: every line of the transcript under the name of who said it, and the summary and action items when you hang up. Nothing to install — guests just open the link.

Try Meetful freeSee what it does