How to Run Architecture Reviews That Don't Waste Time

I've sat through hundreds of architecture reviews. Most of them followed the same pattern: someone presents slides for 45 minutes, a few people ask questions, everyone says "looks good," and the meeting ends with no clear decision.

Then three months later, the team discovers a fundamental problem with the design that would have been obvious if anyone had actually reviewed it instead of just attending a meeting.

Architecture reviews as most orgs run them are theater. They give the appearance of due diligence without the substance. Here's how to run them so they actually catch problems.

# Why Architecture Reviews Fail

# Failure 1: The Presenter Controls the Narrative

When you let the person proposing the architecture walk you through a polished slide deck, you see the design through their lens. They've already decided it's good. Their presentation emphasizes the strengths and glosses over the tradeoffs.

By the time they're done presenting, the audience has spent 40 minutes nodding along. The cognitive effort required to switch from "absorbing information" to "critical evaluation" is enormous. Most people don't make the switch. They ask a clarifying question or two and approve.

# Failure 2: No Pre-Work

Reviewers show up cold. They haven't read the design doc. They don't know the requirements. They're seeing the architecture for the first time, real-time, while simultaneously trying to evaluate it. This is like reviewing a PR by watching someone scroll through the diff at their pace. You'll miss everything.

# Failure 3: Wrong People in the Room

Three types of wrong people attend architecture reviews:

• The tourist: Came because the meeting showed up on their calendar. Has no context on the system. Will ask a basic question that wastes 10 minutes.
• The politician: Has an agenda unrelated to the architecture. Will steer the discussion toward their pet technology or away from a decision that threatens their team's ownership.
• The silent expert: Knows exactly what's wrong but doesn't speak up because the meeting format doesn't create space for deep technical pushback.

# Failure 4: No Decision Framework

"Does this look good?" is not a decision framework. What does "good" mean? Good for current requirements? Good for 10x scale? Good for operability? Good for the team that has to maintain it?

Without explicit criteria, the review becomes a subjective vibes check. And vibes checks miss structural problems.

# The Contrarian Take: Architecture Reviews Should Be Adversarial

Not hostile. Adversarial. Like a thesis defense, not a presentation.

The proposer's job is to convince the reviewers that this is the right architecture. The reviewers' job is to find reasons it isn't. If the architecture survives adversarial review, you can have high confidence it's sound. If it doesn't survive, better to find out now than in production.

This requires a cultural shift. Most engineering cultures treat questioning a colleague's design as rude. You need to create a context where it's expected, welcomed, and professional.

I tell my teams: "In an architecture review, attacking the design is how you show respect for the designer. It means you're taking their work seriously enough to stress-test it."

# The Review Process That Works

# Step 1: Written Design Doc (Required, 3-5 Days Before)

No slides. No presentations. A written design document that follows a standard template. Ours has these sections:

1. Problem Statement: What are we solving? For whom? What's the business impact?
2. Constraints: Performance requirements, budget limits, timeline, compliance needs.
3. Proposed Architecture: Diagrams and descriptions. How components interact. Data flow.
4. Alternatives Considered: At least two other approaches with reasons for rejection.
5. Tradeoffs: What are we giving up with this approach? Where are the risks?
6. Operational Plan: How will this be deployed, monitored, and maintained?

The "Alternatives Considered" section is mandatory. If the proposer can't articulate alternatives, they haven't thought deeply enough about the design space.

The document is shared at least 3 business days before the review. This is non-negotiable. If the doc isn't ready, the review gets rescheduled.

# Step 2: Async Review Phase (3 Days)

Reviewers read the doc and leave comments asynchronously. We use Google Docs comments or GitHub PR-style reviews depending on the team.

This phase catches 60-70% of issues. Typos, unclear sections, missing considerations, basic technical concerns. All handled before anyone sits in a room together.

Every reviewer must leave at least three substantive comments. This isn't bureaucracy. It's a forcing function. If a reviewer can't find three things to question, they either didn't read the document carefully or the design is unusually good. Both are worth knowing.

# Step 3: The Review Meeting (60 Minutes, Strictly)

The meeting is NOT a presentation. The proposer does NOT walk through slides. Everyone has already read the document.

The meeting structure:

Minutes 0-5: Proposer's opening. Three minutes maximum. "Here's the one thing I'm most uncertain about and the one constraint that shaped the design most heavily." This frames the discussion around the areas where input is most valuable.

Minutes 5-40: Structured interrogation. The facilitator (not the proposer) drives the discussion through four questions:

1. What breaks at 10x scale? Force the group to think about what happens when usage grows an order of magnitude. This catches under-provisioned databases, missing caching layers, and single points of failure.

2. What happens when Component X fails? Pick the two most critical components. Walk through failure scenarios. This catches missing circuit breakers, inadequate error handling, and cascading failure risks.

3. What's the operational burden? How many people does this need to keep running? What monitoring is required? What's the on-call impact? This catches designs that are elegant in theory but nightmarish in practice.

4. What's the migration path? How do we get from here to there without downtime? This catches designs that require big-bang migrations, which almost always go wrong.

Minutes 40-50: Open discussion. Any remaining concerns, questions, or suggestions.

Minutes 50-60: Decision. One of three outcomes:

• Approved. Proceed as designed.
• Approved with conditions. Proceed, but address specific concerns before implementation begins. Conditions must be written down with deadlines.
• Needs revision. Significant concerns that require design changes. Schedule a follow-up review within 2 weeks.

There is no "let's think about it." Meetings end with decisions.

# Step 4: Decision Record (Within 24 Hours)

The facilitator publishes a one-page record: decision, conditions (if any), key concerns raised, and participants. This becomes part of the project's permanent record.

# Who Should Be in the Room

Keep the invite list small. My formula: the proposer, the facilitator, and 3-4 reviewers. That's 5-6 people maximum.

The proposer: Owns the design and will implement it.

The facilitator: Runs the meeting. Ensures all four questions get covered. Not the proposer's manager. Ideally someone from another team who can bring an outsider perspective.

Reviewer 1: Domain expert. Someone who knows the existing system deeply. They'll catch integration issues.

Reviewer 2: Operations expert. Someone who's been on-call for similar systems. They'll catch operational nightmares.

Reviewer 3: Fresh eyes. Someone from a different part of the org. They'll ask "dumb" questions that aren't actually dumb.

Optional Reviewer 4: Security or compliance. Only if the design touches sensitive data, authentication, or regulated domains.

# The Stealable Framework: The 4-Question Architecture Review

Every architecture review answers four questions:

1. What breaks at 10x? (Scalability)
2. What happens when X fails? (Resilience)
3. Who keeps this running? (Operability)
4. How do we get there from here? (Migration)

If the design survives these four questions with clear answers, it's probably sound. If it can't answer even one, it needs more work.

Print these four questions. Put them on the wall of every meeting room where architecture reviews happen. They're your defense against the two most expensive words in engineering: "looks good."