Architecture Reviews That Don't Waste Senior Time
TL;DR — Most architecture reviews are theatre. The prep is rushed, the discussion is unfocused, and the outcome is “go back and think more.” A useful review starts with a real document, runs forty-five minutes, and produces one of four explicit decisions. Anything else is wasted senior engineer hours.
Every company above about a hundred engineers has some flavor of architecture review. The names vary (architecture review board, design review, RFC discussion, tech council) but the structure is similar. A team proposes something. A panel of senior engineers reviews it. Everyone leaves slightly tired and not entirely sure what just happened.
I’ve been on both sides of this process at three companies, and I’ve watched it work well and badly. The difference between a good and bad review process is not the calibre of the reviewers. It’s the structure around them. Smart people will give you mediocre reviews if you set them up to. The same smart people will give you sharp reviews if the process is designed well.
This post is about the structural choices that make architecture reviews actually useful. The prep document standards. The meeting format. The decision categories. The rules that keep the process honest over time. Most of what I’ll describe takes about three months to roll out and produces immediate, measurable improvements in decision quality.
What a review is for
An architecture review exists to do one of four things. Not more, not less.
- Catch risk the proposing team missed.
- Surface a constraint from elsewhere in the org that the team didn’t know about.
- Make explicit a trade-off the team made implicitly.
- Either bless or block a decision that crosses team boundaries.
That’s it. If your review is doing teaching, mentoring, coordination, or status reporting, you’ve miscast it. Those are valuable activities but they belong in different forums. The review’s job is to produce a decision faster and with less risk than the team could do alone.
If your reviews don’t reliably produce decisions, the rest of this post is for you.
The prep document is the entire battle
The single biggest determinant of review quality is the document the team brings. If the document is good, the review is short and useful. If the document is bad, no amount of meeting time will save it.
What “good” means here is specific. A good prep document:
- Can be read in fifteen minutes by someone outside the team.
- Takes a clear position rather than presenting options without a recommendation.
- Names the riskiest assumption explicitly.
- Includes a “what would change this decision” section.
- Has been reviewed inside the team before going to the review board.
The template I use:
# Design Review, <project name>
**Author:** <name>
**Date:** <date>
**Team:** <team>
**Status:** Pre-review / Under review / Approved / Approved with conditions / Rejected
## TL;DR
Three sentences. What we're proposing, why, what we're asking the
review board to decide.
## Context
What problem are we solving? What constraints are we operating under?
One page max. No background that a reviewer should already know.
## Proposed approach
What we're going to build. Diagrams welcome. Be specific.
## Why this approach
The case for, in three to five concrete reasons. Each with evidence.
## What we considered and rejected
At least two real alternatives, each with a specific reason for rejection.
Not "less scalable." Specific.
## Riskiest assumption
The single thing that, if wrong, would invalidate this design.
What would we see in production that would tell us we got it wrong?
## What we're asking the review board to decide
A specific question. Not "thoughts?" A real ask.
## What this looks like in six months if we ship it
One paragraph. Concrete. Helps reviewers calibrate the bar.
## Open questions
The things we deliberately deferred.
Notice what’s not in here. There’s no “executive summary” separate from the TL;DR. There’s no “background” section that recaps the obvious. There’s no “we considered ten options” because nobody considered ten options seriously. The document is honest about what the team did and didn’t do.
Teams that submit documents matching this template get faster, better reviews. Teams that submit eight-page documents get tabled. Make the bar explicit.
The meeting format that works
I run architecture reviews at forty-five minutes. Not an hour. Forty-five minutes forces discipline. The structure:
| Time | Activity |
|---|---|
| 0-10 min | Silent reading of the doc (or the last update if it was sent in advance) |
| 10-20 min | Author presents the riskiest assumption and the alternatives considered. No general overview. |
| 20-40 min | Reviewer questions, structured by risk category |
| 40-45 min | Explicit decision and action items |
The silent reading at the start is non-negotiable. It guarantees reviewers actually read the doc. If you can’t run a meeting where six senior engineers sit in silence for ten minutes, you have a culture problem, not a review problem.
The author presenting only the riskiest assumption is the other key move. It signals what the conversation should be about. The default mode for engineers is to present everything they built, which wastes the room’s time. Make them lead with the thing they’re least sure about.
Structuring questions by risk category
Free-form Q&A produces meandering reviews. I use a checklist of risk categories that reviewers cover in order:
- Reversibility. What’s hard to undo if this goes wrong?
- Operational burden. Who’s on call for this in two years? Have they reviewed?
- Failure modes. What happens when an upstream dependency goes down? When this system is overloaded?
- Security and data. Who can access what? What’s the blast radius of a credential leak?
- Cost. Both dollar cost and engineering time. Has it been compared to alternatives?
- Coupling. What other teams will be affected? Have they been consulted?
Reviewers don’t have to ask about every category. But the categories give shape to the conversation, and they catch the “I forgot to ask about ops” moments that produce six-month-late surprises.
The four decision categories
At the end of every review, exactly one of four things happens. State it explicitly. Write it in the doc.
Approved. The team can proceed. The doc becomes the source of truth. Reviewers commit to not relitigating it later.
Approved with conditions. The team can proceed, but X, Y, and Z must be addressed before code ships. The conditions are specific and have owners.
Send back for more work. The proposal isn’t ready. The team gets specific feedback on what to address and comes back. There’s a date by which they’ll return.
Rejected. The proposal doesn’t proceed. Reasons are written down. The team is not asked to “reframe and resubmit” in two weeks. If the answer is no, the answer is no.
The fourth category is the one most boards refuse to use. Rejections feel mean. So instead, boards say “send back for more work” indefinitely, and the team dies a death of a thousand revisions. Cleaner to say no clearly.
Who should be in the room
Six is the right number. More than eight and you’ve lost the ability to have a real conversation. The composition I aim for:
- Two senior engineers from teams that interact with the proposing team
- One operations or platform engineer
- One security or compliance person if data is involved
- One engineer who’s worked on a similar problem before, even if from outside the team
- One reviewer rotating in from a less-related team for fresh eyes
The last one is the most underrated. Domain experts will all see the same thing. A fresh pair of eyes catches the obvious-once-pointed-out problem that everyone else missed.
The proposing team brings one or two people. Not the whole team. The author, plus optionally a tech lead. More than two and the dynamic shifts to defensive.
The unwritten rules that make reviews honest
A few rules I’ve added over the years that aren’t in any template:
No “I just have one quick question” at minute forty
If a reviewer has a question that can’t be addressed in ninety seconds, they raise it as a follow-up rather than expanding the meeting. The follow-up is owned and tracked. Meetings that drift past their end time degrade trust in the process.
No relitigating approved decisions
Once a review approves a decision, reviewers commit to not bringing it back up in three months when something they didn’t anticipate happens. New information triggers a new review with the new information clearly framed. The previous review stays approved.
No surprises in the room
If a reviewer has a major concern, they raise it in writing before the meeting. The meeting is for resolving disagreements, not for surfacing them. This is the rule that takes the longest to enforce but produces the biggest quality jump.
Reviewers rotate every six months
A standing review board calcifies. Reviewers develop favorites, blindspots, and pet patterns. Rotate one reviewer per quarter to keep the gene pool fresh.
A worked example
Here’s a sketch of a review that went well, lightly anonymized.
A team proposed a migration from a self-hosted message queue to a managed service. Their doc was two pages, took a clear position, and named the riskiest assumption as “the managed service’s at-most-once delivery semantics will not break our downstream consumers in ways we can’t detect.”
In the review, the discussion went straight to that assumption. The ops reviewer asked, “how would we know if it broke?” The team didn’t have a great answer. Within twenty minutes, the decision was “approved with conditions: ship the migration behind a feature flag, dual-write for two weeks, and define three specific metrics that would trigger rollback.”
The review took thirty-five minutes. The migration happened three months later without incident. The decision held. Total reviewer time invested: about three hours. Engineering risk avoided: easily three months of cleanup if it had gone wrong.
Compare to the bad version: the same team brings an eight-page doc, presents for thirty minutes, gets thirty minutes of meandering questions, and ends with “looks good, let’s circle back when you have more details.” Net effect: zero.
Common Pitfalls
- Treating the review as a status update. If the team presents what they’ve built rather than the open questions, you’ve already lost. The review’s job is to engage with uncertainty, not to admire certainty.
- Letting prep documents balloon. A twelve-page document is a failed review before it starts. Cap it at four pages. Reviewers won’t read more, and the team will hide the important things in the noise.
- Approving by default. A board that approves everything is providing no value. If your approval rate is above eighty percent, your bar is too low.
- Reviewing too late. A review that happens after code has shipped is a postmortem with extra steps. Reviews must happen before commitment, not after.
- Confusing depth with rigor. Long meetings, detailed documents, and exhaustive question lists are not the same thing as a good review. Rigor is asking the right question, not asking every question.
When This Goes Wrong
Teams stop coming to the board. They route around it, ship things “below the threshold,” and then surprise everyone in production. Diagnosis: the board is seen as a tax rather than a useful service. Fix: shorten the process, make decisions faster, and publish a “what kinds of decisions need review” guide that’s narrow rather than broad.
Reviewers stop showing up. Attendance drops, the same two people carry the load. Diagnosis: usually the reviews are unfocused and reviewers don’t feel their time is well spent. Fix: enforce the prep document standard and the forty-five-minute time box. Quality improves, attendance follows.
Decisions don’t stick. A decision approved in March gets relitigated in May because someone wasn’t there or wasn’t paying attention. Diagnosis: weak written record. Fix: the ADR practice I describe in Writing ADRs That Actually Inform Decisions is the right pairing for a review process. The review approves the decision; the ADR captures it.
Wrapping Up
Architecture review is one of the few processes in engineering that has high leverage when done well and produces zero value when done badly. There’s no middle ground. A bad review process is worse than no review process, because it consumes senior time while creating false confidence.
The structures in this post (clear prep doc template, forty-five-minute time box, explicit decision categories, rotating reviewers) are not glamorous. They’re operational discipline. Roll them out, hold the line, and within a quarter your review meetings will become the most useful hour your senior engineers spend each week.
The book The Software Architect Elevator by Gregor Hohpe is the best treatment I’ve read of how architecture fits into the larger organization. Worth reading alongside this, especially the chapters on selling decisions and managing risk.
The best architecture reviews don’t feel like reviews. They feel like a productive conversation between senior engineers about a real problem, with a decision at the end. Build for that. Anything less is theatre.
