Asking for more people is the most common response when deliveries slip and the list of requests keeps growing. Hiring solves a lack of capacity. It does little when the team starts more work than it can finish, and on a deadline chart the two situations look the same: everything is late and everyone seems busy.
The difference shows up when you look at work that has started and not yet finished. That number is usually left out of the hiring conversation, and it changes the decision.
The arithmetic that links queues and lead time
In 1961, John Little proved a relationship that holds for any stable system with items coming in and going out: the average number of items in progress equals throughput multiplied by the average time each item spends in the system. In operations management, the same relationship appears as work in progress divided by cycle time equals throughput.
A hypothetical example makes the arithmetic concrete. A team that finishes ten items a week on average and keeps forty items started will take about four weeks to deliver each one. If it keeps twenty in progress and still finishes ten a week, the average time drops to two weeks. Nobody worked faster. The team simply stopped opening fronts that would sit waiting.
Little himself makes an important caveat in the paper where he reviews fifty years of the law: the relationship measures averages and does not, by itself, say how to change any of those numbers. It does not prove that reducing work in progress always speeds up delivery. It shows that, with stable throughput, more started items mean more waiting time for each one. Improving throughput still depends on removing blockers, waits, and rework.
Why new people can lengthen the queue
In The Mythical Man-Month, drawing on IBM's OS/360 project, Fred Brooks described why adding people to a late project tends to make it later. Newcomers need time to become productive and take time from those already on the project. The number of communication channels grows faster than the number of people. And some work cannot be split: certain tasks take the same time with one person or five.
With too much work in progress, there is an additional effect. New people usually get new items, because the old ones are stuck in review, dependencies, or pending decisions. The team increases the number of open fronts, while the items that were already stalled keep waiting for the same review, the same specialist, or the same approval.
Brooks's law does not forbid hiring. It describes the cost of hiring as a response to lateness. Hiring planned in advance, for work that can be separated, tends to work better than reinforcements called in during a crunch.
What to measure before opening a role
The Kanban Guide defines four minimum flow measures: work in progress, throughput, work item age, and cycle time. They answer questions that a hiring request should come with:
- how many items the team started and how many it finished per week over recent weeks;
- how old the oldest open items are and where they are stuck;
- how long items spend waiting for review, an environment, a decision, or another team;
- how many items each person carries at the same time.
The age of open items is often the most revealing. An item that is six weeks old, waiting on the same person who approves everything, points to a bottleneck that a generic hire will not reach. If several items age in the same stage, the problem is in that stage.
Test a limit before deciding
The guide describes the work in progress limit as the way to turn the workflow into a pull system: a new item starts only when there is capacity for it. Exceeding the limit should be rare and explicit, agreed among the people who use the workflow.
In practice, that means choosing a number lower than the current one, keeping it for a few weeks, and watching the same measures. Three outcomes are possible, and each leads to a different decision.
If throughput holds and cycle time falls, the team was overloaded with open fronts rather than with demand. Hiring now would raise costs without addressing the reason for the delay.
If items start piling up in a specific stage, for example waiting for a security review that only one person does, the capacity shortage is real but localized. Hiring, when needed, should target that skill, and there may be faster alternatives, such as training someone else to do the review.
If flow improves and important requests still arrive faster than the team can sustainably finish them, hiring now has a measured justification. The role comes with a number behind it: how much throughput needs to grow and in what kind of work.
The cost of the limit
Limiting work in progress forces someone to say that a request will wait. That cost falls on whoever leads the team and on whoever sets priorities with the areas that ask for work. Without that support, the limit becomes a number on the board that every urgent request ignores, and the team goes back to starting everything at once.
That is why the test needs to be agreed in advance, with a time frame and the measures that will be compared. It takes a few weeks of discipline and a difficult conversation about priorities. In return, the decision to hire no longer depends on the feeling that everyone is busy.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
