The approval bottleneck

A team builds a system that moves work fast. Tickets route themselves. Notifications fire the moment a task is ready. The pipeline looks, on paper, like exactly what a mature operation should look like.

And the work still waits a week for one yes. Everything upstream of the approval moves at software speed. The approval itself moves at the speed of whoever has to give it, and that person has not gotten any faster just because the ticket reached them sooner.

The natural response is to treat this as a queue problem. Faster tickets. A dashboard everyone can check, so nobody has to ask where a request sits. More visibility, more nudges, more ways to see the wait happening in real time.

None of it changes how long the wait actually is. The work still lands on the same person, and that person is still deciding at the same pace they always did, just with better lighting on the delay. Watching a bottleneck more closely does not widen it. The queue was never the bottleneck. The gate was, and no amount of queue tooling touches a gate.

The fix started with a different question. Not who approves this, which had already been answered and re-answered by the org chart, but what about this actually requires a person to look at it. Most approvals in a queue like this are not decisions. They are confirmations: the work matches the pattern, the numbers are in range, nothing unusual happened. A confirmation does not need to wait for a calendar to align. Only the requests that genuinely diverge from pattern, that carry real judgment calls, need a human in the loop at all.

So the gate got redesigned around that distinction. Anything that matched the known-good pattern cleared automatically, logged for audit, never blocked. Anything that diverged got routed to a person, but now it was a small, real set of decisions instead of everything wearing the same approval costume. The person doing the approving was finally being asked to use judgment, not to rubber-stamp volume.

Most of the work stops waiting on a person at all. It clears on its own, because most of it never needed a decision in the first place, just a confirmation that a machine can make as reliably as a person can. What used to sit in a queue for a week now clears the same day, and the person who used to approve everything now spends that time on the small number of calls that actually need a human being to make them.

The lesson generalizes past this one team. A bottleneck rarely announces itself honestly. It looks like a slow queue, so the instinct is to speed up the queue. But speed only helps a process that was actually constrained by throughput. When the constraint is a gate, judgment, a decision someone has to actually make, more throughput just moves the same wait closer to the front of the line. The fix is never a faster queue. It is a smaller, truer gate.