Architecture reviews have a reputation problem. Developers tend to see them as bureaucratic overhead. Architecture teams tend to see them as under-resourced quality gates. Neither view is entirely wrong.
The failure mode on one side: a review process so lightweight it approves everything without adding insight. The failure mode on the other: a review process so heavyweight it becomes a negotiation rather than a conversation.
This tutorial describes a practical middle path — a review process that consistently improves technical decisions and does not slow teams down by more than it helps them.
Before the review: the pre-work that determines outcome
The quality of a review is determined almost entirely by what happens before the review meeting.
Step 1: Define what is being reviewed.
Not every technical decision warrants a formal review. The trigger should be decisions that are:
- Hard to reverse without significant cost
- Cross-system or cross-team in their effects
- Setting a pattern that other systems will follow
- Involving security, compliance, or data handling
Decisions below that bar can be handled by the team with optional consultation. Reviews are for the subset where external perspective has clear value.
Step 2: Require a written proposal.
The team requesting the review produces a short document before the meeting. Not a design spec — a decision document. It should cover:
- What problem are we solving?
- What options did we consider?
- What option are we proposing and why?
- What are we trading away?
- What would change this recommendation?
The discipline of writing this document is often where the value is created. Teams that cannot produce this document are not ready for a review. The review would be premature because the decision has not been formed clearly enough to evaluate.
Step 3: Distribute the document 48 hours before the meeting.
Reviews held without preparation time turn into soapboxes where whoever talks first shapes the conversation. Give reviewers time to read and think. Ask them to come with specific questions, not general opinions.
The review meeting
Time: 45 minutes. Not more.
If the conversation is going well at 45 minutes, it means the document was good and the reviewers were prepared. At that point, the decision should be clear enough to close or to identify the single remaining question that needs follow-up. Extending to 90 minutes almost never produces 2x the value.
Structure:
The first 10 minutes are the team’s. They walk through the proposal, emphasizing the decision — not the full technical context, which the reviewers have already read.
The remaining 35 minutes are questions and dialogue. The goal is not for reviewers to agree with every choice. It is to ensure the team has considered the important alternatives and can defend their reasoning.
The reviewer’s job:
Ask questions that surface assumptions, unexamined alternatives, and unconsidered risks. Not: “Have you thought about X?” — but: “What would happen to this design if X changed?” The second question gets to the assumption underneath the surface.
The worst kind of reviewer does not ask questions. They give verdicts without explanation, propose alternatives without acknowledging the context the team is in, or relitigate technical preferences they have held since before reading the document.
The facilitator’s job:
Keep the conversation specific. When discussion goes abstract, bring it back to the document. When someone raises a new option that was not in the document, ask whether it would actually change the recommendation or whether it belongs in a separate ADR.
Close by naming the decision: approved, approved with conditions, or needs revision. If revision is needed, specify exactly what the revision requires — not “we need more thought on security” but “the proposal needs a threat model for the data at rest scenario in section 3.”
After the review
The team updates the ADR to reflect the review outcome — including any dissent from the reviewers and why the team decided to proceed anyway, if they did.
This step is optional in almost every organization’s process and critical for the long-term value of the review system. Reviews without a record of their outcome produce no institutional memory.
Set a calendar reminder for 6-12 months out to revisit significant architectural decisions. Conditions change. The review is not a final verdict; it is a checkpoint at a specific point in time.
Calibrating your process
The right level of process depends on your organization’s size, risk profile, and technical maturity.
A five-person startup should not have a formal architecture review committee. The overhead would exceed the benefit. A 150-person engineering organization in a regulated industry probably needs more rigor than what I have described here.
The constant across all scales: the value of a review is in the quality of the thinking before the meeting, not in the meeting itself. Any process improvement that increases the quality of the document and the preparation will improve review outcomes more than any improvement to the meeting structure.