Measure governance by review burden, not technical difficulty
Architecture review boards fail in two ways: they become bottlenecks, or they become rubber stamps. The fix is to classify work by how much deliberation a decision needs.
Every large program eventually creates an architecture or technical review board, and every board eventually faces the same complaint: it is either too slow, because every change waits in the same queue, or too shallow, because the volume forces reviewers to skim. Both complaints are usually true at once. The board is spending its scarce attention evenly across work that does not need it evenly.
The usual response is to triage by technical complexity. Big, hard projects get deep review; small, easy ones get a lighter touch. This feels right and works poorly, because technical difficulty is not what makes a review hard. A large, technically demanding migration that follows established standards with no contested decisions needs confirmation, not deliberation. A small change that touches a shared identity service, crosses an organizational boundary or sets a precedent needs real debate regardless of its size.
Classify by the decision, not the project
A more useful question for intake is: how much deliberation will this decision actually require of the board? Some submissions are confirmatory, where the standards are clear and the board's job is to verify they were followed. Some are deliberative, where reasonable architects would disagree and the board must weigh options. A few are adjudicative, where the decision resolves a conflict between parties or sets policy for everyone after. Each tier deserves a different process, a different amount of reviewer time and a different kind of documentation.
Framing intake this way has a side effect that boards tend to appreciate: it makes the board's own workload visible and defensible. Leadership can see how much of the board's time goes to confirmation that could be automated or delegated, and how much goes to the contested decisions that are the actual reason the board exists.
What good looks like
A well-run review function moves routine work quickly, concentrates expert attention where decisions are contested, records every decision in a form a future team can read, and measures itself by whether its decisions held up, not by how many it made. Governance designed this way stops being the step everyone dreads and becomes the mechanism by which an organization learns what its own architecture is.