Design reviews are where critical engineering decisions get made — or where good ideas get killed by bikeshedding. The format separates effective teams from frustrating ones. EMs who run design reviews well multiply their team’s effectiveness; those who do not turn the meeting into theater.
What a design review is for
To help an author improve a design before implementation. Specifically:
- Catch architectural problems early
- Surface alternatives the author had not considered
- Ensure cross-team concerns are addressed
- Build shared understanding among reviewers
What it is not for
- Status updates
- Code review (that happens in PRs)
- Stakeholder management (separate forum)
- Performance evaluation
The structure
Standard format (60 minutes):
- Pre-read: doc circulated 24–48 hours in advance
- Silent reading: 5–10 minutes at the start to ensure everyone has read
- Discussion: 30–40 minutes
- Action items and decision: 5–10 minutes
The pre-read
The author writes a design doc:
- Problem statement
- Constraints and requirements
- Proposed approach
- Alternatives considered
- Open questions
Length: 5–15 pages typically. The pre-read is the work; the meeting is the polish.
Reviewers
Invite:
- Senior engineers and architects in the relevant domain
- Engineers from teams with cross-cutting concerns
- The EM (you)
- Author’s manager (often you, sometimes peer)
Don’t invite:
- Random observers
- Junior engineers who are not in the loop (they should attend selectively for learning, but not as decision-makers)
- Stakeholders who do not have technical context
Cap attendance at 8–10 for productive discussion.
What strong reviewers do
- Ask about assumptions, not implementations
- Suggest alternatives with reasoning
- Identify cross-cutting concerns
- Distinguish must-fix from nice-to-have
- Focus on the design, not the doc’s prose
What weak reviewers do
- Bikeshed (color of the button arguments)
- Showcase their own knowledge without contributing
- Critique without proposing
- Demand re-design without time investment
- Veto without alternatives
The author’s role
- Listen before defending
- Acknowledge feedback even if disagreeing
- Capture action items in the doc
- Defend choices when warranted, but with humility
Decisions out of the meeting
Three outcomes:
- Approved: proceed
- Approved with conditions: implement, address X/Y/Z
- Send back: re-design and re-review
Document the outcome in the doc. Future engineers find it.
The EM’s role in design review
- Set the agenda and ground rules
- Time-box the discussion
- Surface concerns the team is not raising (you have context they may not)
- Make the decision if there is no consensus
- Protect the author from unfair criticism
Common dysfunctions
- Bikeshedding: argument over irrelevant details. Cut it off.
- Veto without alternative: “I do not like X” without proposing Y. Push for the alternative.
- Late feedback: reviewer raises critical concerns at the end. Ask reviewers to read in advance.
- Delegation by review: reviewers expect the author to address every comment. Some are FYI; some are blocking.
Async design reviews
For documents that do not need a live meeting:
- Doc shared with reviewers
- 5-day comment period
- Author resolves threads as addressed
- Decision recorded
This pattern works well for moderate-stakes designs and distributed teams.
Frequently Asked Questions
How often should design reviews happen?
Every meaningful project. Define “meaningful” — typically anything >1 week of effort or affecting multiple teams.
What if reviewers conflict?
EM facilitates. Sometimes the EM has to make a call. Document the disagreement; revisit if new info emerges.
How do I prevent design review from slowing the team down?
Cap meeting time. Use async review for non-critical designs. Build a culture where most reviews approve quickly because the doc is good.