Technical leadership in design reviews
How staff+ engineers run effective design reviews: preparation, the right feedback posture, unblocking cross-team dependencies, and knowing when to escalate vs. decide.
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.
Continue Reading with Premium
Unlock this article and every other in-depth system design guide on the platform with NotesFromSDE Premium.