How would you structure a design review function that improves decisions without becoming a bottleneck?

What is being tested

Whether you reduce the number of decisions needing review rather than reviewing faster.

The model: advisory by default, gating by exception

1. Reduce what needs review at all. The highest-leverage act available: publish standards and provide paved roads so most decisions are already made.

A team using the standard pipeline, the standard database and the standard deployment pattern needs no review — the decisions were made once, centrally, and encoded in the easy path.

2. Publish what "significant" means, with concrete examples, so teams self-identify. A new data store, a new integration pattern, a change to a security boundary, a cross-team boundary. Everything else proceeds without asking.

3. Engage early, at the shape of the design rather than at its completion. A thirty-minute conversation before implementation is worth more than a review of finished work — and reviewing 800 lines of completed work is the most demoralising pattern available, as well as the most expensive to act on.

4. Advise rather than approve, for most things. Approval creates optimisation for getting through review; advice creates better designs. Reserve gating for genuinely high-risk decisions — irreversible, security-relevant, or organisation-wide.

5. Turn around in days, not fortnights. A fortnightly meeting adds a fortnight to every decision, and teams will route around it — which produces designs with no review at all.

6. Record decisions so precedent accumulates, and the same question is not re-asked. Over time the recorded decisions become the standards, which further reduces what needs review.

The measure

Not reviews conducted, which measures activity and rewards becoming a bottleneck.

Better: the proportion of decisions that did not need review because standards had settled them, and the turnaround time for those that did.

Choose measures that would look bad if the function became a bottleneck.

The failure to name

Reviewing at the end, when the work is complete and changing anything is expensive. It produces either rubber-stamping or a demoralising rework demand, and both damage the function's standing.