Managers stopped being a bottleneck and became a constraint
A bottleneck is a queue you can staff your way out of. A constraint is the thing that sets the safe rate of the whole system. Managers moved from one to the other, and most organisations are still applying the old fix.
For most of the last decade, the standard complaint about engineering managers was that they were in the way. Approvals sat with them, assignment sat with them, and anything they touched slowed down. The standard fix was to delegate: push approval to tech leads, let the team pull its own work, remove the manager from the path.
That fix worked, because the manager was a bottleneck. A bottleneck is a station with finite capacity and a queue in front of it, and you can solve it by adding capacity, removing the station, or routing around it.
What managers are now is something else. My position: the manager has become the constraint on delivery, in the specific sense that their decision rate now sets the rate at which the system can safely produce, and every technique the industry learned for fixing bottlenecks makes a constraint worse rather than better.
The difference is not semantic
A bottleneck is a capacity problem. Two reviewers, four hundred pull requests, a queue. Add reviewers, shrink the queue. The work waiting is homogeneous and parallelisable.
A constraint is a rate governor. It is the point that determines how fast the whole system can run without producing outcomes you cannot live with. You do not fix a constraint by adding capacity, because the work at that station is not parallelisable in the way that queueing work is. Two people cannot make one coupled decision twice as fast, and three managers do not make a scope trade-off three times better.
The reason this distinction now matters is that code production stopped being scarce. When engineers were the slow step, the manager’s judgement was consumed at the rate engineers could produce work needing judgement, and that rate was human. It is not human any more. The decisions that used to arrive weekly now arrive daily, and the ones that used to arrive daily arrive continuously.
Manager as bottleneck (the old problem)
- Queue of homogeneous approvals in front of one person
- Fix by delegating, batching or removing the step
- More capacity genuinely helps
- Cost of delay is elapsed time
- Routing around it is a net win
Manager as constraint (the current one)
- Coupled decisions that require the same head to hold context
- Delegating splits the context and produces contradictions
- More capacity adds coordination cost, not throughput
- Cost of delay is a decision made badly, not late
- Routing around it produces unowned change
What routing around it looks like in practice
The industry has been routing around this constraint for about eighteen months, and the numbers are visible.
LinearB’s 2026 benchmarks put pull requests merged with zero review up around 31.3 percent. That figure is usually discussed as a review problem. Read it as a decision problem instead. A zero-review merge is a change that entered production without anyone with authority forming a view about it. Some of those are trivial. Some are not, and nobody sorted them, because sorting them is exactly the work at the constrained station.
The same benchmarks show median review duration up over 400 percent and pickup time on agentic pull requests roughly 5.3 times longer. Those are the queue in front of the constraint, growing. The zero-review number is the overflow valve opening.
This is the classic failure with constraints: when the queue gets long enough, systems find a bypass, and the bypass is invisible until something goes wrong through it.
Decision latency is the metric you are missing
Most delivery dashboards measure code moving. Cycle time, lead time, deployment frequency, throughput. Under agentic delivery those measure the fast part of the system, which is why they look excellent in organisations that are quietly accumulating risk.
If the constraint is decision-making, measure decisions.
Reversal rate is the one I would add first if you can only add one. Throughput at a constrained station degrades in quality before it degrades in volume, and reversals are the cheapest observable form of that degradation.
What you actually do about a constraint
You do three things, and none of them are “hire another manager”.
Reduce the arrival rate of decisions. Most of what reaches a manager is not a genuine judgement call, it is an ambiguity that should have been resolved when the work was specified. A backlog where done is defined precisely generates dramatically fewer escalations than one where tickets are titles. This is the highest-return intervention available and it happens upstream, nowhere near the manager’s calendar.
Make the standing decisions once. A great deal of decision traffic is the same question in different clothing: what may an agent merge unattended, what always needs a named approver, what happens when a change touches permissions. Answer those as policy, write them where the pipeline can enforce them, and the individual instances stop arriving.
Set the rate deliberately instead of discovering it. If your system can produce more change than it can responsibly decide about, you have to choose where the excess goes. Choosing means an explicit policy on what merges without judgement. Not choosing means the excess still goes somewhere, it just goes wherever the path of least resistance leads, and you find out afterwards.
That third one is uncomfortable, because it means deliberately capping throughput below what the tooling can deliver. Everyone hates it. It is still better than the alternative, which is the same cap arriving as an incident review.
Where this breaks down
Plenty of managers are still a plain bottleneck, and telling them they are a constraint flatters the problem. In organisations where approvals sit with a manager purely out of habit, the old fix is still the right one: delegate, remove the step, get out of the way. Applying constraint logic to a habit-bottleneck is a very good way to justify not fixing something you should just fix.
“Decisions cannot be parallelised” is too strong. Many of them can. Clear ownership boundaries, a written architectural direction and a competent tech lead group will split a large fraction of the decision load without producing contradictions. The genuinely coupled decisions, the ones about trade-offs across teams, are a smaller set than this argument implies.
Measuring decision latency is much harder than measuring cycle time. Cycle time is in your tooling already. Decisions are made in meetings, in threads and in someone’s head on the way home. Any measurement of them is either self-reported, which is unreliable, or inferred from artefacts, which misses everything that never became an artefact. I would not present these numbers to a board as though they were as solid as DORA.
Capping throughput has a real business cost, and I have skated over it. If a competitor ships twice as fast because they accept more unowned change, and it works out for them, the deliberate governor was the wrong call and no amount of principle recovers the market position. The honest framing is a bet on which failure is more expensive in your particular market, not a universal truth.
And I have a commercial interest. We sell tooling that sits on the decision layer of delivery, so an argument that decisions are the constraint is convenient for us. Weigh it accordingly. Note that the first two of my three recommendations are entirely about how you write tickets and policy, and cost nothing but attention.
The takeaway
Managers used to be a queue. They are now a governor. The techniques the industry learned in the era of the queue, delegate harder, route around, remove the step, all reduce the visibility of the constraint without changing its capacity, and the excess reappears as change nobody formed a view about.
Measure decisions, not just code. Reduce how many of them arrive by defining done properly upstream. Convert repeated decisions into written policy the pipeline enforces. Then choose your rate explicitly, because you are choosing it either way.
If you take one thing into next week: work out what share of last month’s merged changes reached production without a single recorded human judgement, and read that number as your current bypass rate rather than as a review statistic.