An architecture review board of five people meets weekly for 90 minutes. The organisation has 120 teams shipping continuously. Leadership asks the board to review "all significant changes". Estimate what that means and what the board should actually review.

The assumptions, stated

• 120 teams. Each makes, generously, one architecturally significant decision per quarter — a new datastore, a new external dependency, a new service, a cross-boundary data flow, a change to an interface others consume. That is 480 a year.
• A review that is worth attending needs roughly 20 to 30 minutes of board time plus reading, so 25 minutes as the planning figure.
• The board has 90 minutes a week, about 45 weeks a year: 4,050 minutes of capacity.

The arithmetic

Demand: 480 × 25 = 12,000 minutes. Capacity: 4,050 minutes, or about 160 reviews a year, three or four a week. The board can see roughly a third of the significant decisions, and that is with an optimistic estimate of one per team per quarter and no time spent on anything else.

If you assume two significant decisions per team per quarter, which is closer to reality in a growing organisation, the board can see about 17%. And a queue that receives 10 items a week and clears 3.5 grows without bound: at that ratio the wait reaches six weeks within two months, which is the familiar symptom.

Which assumption dominates the error

The definition of "significant", by a wide margin. Everything else moves the answer by a factor of two; the threshold moves it by an order of magnitude. This is why arguing about board process is wasted effort until the threshold is written down. A board reviewing every new service and a board reviewing every change that is expensive to reverse are two different institutions with the same name.

What the number rules in or out

• It rules out universal review, arithmetically, at any realistic board size. Growing the board to ten people doubles capacity and still covers under 70% of the optimistic demand, while making every meeting worse.
• It rules in a threshold with examples. Review what is expensive to reverse and wide in blast radius: a new primary datastore, a new jurisdiction for personal data, a new third-party on the critical path, a change to a contract other teams consume, anything that creates a new always-on cost line. Everything else is advisory on request.
• It rules in automation for the rest. The decisions the board stops reviewing do not become ungoverned; they become machine-checked. A policy check in the pipeline runs on all 480 decisions and costs nothing per decision, which is the only mechanism that scales with 120 teams.
• It rules in the advisory model with a documented deviation route. If a team can proceed over the board's objection by recording the decision and its rationale, the queue stops being a blocker and the board's influence becomes its argument quality rather than its veto.

When the arithmetic argues for a board anyway

In a regulated environment where a design decision carries external evidential weight, the review exists to produce a record, and the cost is the point. Then size the threshold to the evidential requirement, not to the engineering risk, and expect the number of reviewable items to be small and specific. The failure mode to avoid is a board that reviews everything slowly in order to be seen to govern, which produces neither evidence nor better architecture.

Common weak answers

• "Add more people to the board." Doubles capacity, multiplies coordination, and does not change the order of magnitude.
• "Teams should engage earlier." True and orthogonal. Earlier engagement with a queue that cannot clear produces an earlier wait.