Running Architecture Review Meetings That Work

Architecture reviews have a reputation problem. Teams see them as gatekeeping, reviewers see them as a pile of documents they skimmed in the elevator, and the meeting devolves into a debate about naming. The fix is not fewer reviews but better mechanics: clear purpose, prepared participants, and a visible outcome.

Decide what the meeting is for

A review can serve three different purposes, and mixing them wastes the hour.

| Purpose | Question answered | Typical outcome | |---------|-------------------|-----------------| | Advisory | What are we missing? | Feedback list, no veto | | Approval | May this proceed? | Approve, approve with conditions, reject | | Alignment | Do neighbouring teams agree? | Agreed interfaces and owners |

Say which one it is in the invite. Advisory reviews should happen early; approval reviews belong before irreversible commitments such as signing a vendor contract or migrating data.

Require pre-reads

Do not present the design live to people seeing it for the first time. Send the design doc at least two working days ahead and ask reviewers to leave comments beforehand. Start the meeting by silently reading for ten minutes only if the doc was not circulated. Pre-reads convert a presentation into a discussion, and the presenter spends the time on contested points instead of walking through slides.

Use a fixed agenda

A sixty-minute agenda that works:

00-05  Goal of the review and decision needed
05-10  Presenter summary: problem, proposal, top three risks
10-45  Discussion, ordered by comment severity
45-55  Decision and conditions
55-60  Actions, owners, dates

The facilitator is not the presenter. Their job is to keep time, park tangents in a visible list, and make sure quieter participants are asked directly.

Review against criteria, not taste

Agree on the lens up front. A short checklist keeps the conversation anchored:

Does it meet stated requirements, including non-functional ones such as latency and availability?
What are the failure modes, and how will we detect them?
How is data owned, secured, and migrated?
What does it cost to run and to change?
Is the team able to operate it?

Tag comments as blocking, important, or nit. Without this, a naming preference and a data-loss risk are given equal airtime.

Record the decision

End every meeting by stating the outcome aloud, then write it down within 24 hours. A decision record needs only: decision, conditions, owner of each condition, date to revisit. For example: "Approved with two conditions: load test at 3x peak before launch (Dana, by 14 March); add a rollback runbook (Omar, by 21 March)."

If no decision was reached, record that too, with who will decide and by when. An unrecorded decision will be relitigated.

Make it safe to be wrong

Presenters should not feel they are on trial. Reviewers should lead with questions: "What happens if the queue is unavailable?" lands better than "This will fail." Praise specific good choices. Over time, teams that feel reviews help them will bring designs earlier, which is the real goal.

Measure and adjust

Every quarter, ask: how many reviews changed a design materially? How long from request to decision? Did any incident trace to something a review should have caught? If reviews never change anything, they are theatre; if they delay teams for weeks, they are a bottleneck. Consider lighter paths, such as an asynchronous review for low-risk changes, reserving meetings for high-impact ones.

Key takeaways

State the review's purpose: advisory, approval, or alignment.
Circulate the doc in advance and discuss rather than present.
Use a timed agenda and a facilitator who is not the presenter.
Classify comments by severity so important issues get time.
Write down the decision, conditions, and owners within a day.