Technical leadership in design reviews

TL;DR

Design reviews exist to catch the 2-3 irreversible decisions in a design and make sure they're intentional. Everything else is commentary.
The reviewer's job is to open up the author's thinking, not to demonstrate their own expertise. Enabling questions beat gotcha questions every time.
Most design reviews fail the same way: 80% of the time goes to naming conventions and technology preferences while nobody notices the system assumes strong consistency from an eventually-consistent database.
Label every piece of feedback as a blocker, a suggestion, or a nit. Undifferentiated feedback is harder to act on and creates unnecessary anxiety for the author.
When to approve, when to block, and when to defer are three distinct decisions, each with different criteria and different signals to the author.
Cross-team reviews are the hardest type. Name the decision owner explicitly or nobody will decide anything.

What Goes Wrong in Design Reviews

Picture this: eight engineers in a conference room. Sixty minutes on the calendar. The team is designing a new order processing pipeline. Forty-five minutes in, they're still debating whether the service should be called order-processor or order-pipeline. Nobody has noticed that the design assumes exactly-once delivery from a message queue that provides at-least-once semantics. The review ends. Everyone feels productive. Three months later, the team is debugging duplicate charges in production.

Now picture the opposite. A staff engineer reads the design doc the night before. She writes three comments async. In the meeting, she asks one question: "What happens when the primary region fails and the secondary region hasn't finished replicating the last 30 seconds of orders?" The room goes quiet. The author realizes they have no answer. That single question saves the team from a data loss incident that would have taken weeks to untangle.

I've sat in hundreds of design reviews across four companies. The pattern is consistent. The reviews that produce value are the ones where someone prepared, asked hard questions about failure modes, and kept the room focused on decisions that actually matter. The reviews that waste time are the ones where nobody prepared, everyone has opinions about everything, and the hardest decisions never get discussed because time runs out.

The cost of a bad design review isn't just the wasted hour. It's the false confidence it creates. The team walks out thinking their design has been validated when it hasn't been examined at all.

The silent cost

A design review that approves everything because nobody prepared is worse than no review at all. It creates a false record that "the design was reviewed" when it wasn't truly scrutinized.

What Design Reviews Are Actually For

A design review is a risk identification process, not a gatekeeping mechanism. That distinction matters. The moment a review becomes about approval, the author optimizes for getting through the review instead of getting the design right.

There are four things a design review should accomplish:

1. Identify irreversible decisions and make them intentional.

Some decisions are easy to change later. Renaming a field, switching a logging library, adjusting a timeout. Those aren't worth review time. Other decisions lock you in: database choice for a high-write system, API contracts consumed by external partners, data models that will have millions of rows within months. A design review should spend 80% of its time on the decisions that are hardest to undo.

2. Surface cross-team dependencies the author missed.

The author of a design is almost always closer to their own team's context than to the broader organization's. I've seen designs that assumed an API would exist when the owning team had no plans to build it. I've seen schemas that duplicated data another team already maintained, creating a consistency nightmare. The reviewer's job is to bring the wider lens.

3. Document reasoning for future engineers.

Six months from now, someone will ask "why did we choose Kafka over SQS here?" If the design review captured the reasoning (ordering guarantees were critical, the team already had Kafka operational expertise), that question has an answer. If the review was a rubber stamp, the reasoning dies with the original team's memory.

4. Catch failure modes not considered.

Every design has a happy path. Good reviewers ask about the unhappy paths. What happens when the downstream service is down for 15 minutes? What happens when traffic spikes 10x during a promotional event? What happens when the database runs out of disk space? These questions aren't pessimism. They're engineering discipline.

What design reviews are NOT for

Design reviews are not code reviews, not performance benchmarking sessions, and not the place to debate technology preferences. "You should use Go instead of Java" is not a design review comment unless there's a specific technical requirement that Java cannot meet. Save style and implementation preferences for the code review phase.

The Reviewer's Mindset

The difference between a reviewer who improves designs and a reviewer who just adds friction comes down to mindset. Let me break down the three core shifts.

Enabling questions vs. gotcha questions

A gotcha question demonstrates the reviewer's knowledge. An enabling question opens up the author's thinking. They feel different in the room, and they produce completely different outcomes.

Gotcha question	Enabling question
"Why aren't you using gRPC?"	"I notice the latency target is 10ms for internal calls. Have you evaluated whether REST serialization overhead will fit within that budget?"
"This won't scale."	"The design targets 1,000 writes/sec. What's your plan if the product team's growth projections push that to 10,000 within a year?"
"You should use event sourcing here."	"I see you're storing only current state. If the business needs an audit trail later, how would you retrofit that? Is it worth considering upfront?"
"What about CAP theorem?"	"This design spans two regions. When a network partition happens between them, which side accepts writes and which side rejects them?"
"Have you thought about security?"	"The user ID comes from the client request. What prevents a user from passing someone else's ID to access their data?"
"That database choice is wrong."	"Help me understand the write pattern. MongoDB handles the schema flexibility well, but with the join-heavy queries in the reporting flow, have you considered how that performs at scale?"

The pattern: gotcha questions are closed (they imply the reviewer already knows the answer). Enabling questions are open (they genuinely explore the design space with the author).

I've watched senior engineers shut down entirely after a round of gotcha questions. The author stops sharing their reasoning and starts defending their choices. Once that happens, the review is no longer productive. The enabling question format, particularly the "I notice..." pattern, keeps the conversation collaborative.

The "I notice..." pattern:

Start observations with "I notice..." instead of "You should..." or "Why didn't you...". It frames feedback as shared exploration rather than criticism.

"I notice the retry logic doesn't have a backoff strategy. What happens if the downstream service is overloaded?"
"I notice there's no mention of how this handles partial failures in the batch processor."
"I notice the data flows through three services before reaching storage. Have you measured the cumulative latency?"

Blocker vs. suggestion vs. nit labeling

When you give 15 pieces of feedback with no severity labels, the author has to guess which ones you actually care about. That wastes their time and creates unnecessary stress.

Blocker: Must address before proceeding. The design has a correctness problem, is missing a critical dependency, or introduces a risk that could cause data loss, outages, or security vulnerabilities. Threshold: if this ships as-is, something bad will happen.

Suggestion: Would improve the design but author decides. A better approach exists, but the current approach will work. You'd do it differently, and you think the author should consider your alternative, but you won't hold up the project over it. Threshold: the design is safe either way.

Nit: Take or leave. Minor observations. Naming preferences, documentation gaps, small inconsistencies. Threshold: nobody will notice in six months.

When you're the most senior person in the room

Your suggestions carry more weight whether you intend it or not. When a staff engineer says "suggestion: consider using a circuit breaker here," many engineers hear it as a blocker. Be extra explicit. "This is genuinely a suggestion. The design works without it. I'd add it, but it's your call."

Collaborator, not approver

The author owns the design. They wrote it, they'll build it, and they'll maintain it at 2 AM when it breaks. The reviewer provides input. That's it.

This sounds simple, but the ego trap is real. It feels good to be the person who approves things. It feels good to demonstrate that you caught the thing nobody else caught. I've caught myself doing this, using a review to showcase my own knowledge instead of improving the design. The tell is when you find yourself giving feedback on topics the author didn't ask about, on aspects that are working fine, just to show you noticed.

When to override the "author decides" principle: genuine safety or correctness issues. If the design will lose customer data, introduce a security vulnerability, or violate a compliance requirement, you block regardless of the author's feelings. But "I would have designed it differently" is not a safety issue.

Preparing for a Design Review (as reviewer)

Most design reviews fail before the meeting starts because nobody prepared. Here's the preparation process I use for any non-trivial design (new service, schema migration, infrastructure change).

Step 1: Read the doc async before the meeting.

This is the single highest-leverage thing you can do, and most people don't do it. Reading a design doc takes 15-20 minutes. Reading it during the meeting takes 15-20 minutes of everyone's time. Write your initial comments directly on the doc so the author can see them before the meeting.

Step 2: Identify the 3 decisions you want to discuss.

Don't try to review everything equally. Find the 2-3 decisions that are hardest to reverse and focus your energy there. For most designs, these are: data model choices, service boundaries, and external API contracts.

Step 3: Check cross-team implications.

Does this service depend on anything owned by another team? Does it expose an API another team will consume? Are those teams aware? I once reviewed a design that assumed a specific rate limit on a partner team's API. The partner team had no idea this assumption existed. Catching that before implementation saved weeks of rework.

Step 4: Look for unstated assumptions.

Every design has assumptions the author didn't write down because they feel obvious. "Traffic will stay under 1,000 QPS." "The database will always be available." "Users will only call this endpoint once per session." Find those assumptions and make them explicit. If they're wrong, you've just saved the team from a production incident.

Step 5: Pre-write your blockers vs. suggestions.

Before the meeting, decide which of your concerns are blockers and which are suggestions. Writing this down forces you to think about severity honestly. Sometimes a concern that felt like a blocker in your head reveals itself as a preference once you try to articulate why it matters.

Reviewer preparation checklist:

Step	Question	Time
Read doc	Have I read the full design, not just the summary?	15-20 min
Key decisions	What are the 2-3 hardest-to-reverse decisions?	5 min
Cross-team	Which other teams are affected? Are they in the review?	5 min
Assumptions	What does the design assume that isn't explicitly stated?	5 min
Label feedback	Which concerns are blockers vs. suggestions vs. nits?	5 min

Running a Design Review Meeting

A design review meeting without structure devolves into free-form commentary. Here's the format I've seen work consistently across multiple organizations.

The 30-minute structure

Minutes 1-5: Author presents key decisions. Not a full walkthrough of the doc. Everyone should have read it already. The author highlights the 2-3 decisions they're least confident about and explains their reasoning. This focuses the room immediately.

Facilitation script: "We've all read the doc. [Author], walk us through the decisions you most want feedback on. We have 5 minutes for this."

Minutes 5-20: Reviewers ask questions. Structured discussion focused on failure modes, cross-team dependencies, and the reversibility of key decisions. The facilitator's job here is to keep the conversation on high-impact topics and redirect tangents.

Facilitation script (redirecting a tangent): "That's a fair point about naming, but let's table it and come back if we have time. I want to make sure we cover the data replication question before we run out of time."

Minutes 20-25: Identify blockers. The facilitator goes around the room and asks each reviewer: "Do you have any blockers?" Not suggestions, not nits. Blockers only. This forces everyone to commit to a severity level.

Facilitation script: "Let's identify blockers. A blocker means we shouldn't start building until this is resolved. [Reviewer], do you have any blockers on this design?"

Minutes 25-30: Capture action items. For each blocker, assign an owner and a timeline. "Who resolves this? By when?" If a blocker can be resolved in the meeting (clarifying a miscommunication, adding a missing section to the doc), resolve it on the spot.

Facilitation script: "We have three action items. [Author] will update the failover section by Friday. [Reviewer B] will confirm the rate limit with the payments team by Thursday. [Author] will schedule a follow-up if the capacity numbers change the approach."

Handling strong disagreements

When two engineers disagree on a technical approach and neither will budge:

Name the disagreement explicitly: "We have two positions. Position A is X. Position B is Y. Let's make sure we understand the tradeoffs of each."
Ask what information would change each person's mind. If neither can answer, the disagreement is about preference, not engineering.
If the disagreement is about preference, the author decides. If it's about correctness, escalate to someone with the data or authority to resolve it.

Protecting the author

I've seen design reviews turn into pile-ons where every reviewer adds more criticism and the author shrinks. The facilitator's job is to prevent this.

Facilitation script (preventing pile-on): "We've heard several concerns about the caching layer. [Author], do you want to take a minute to respond before we add more, or should we move to the next topic?"

The facilitator also ensures junior engineers presenting designs don't get steamrolled by senior reviewers. A junior engineer's design that works is better than a senior engineer's preferred design that the junior engineer can't build or maintain.

The Block/Approve/Defer Decision

Every design review ends with one of three decisions. Understanding when to use each, and what each communicates, is a core staff+ skill.

When to approve

The design addresses the stated requirements.
Key tradeoffs are documented with reasoning.
Failure modes are identified and mitigated (or accepted with justification).
Cross-team dependencies are acknowledged and owners are identified.

You don't need to love every choice. The author picked a message queue you wouldn't have picked? If it meets the requirements and the tradeoffs are documented, approve. "I would have done it differently" is not a blocker.

What approval communicates: "I trust that you've thought through this design and the remaining risks are acceptable."

When to block

Correctness issues. The design has a race condition, a data loss scenario, or a logical error that will cause incorrect behavior in production.
Missing critical dependencies. The design depends on another team's API, but that team hasn't been consulted. The design assumes a feature that doesn't exist yet in the infrastructure.
Reversing architectural decisions without alignment. The design introduces a new message queue when the organization standardized on Kafka last quarter, with no explanation for why the standard doesn't apply here.
Security or compliance gaps. PII flowing through an unencrypted channel. Auth checks missing on a public endpoint. Data retention that violates regulatory requirements.

What blocking communicates: "There's a risk here that needs to be resolved before we invest engineering time in building this."

When to defer

The design needs capacity numbers that haven't been gathered yet.
The approach depends on a partnership team's decision that hasn't been made.
The design is sound conceptually, but implementation details need more investigation.

Deferral means: approve the direction, but don't commit to specific implementation details until more information is available.

What deferral communicates: "The approach looks right, but we're uncertain about specifics. That uncertainty is acceptable for now."

The preference trap

Blocking for preference instead of risk is the single most common anti-pattern among new staff engineers. If the design will work, and your concern is "I'd do it differently," that's a suggestion, not a blocker. Save your blocks for genuine risks. Your credibility as a reviewer depends on it.

Cross-Team Design Reviews

Cross-team reviews are the hardest type because each team optimizes for their own goals. The payments team wants stability. The growth team wants speed. Neither is wrong, but their requirements conflict, and no single designer can resolve that tension alone.

Getting the right stakeholders

Too few stakeholders and you miss critical dependencies. Too many and the meeting becomes a committee that can't decide anything. I use a simple split:

Must attend (decision input): Teams whose APIs, data, or infrastructure are directly affected by the design. They need to agree to the contract.
FYI (async review): Teams who might be affected indirectly or have useful context. Share the doc, invite comments, but don't require their presence.

Naming the decision owner

In cross-team reviews, the default is that nobody makes a decision because everyone assumes someone else will. Fix this by explicitly naming the decision owner at the start of the meeting.

Facilitation script: "Just to be clear, [Author] owns this design decision. We're here to provide input, surface risks, and align on the API contract. The final call is [Author]'s unless we identify a blocker that requires escalation."

Handling conflicting team incentives

When Team A wants a synchronous API and Team B wants async events, don't pretend the conflict doesn't exist. Name it:

"Team A needs synchronous responses for their checkout flow. Team B can't guarantee sub-100ms responses. These are genuinely in tension. Options: Team A adds a cache, Team B improves their P99, or we design a hybrid where checkout uses a cached value and reconciles async."

The API contract pre-agreement technique

For cross-team designs, align on the API contract before the full design review. Schedule a 15-minute meeting with just the teams that share an interface. Agree on the contract shape, SLAs, and error handling. Then present the full design with that contract already settled. This prevents the full review from spending 40 minutes debating API shapes.

When to escalate vs. resolve technically

Escalate when:

Two teams have fundamentally different priorities and neither can compromise without violating their team's commitments.
A decision requires budget or headcount that neither team controls.
The disagreement has been going in circles for more than one meeting.

Resolve technically when:

Both positions are engineering tradeoffs, not organizational priorities.
A creative third option exists that both teams can accept.
One position is clearly wrong on the merits (rare, but it happens).

Anti-Patterns in Design Reviews

Six named anti-patterns I've seen repeatedly. Each one destroys the value a design review should provide.

1. The Architecture Court

What happens: Every design must be presented to a panel of 5-8 senior engineers for approval. The panel meets weekly. Designs queue up for weeks waiting for their slot.

Why it's harmful: It creates a bottleneck that slows every team. It centralizes architecture decisions in people who don't have the team's context. It trains engineers to optimize for pleasing the panel instead of building the right system. And it signals to the organization that engineers aren't trusted to make technical decisions.

What to do instead: Design reviews happen within the team, with relevant cross-team stakeholders invited as needed. Senior engineers participate in reviews for their area, not all reviews. Reserve the architecture panel (if you must have one) for truly cross-cutting decisions that affect multiple teams.

2. The Rubber Stamp

What happens: The review is on the calendar. Everyone shows up. Nobody has read the doc. The author walks through every slide. People nod. "Looks good." Meeting ends. Nothing was actually reviewed.

Why it's harmful: It creates a false record that the design was reviewed. When something goes wrong in production, the team points to "we had a design review" as evidence of due diligence. But no review happened. The failure modes, the cross-team dependencies, the unstated assumptions, none of those were examined.

What to do instead: Cancel the meeting if fewer than two reviewers have read the doc. Require async comments before the synchronous meeting. Make "no comments" visible (if you didn't comment, everyone knows you didn't prepare).

3. The Bike Shed

What happens: The review spends 45 minutes debating the service name, the error code format, and whether to use camelCase or snake_case. The hard decisions (data model, consistency guarantees, failover strategy) get 5 minutes at the end when everyone is mentally checked out.

Why it's harmful: Trivial decisions are easy to discuss because everyone has an opinion. Hard decisions are uncomfortable because they require admitting uncertainty. The review gravitates toward comfort instead of value.

What to do instead: The facilitator sets the agenda before the meeting: "We're discussing three topics: the replication strategy, the API contract with the payments team, and the capacity plan. Naming and formatting are out of scope for this meeting."

4. The Design-by-Committee

What happens: The review tries to reach consensus on every decision. If anyone disagrees, the discussion continues until everyone agrees (or gives up). Designs emerge as compromises that satisfy nobody.

Why it's harmful: Consensus-driven design produces the least objectionable option, not the best option. It takes forever. It dilutes accountability because nobody owns the final decision.

What to do instead: The author owns the design. Reviewers provide input. The author makes the final call. If a reviewer has a genuine blocker, that's a escalation, not a consensus problem.

5. The Late Review

What happens: The team starts building. Two weeks into implementation, someone schedules a design review. The implementation is 40% done. The review surfaces a fundamental problem with the data model.

Why it's harmful: Now the team faces a choice between reworking two weeks of code or living with a known design flaw. Neither option is good. The sunk cost fallacy kicks in: "We've already built this, let's just ship it." The design review becomes a formality that can't actually change the outcome.

What to do instead: Design reviews happen before implementation starts. No code should be written for a feature that requires a design review until the review is complete and blockers are resolved.

6. The Reviewer's Showcase

What happens: A senior reviewer uses the meeting to demonstrate their knowledge. They bring up tangentially related distributed systems papers, mention how Google solves this problem, and suggest three alternative approaches they've seen work at previous companies. The author's design gets lost in the reviewer's lecture.

Why it's harmful: The meeting stops being about the author's design and becomes about the reviewer's expertise. The author learns nothing about their own design's weaknesses. The room loses focus. Other reviewers disengage because the airtime is being consumed.

What to do instead: Keep feedback grounded in the specific design being reviewed. "How does Google do it" is interesting background, not actionable review feedback. If you have knowledge that's genuinely relevant, frame it as: "I've seen a similar approach fail because of X. Have you considered that risk here?"

Design Reviews for Your Career

Design review skills translate directly to staff+ interviews. Here's how.

Behavioral questions about influencing technical decisions

The classic: "Tell me about a time you influenced a technical decision you didn't own." This question evaluates whether you can drive outcomes through persuasion and evidence rather than authority.

Strong answer template:

Situation: "My team was consuming an API from Team X. Their proposed design had a pagination approach that would cause N+1 query problems at our scale."
Action: "I wrote up the specific performance impact with numbers, proposed two alternatives, and brought it to their design review. I framed it as 'here's what happens to our use case' rather than 'your design is wrong.'"
Result: "They adopted alternative B. It added a day of work for them but saved us from building a complex caching layer."
Reflection: "The key was bringing data, not opinions. And framing it as shared problem-solving instead of cross-team criticism."

Notice the structure: you identified a real risk, you prepared evidence, you communicated it as collaboration (not conflict), and you drove a concrete outcome. That's what staff-level influence looks like.

Architecture critique exercises

Some interviews include a "review this design" exercise where you're given a design doc and asked to provide feedback. The evaluation criteria map directly to design review skills:

Do you identify the highest-risk decisions (or do you comment on everything equally)?
Do you label your feedback by severity?
Do you ask enabling questions or make declarative statements?
Do you consider cross-team implications?

Handling conflicting requirements

"Two teams need different things from a shared service. How do you handle it?" This is a direct test of your cross-team design review skills. The strong answer walks through: naming the conflict explicitly, identifying what each team actually needs (vs. what they're asking for), finding a creative solution that serves both, and escalating to management only as a last resort.

How This Shows Up in Interviews

Interview question	What they're evaluating	Strong answer pattern
"Tell me about a time you influenced a technical decision."	Cross-team influence, persuasion through evidence	Describe the risk you identified, the data you brought, and how you framed it as collaboration. End with the outcome.
"How would you handle conflicting requirements between two teams?"	Conflict resolution, stakeholder management	Name the conflict explicitly. Identify each team's real need (often different from their stated position). Propose a solution that serves both. Escalate only if technically unresolvable.
"Describe a time you blocked a design. What happened?"	Judgment about when to block, communication under tension	Explain the specific risk (correctness, security, data loss). Show that you communicated it as a risk, not a preference. Describe the outcome and what the team did instead.
"How do you give technical feedback to someone more senior than you?"	Influence without authority, professional courage	Frame observations as questions. Lead with data. "I notice the design assumes X. Here's what happens if X doesn't hold." Focus on the design, not the person.
"A team ships a design you reviewed and approved. It fails in production. What do you do?"	Accountability, incident response, learning culture	Own your role in the failure ("I missed this in the review"). Focus on root cause, not blame. Propose changes to the review process that would catch this class of failure.
"How do you run an effective design review?"	Process leadership, facilitation skills	Describe your preparation process, the meeting structure, how you handle disagreements, and how you ensure actionable outcomes. Mention specific facilitation techniques.

Test Your Understanding

Quick Recap

Design reviews exist to identify the 2-3 irreversible decisions in a design and make sure they're intentional, not to approve every detail or demonstrate reviewer expertise.
Enabling questions ("I notice the latency target is 10ms; have you measured the serialization overhead?") open the conversation. Gotcha questions ("Why aren't you using gRPC?") shut it down.
Label every piece of feedback as blocker, suggestion, or nit. Undifferentiated feedback forces the author to guess what you actually care about.
Block for genuine risks (correctness bugs, missing dependencies, security gaps). Approve designs that will work, even if you'd have designed them differently.
In cross-team reviews, name the decision owner explicitly at the start. Reviews without a clear decision owner produce discussion but not decisions.
Prepare before the meeting: read the doc, identify the 3 hardest decisions, check cross-team implications, and label your feedback by severity.
The biggest career signal from design reviews: can you improve a design through questions and evidence, without needing authority over the author?

Staff engineer system design expectations: Covers the broader scope of staff-level design work, including when and why design reviews are triggered.
Senior vs. staff expectations: Understanding the level distinction helps you calibrate which design review behaviors read as senior vs. staff.
Principal engineer design leadership: At the principal level, design reviews shift from reviewing individual designs to setting the review process and culture for the organization.