Every change to a cross-team interface must be approved by an architecture forum that meets weekly with six 20-minute slots. About 14 requests arrive each week. Over the next two quarters, what happens to the queue and — more importantly — what happens to the designs themselves?

Week by week, what happens

• Weeks 1 to 4. Fourteen arrive, six are served, the backlog grows by eight a week. Wait time for a new request goes from days to roughly four weeks. The forum still feels productive because it is full.
• Weeks 5 to 10. Teams adapt in two ways, and the second one is the expensive one. They bundle unrelated changes into one request so that a single slot buys several decisions. And they design for options they may not need, because a second visit costs another month, so a proposal that needed one endpoint arrives with a configurable abstraction, a versioning scheme and an extension point.
• Weeks 11 onward. Shadow decisions start. The interface change goes ahead and is brought to the forum retrospectively, or not at all. Attendance by senior people drops because the agenda is now bundles they cannot assess in 20 minutes.

Where it amplifies

The forum's throughput falls as the bundles grow, so the queue accelerates rather than stabilising: bigger items take more than one slot, and rejected bundles return whole. Meanwhile the inflated designs enter the codebase and become the next generation's constraints. Queueing on approvals does not merely delay architecture; it systematically makes it more complicated, because optionality is the rational hedge against slow decisions. That is the second-order effect most governance reviews never measure, and it outlives the forum.

What the users see

Lead times lengthen in a way that looks like engineering slowness, because the wait is invisible in delivery metrics: the work is not in progress, so it is not late. Teams stop proposing small improvements at all — the ones whose value is smaller than the cost of getting them approved — which is a silent loss of exactly the changes that keep an estate tidy.

What stops it

Not a bigger forum. Three mechanisms, in order of effect:

1. Delegate by blast radius, in writing. Reversible changes inside one team's boundary need no forum. Changes to a shared contract with more than two consumers, to a data retention rule, or to anything with a one-way door do. Publish the list; the test must be applied by the requester without asking.
2. Asynchronous review with a named reviewer and a deadline. A written proposal, one accountable reviewer, a 48-hour response commitment and default approval if the deadline passes. The forum keeps only the genuinely contested and the genuinely irreversible.
3. Measure decision latency and publish it. Request timestamp to decision timestamp, p50 and p90, plus the share of decisions that were taken outside the process. A rising share is the clearest available evidence that the process has stopped being real.

A target worth holding: p90 under five working days. Above two weeks, expect bundling and optionality as a matter of course.

What would have to be true for this to self-heal

Only if arrival rate fell below service rate on its own, which happens when teams stop asking. That looks like recovery in the forum's metrics and is the failure completing. Any governance measure whose success signal is "fewer requests" needs a second signal from outside the process.

When this is the wrong answer

When the decisions really do need the room. A regulated change, a cross-company commitment, a choice that cannot be reversed for five years: those deserve a quorum, a record and a wait, and routing them through a 48-hour default-approve is how an organisation acquires a liability. The split is not speed against care; it is matching the cost of the decision process to the cost of being wrong, item by item.