# Running Effective Design Reviews

Source: https://www.techinterview.org/post/3233475150/running-effective-design-reviews/
Updated: 2026-06-30 · techinterview.org

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.