Running Design Reviews That Help

Scenario

Example organisation: a weekly "architecture review board" approves designs for 40 engineers. Authors prepare slides for a week; the board asks questions about technologies it prefers; approval takes 2–3 cycles. Teams start skipping it and building first.

What you see on the team

• Designs presented after code is already written ("for awareness").
• Review meetings dominated by one or two senior voices.
• Feedback that is opinion ("I'd use Kafka") rather than risk ("what happens when the consumer falls behind?").
• Authors who leave reviews deflated, and junior engineers who never present.

The common mistake

Running design review as a gate where seniors approve or reject, instead of as a forum where the author gets the best possible feedback on risks and trade-offs.

Why it happens

Review boards are often created after an incident, to "prevent bad designs". Over time, approval becomes the goal, reviewers optimise for their preferences, and authors optimise for passing. The doc-first approach in Design Docs at Google works because comments happen asynchronously on a written argument — the meeting, if any, resolves what writing couldn't.

The playbook

Before the meeting

• The doc is circulated at least two days ahead; reviewers comment in the doc.
• The author lists the decisions they want help with.

In the meeting (30–45 minutes)

• The author owns the decision; reviewers advise. Say this at the start.
• Walk through open comments and the author's questions, not the whole doc.
• Review against a checklist, not taste:

- Failure modes: what happens when each dependency is slow or down?
- Data: ownership, consistency, migration and backfill, retention
- Security and privacy: authn/authz, PII, secrets, audit
- Operability: metrics, alerts, runbook, on-call impact
- Rollout: feature flag, canary, rollback, data-migration reversibility
- Cost and capacity: rough numbers for the next 12 months
- Alternatives: were simpler options considered?

After

• The author records decisions and open items in the doc; significant ones become ADRs.
• Unresolved disagreements are written down with an owner and a date.

Rotate presenters — every engineer presents at least once a quarter; seniors review in pairs with juniors.

What to say

Opening the review:

"Ana owns this design. Our job is to find risks she hasn't covered and suggest options — she decides. Let's start with her three questions, then go through the checklist."

Turning an opinion into a risk:

"When you say you'd use Kafka here — what problem with the current queue are you worried about? Let's write that risk down and let Ana decide how to address it."

Trade-offs

• No gate at all can let risky designs through; keep a mandatory review only for high-risk categories (money, security, data migrations, cross-team APIs).
• Async-only reviews are efficient but miss nuance; meet when there are unresolved disagreements.
• Checklists can become box-ticking; use them as prompts, not scores.

Signals it's working

• Designs arrive before code, with specific questions.
• Comments are about failure modes and trade-offs, not technology preference.
• More engineers present each quarter, including juniors.
• Fewer production incidents trace back to design gaps that a review should have caught.

Key points

• The author owns the decision; reviewers find risks and suggest options.
• Comment asynchronously on a written doc; meet to resolve what writing couldn't.
• Review against a risk checklist (failure modes, data, security, operability, rollout, cost).
• Record decisions and disagreements; rotate presenters to grow the team.