An architecture review board reviews everything and has a six-week queue. What should it stop reviewing, and how should the triggers be defined?

What it should stop reviewing

Anything whose consequences are contained within one team's boundary. Internal architecture, framework choices, module structure, testing approach, and implementation decisions with no cross-team or external effect. These are the team's to make, and reviewing them adds delay without reducing risk.

Anything already covered by an automated guardrail. If policy prevents unencrypted storage, the board should not be checking for it — that is a control that scales, and re-checking it manually is pure queue.

Anything with a published pattern the team has followed. If the reference architecture decides the question and the team conformed, the review adds nothing.

The triggers that should remain

Defined in advance, so teams know before they start:

• A new persistent data store, because data decisions are the least reversible.
• A new external interface to customers or partners, which becomes a contract you cannot unilaterally change.
• Personal or regulated data crossing a boundary — a new store, a new region, a new third party.
• A new failure domain or a change to an existing one, since availability consequences cross teams.
• A dependency added to a critical path, which lowers the availability ceiling for everyone.
• Spend above a threshold, or a commitment that constrains future options.
• An irreversible decision — tenancy model, identity scheme, shard key.

Each has consequences that land outside the team, which is the principle behind all of them.

Fixing the queue

1. Self-service for the common case. A published questionnaire teams complete themselves, with the board reviewing only answers indicating risk. This converts a queue into a filter.

2. Bounded turnaround, published. Unpredictable lead time causes routing around more than the review does.

3. Advisory early sessions, unqueued and cheap, where the board's experience is worth most.

4. Asynchronous review by default, with a session only for genuine disagreement.

5. A verdict, not a comment list. Approved, approved with conditions, or not approved with specific required changes. Twenty comments and no decision leaves the team unable to proceed or to argue.

The measure of success

Whether teams bring things to the board before they are required to. A board with a six-week queue is being avoided, and every avoidance is an ungoverned decision — so shortening the queue is a governance improvement, not a concession.