Architecture review boards are widely disliked and frequently ineffective. What makes a review actually improve a design, and what should the reviewer's posture be?

Why they fail

• Too late. A review at the end of design, when the work is done and the deadline is close, can only approve or obstruct. The team has already committed emotionally and practically, and any substantive finding is received as an attack.
• Gatekeeping rather than improving. A board whose output is approval or rejection is optimising for its own risk, and teams respond by presenting the minimum, avoiding the process, or framing decisions as already made.
• Reviewers without context, generating generic objections that the team has already considered and cannot efficiently rebut.
• No decision authority in the room, so the review generates opinions that must be re-litigated later.
• Style preferences presented as findings, which destroys the reviewers' credibility for the findings that matter.

What makes a review work

• Early and repeated. A thirty-minute conversation at the point of the first significant decision is worth more than a two-hour review of a finished design. The value of a review is inversely proportional to how much has been built.
• Focused on the decisions, not the diagram. The useful question set is small: what are the quality attributes that matter, what alternatives were considered, what would make this the wrong choice, what is irreversible, and what happens when each dependency fails.
• Reviewers who prepare, having read the material beforehand, so the session is discussion rather than presentation.
• Findings ranked, with the reviewer stating which are blocking and which are observations. A list of twenty undifferentiated comments transfers the prioritisation burden to the team and is usually ignored entirely.
• Every finding paired with a constructive alternative. "This will not scale" is not a finding; "this will not scale beyond roughly X because of Y, and here are two ways to address it" is.
• A written outcome recording the decisions and the accepted risks, so the conversation is not repeated in six months with different people.

The reviewer's posture

Assume the team knows more about their problem than you do, because they do. The reviewer's advantage is breadth — having seen this pattern fail elsewhere — not depth.

The most productive questions are those the team cannot answer:

• "What did you consider and reject, and why?" An empty answer is the single most informative result in a review — it means the design is the first idea, not a chosen one.
• "What would have to be true for this to be the wrong choice?" This surfaces the assumptions, which is where the risk lives.
• "Which parts of this are hard to reverse?" Effort should concentrate there and nowhere else.
• "What happens when this dependency is slow rather than down?" Consistently productive, consistently unconsidered.
• "Who operates this at 3am, and what do they see?"
• "What is the simplest thing that could work, and what specifically rules it out?"

Separating the two kinds of review

Advisory review — help the team make a better decision, no authority, early, frequent, cheap. This is where almost all the value is.

Governance review — an organisational decision about risk, compliance or standards, with authority, applied to a small number of genuinely significant decisions.

Conflating them produces the worst of both: teams experience advice as gatekeeping and governance as opinion. Naming which one is happening, at the start of the session, resolves most of the dysfunction.