Architecture Reviews

An architecture review should produce decisions. Not opinions, not concerns, not vague agreement that "the approach looks reasonable." Decisions — specific, documented, with owners and consequences understood. If the review ends without a clear decision on every open question, it was a discussion, not a review.

The failure mode of most architecture reviews is social, not technical. The senior engineer who dominates the conversation. The stakeholder who nods along without understanding. The team that defers to authority instead of evaluating evidence. A well-run review creates a structure that makes these dynamics visible and manageable.

1. Pre-Read Distribution Send the architecture document 48 hours before the review. Not a slide deck — the actual document with diagrams, trade-off analysis, and open questions clearly marked. Attendees who arrive having read the document contribute decisions. Attendees who arrive cold contribute confusion.
2. Open Questions First Start the review with the open questions, not the presentation. "Here are three decisions we need to make today. Here are the options and trade-offs for each. Let us work through them." This orients the room toward output, not consumption.
3. Evidence Over Authority When opinions conflict, ask for evidence. "What data supports that concern? Have we seen this pattern fail in a similar engagement? What would we need to measure to know which approach is better?" The review should surface the best argument, not the loudest voice.
4. Document Decisions Live Write down every decision as it is made — in the meeting, visible to everyone. Decision, rationale, owner, and any conditions. If a decision cannot be made today, document what information is needed and who will get it by when. The meeting notes are the deliverable.