The program was behind, so it added five people. The reasoning was the reasoning everyone reaches for: more hands, more output, faster. Three weeks later it was further behind. The five new people needed onboarding from the few who already understood the system, which pulled the most valuable contributors off the work to explain it. Coordination got heavier. And the one thing that had actually been holding the program back was no busier with five extra people than it had been without them, because none of the five could touch it.
This is the resourcing mistake that feels like diligence. A program slips, and the response is to spread more resource across it — staff every workstream, push utilization up, get everyone busy. But busy is not the same as productive, and a team at full utilization can produce almost nothing if the wrong things are full. Throughput is not governed by how hard everyone is working. It is governed by one thing at a time.
So we stopped asking how to keep everyone busy and started asking what the single constraint is, and whether we are spending against it.
Utilization is not throughput
There is always a constraint — the one workstream, person, decision, or dependency that everything else waits on. Maybe it is the lone integration architect every interface routes through. Maybe it is a sign-off only one stakeholder can give. Whatever it is, the program goes exactly as fast as that constraint goes, and not one step faster, no matter how productive everything else becomes.
Which means effort spent anywhere but the constraint produces motion, not progress. It generates work-in-progress that piles up in front of the bottleneck, status that looks healthy, and a team that is genuinely working hard — and a finish date that does not move. The hard discipline is to look at a busy program and recognize that most of the busyness is not buying anything.
Allocating against the bottleneck
Spending resource where it actually changes the date is a specific habit:
- Find the one constraint. At any moment, one thing governs the date. Name it. If you can't, you are about to staff everything except the part that matters.
- Staff it first. The constraint gets your best people and your protected time before anything else is resourced. Relieving it is the only move that moves the date.
- Subordinate everything else. Other workstreams serve the bottleneck's pace. Running them faster than the constraint can absorb just builds inventory in front of it.
- Protect it from noise. Keep the bottleneck resource off status decks, side requests, and onboarding duty. Every hour it spends elsewhere is an hour the whole program waits.
- Re-find it when it moves. Relieve one constraint and another becomes the binding one. The bottleneck is a moving target; allocation is a standing question, not a one-time plan.
None of this is about working less. It is about pointing the work at the one place that converts effort into a sooner finish, and refusing to mistake activity elsewhere for that.
The cost of spreading thin
Resource a program evenly and you get the illusion of progress and very little of it. Everyone is occupied, every workstream reports movement, and the date holds where it was — because the constraint was never the thing being fed. Worse, the added coordination and onboarding can pull from the constraint and push the date out, which is how a program adds people and gets slower. The motion is real. It just isn't progress, in the same way that drift isn't progress — both are movement that doesn't close the distance.
And the constraint you are staffing against is often a hard limit you can't remove at all, which is its own discipline: designing within the constraint rather than fighting it.
It ties back to the ledger
The program finishes on time because the resource went where the resource mattered — into the one constraint governing the date — and everything else was arranged to serve that pace. Progress is the bottleneck moving, not the team being busy. A full program and a fast program are different things, and telling them apart is most of what good resource allocation is.