Adding a Person Made Your Cycle Time Worse. Little's Law Says That Is Expected.
The new hire did not slow the team down. The four extra items everyone started because there was now capacity to start them did, and the arithmetic is predictable.
Founder of FlowBoard · Full-stack developer & serial entrepreneur
The complaint
A five-person product team hired a sixth engineer in March. By May the founder was quietly worried. Things were taking longer than they had with five people, and nobody could point at anything that had gone wrong.
The obvious explanations were all uncomfortable. Maybe the hire was not working out. Maybe onboarding had cost more than anyone budgeted. Maybe the team had crossed some size threshold where coordination overhead kicks in, which someone had read about.
The new engineer, for what it is worth, was doing fine. Shipping steadily by week three.
What the numbers said
Before the hire: about eleven items in progress across five people, finishing roughly six a week.
After: about nineteen items in progress across six people, finishing roughly seven a week.
Throughput went up, which is what you would hope for. Work in progress went up considerably more. Run those through Little's Law, where average cycle time equals average work in progress divided by average throughput:
Before: 11 / 6 = 1.8 weeks.
After: 19 / 7 = 2.7 weeks.
A fifty percent increase in delivery time, from a team that got strictly more productive.
The reframe
The new person did not slow anything down. The eight extra items the team started because there was now capacity to start them did.
Note the arithmetic carefully: one extra engineer, twenty percent more people, and work in progress grew by seventy percent. That is the part that did the damage, and it was not a decision anybody made. Nobody said "let us run more work in parallel". Several people independently noticed there was a bit more room and started something.
This is not a coordination-overhead story and it is not a Brooks's Law story about adding people to a late project. It is simpler and more mundane. The team's delivery time is governed by an equation with two inputs, hiring moved both of them, and it moved the wrong one further.
Why growth pulls WIP up faster than headcount
Three things happen at once when a team grows, and all three push in the same direction.
The new person needs something to do immediately. They cannot pair on everything, so they start something of their own. That is one new item, which is proportionate.
The person onboarding them starts something too. Onboarding is not a full-time job after the first week, but it fragments the day enough that a long-running item feels unwise, so people pick up extra smaller things to fill the gaps.
The backlog pressure that was being held back gets released. Every team has a set of things that would obviously be worth doing if only there were capacity. Hiring is exactly the signal that capacity has arrived, and several of those items get started in the same fortnight.
None of that is irrational. It is just that the visible constraint, people, is not the binding one. See Little's Law for software teams.
What to change on Monday
Set the work-in-progress limit before the new person starts, not after.
Two items per person is the usual figure, so a team going from five to six should move its cap from ten to twelve. Deliberately, as a number someone writes down, rather than emergently as whatever people happen to pick up.
The team above capped at twelve in June. Work in progress fell from nineteen to twelve over three weeks, throughput held at seven, and cycle time came in at 12 / 7, about 1.7 weeks. Slightly better than they had managed with five people, which is what hiring was supposed to buy them in the first place.
See WIP limits for how to set one without turning it into a process the team resents.
The metric to watch
Work in progress, counted weekly, as a ratio to headcount. One number, thirty seconds to collect, and it is the leading indicator for every delivery-time problem on the flow metrics guide.
If that ratio is drifting upward, your cycle time is already getting worse and the effect has not finished arriving yet. Check it the month after any hire, any reorg, and any quarter where somebody senior asks whether the team could take on a bit more.
See Your Real Flow Metrics
Cycle time, throughput and aging work in progress, calculated from the work you already track. No story points required.
Open a Free WorkspaceMore from Flow Metrics: The Complete Guide for Teams Without Sprints
Flow Metrics: The Complete Guide for Teams Without Sprints
Cycle time, lead time, throughput, WIP and flow efficiency explained for small teams. What each one tells you, how to read it, and what to do when it goes wrong.
MetricsCycle Time vs Lead Time: What Each One Actually Tells You
Cycle time measures your team. Lead time measures the customer experience. The gap between them is the number nobody looks at, and usually the one that matters.
MetricsHow to Read a Cumulative Flow Diagram (And What a Broken One Looks Like)
Every guide explains the coloured bands. Almost none show you the four shapes that mean something is wrong. Here are both, with the fix for each.
MetricsThroughput: The Only Delivery Metric That Survives Without Sprints
Velocity is undefined the moment you drop sprints. Throughput keeps working, needs no estimates, and is the raw material for every forecast you will make.