A team running at 95% of capacity is not a little slower than a team running at 50%. By the math of queueing theory, work waits in line roughly 19 times longer. Same people, same talent, same hours — the only difference is how full the pipe is. And the fuller you push it, the worse it gets, faster than anyone expects.

That number comes from a piece of operations math most managers have never been handed: Little's Law. It is taught to factory engineers and Kanban coaches, and almost nobody else, which is a shame, because it quietly governs why your remote team feels slow even when everyone is clearly busy. The instinct when delivery drags is to add more — more people, more hours, more projects in flight. Little's Law says that instinct is usually backwards.

This piece does three things. It explains what Little's Law actually says (it is simpler than it sounds). It shows why running a team near full capacity is a trap, with the numbers. And it looks at why 2026's favorite productivity tool — AI — is quietly making the problem worse.

What Little's Law actually says

Start with the source. In queueing theory, Little's Law states that "the long-term average number of customers (L) in a stationary system is equal to the long-term average effective arrival rate (λ) multiplied by the average time that a customer spends in the system (W)." Algebraically, L = λW. John Little published the general proof in 1961.

The reason it travels so well is the part people skip. The relationship, as Wikipedia puts it, "is not influenced by the arrival process distribution, the service distribution, or the service order." Translated: it does not care how chaotic your work is, what order you do it in, or how lumpy the requests arrive. Any stable system where things come in, sit a while, and leave obeys it. A checkout line, an ER, a support inbox, a product roadmap — all the same law.

Rearrange the formula for work and it becomes the single most useful sentence in this article. Throughput is how much you finish per week; work in progress (WIP) is how much is open at once; cycle time is how long the average item takes. Little's Law says cycle time = WIP / throughput.

Picture a team that finishes five projects a week. If ten projects are open at once, each one takes, on average, two weeks to clear. Leave fifty open — same team, same five-a-week pace — and the average project now takes ten weeks. Nothing about the people changed. The only thing that changed is how much was in flight. That is the whole trick, and it is why "we'll just start it now and get to it" is the most expensive sentence in remote work. Starting a thing does not move it forward. It lengthens the line for everything else. This is a different failure from the single-track problem, where one shared resource physically can't be parallelized; here the work can run in parallel, and that is exactly what buries it.

The 100% utilization trap

So why not just run flat out? If the team can absorb fifty projects, isn't a fully loaded team an efficient one? This is where the math turns genuinely counterintuitive, and where the data-report part of this piece earns its name.

As a system gets busier, the time work spends waiting does not climb in a straight line — it climbs on a curve that goes vertical near the end. The standard result, Kingman's formula, makes the queue wait proportional to a single factor: utilization divided by one-minus-utilization, or ρ/(1−ρ). Run the numbers and the trap is obvious:

Go from half-full to nearly-full and the waiting balloons nineteenfold. The mathematician John D. Cook puts the endpoint bluntly: "As the utilization ρ approaches 1, the wait time goes to infinity." And the pain starts early — "the curve does go up quickly when ρ exceeds 0.8." A team you have loaded to 95% is not 5% away from a team at 90%. It is roughly twice as slow to respond, and one surprise away from gridlock.

The mechanism is variability. Real work is bumpy — a sick day, an urgent escalation, a task that takes three times longer than scoped. Slack is what absorbs those bumps. Remove the slack and every bump turns into a queue that never drains. One engineer put it precisely on Hacker News, citing lean pioneer Don Reinertsen: "developers should be kept at roughly 65-75% utilization. Otherwise, contra-intuitively, work queue lengths increase exponentially the closer utilization gets to 100%. The reason is that slack in the system absorbs and smooths perturbations and variability, which are inevitable." Idle time is not the waste. It is the buffer doing its job.

The sacred cow: "I'm paying for full capacity"

Every instinct in management pushes the other way, and the instinct is not stupid. Idle people look like money on fire. A manager who sees a teammate with spare hours feels, reasonably, that they are overpaying. Capacity you bought and did not use is the textbook definition of waste, and chasing high utilization is how good operators have squeezed cost out of factories for a century. The steelman is real: slack looks like slack.

Here is the hidden condition that breaks it. Utilization and speed are allies only up to about 80%. Past that line they become enemies, and the trade gets brutal fast. The spare capacity you proudly eliminated was not waste — it was the shock absorber that kept the queue short. Cut it, and you do not get a faster team that costs less. You get a team that is fully booked, permanently behind, and slower on every single item, because by Little's Law a longer queue is a longer cycle time. You optimized the one number that is easy to see (are people busy?) and wrecked the one that customers actually feel (how long does my thing take?).

That is the counterintuitive core: you do not speed up a team by filling it. You speed it up by leaving it room. A team that looks 100% efficient on a capacity chart is usually the slowest-delivering team you have — it has just hidden the delay inside a queue instead of an idle calendar. The busyness is real. The progress is not, which is the same gap between motion and outcome that makes so many hardworking teams quietly lose.

Why adding people and projects backfires

Once you see work as a queue, the two reflexive fixes for a slow team both get exposed.

The first reflex is to add projects — to say yes, to start the new initiative now, to keep everyone "fully utilized." Little's Law shows that every open project taxes the cycle time of every other open project. More WIP, longer waits, for everything. The team feels productive (look at all we're working on!) and ships slower than ever. On Hacker News, one engineer described exactly this in a big org: "everyone is very busy yet unfocused. Too much context switching at all levels, too many works in progress get blocked on waiting for other teams to contribute their part." Busy and blocked are not opposites. High WIP produces both at once.

The second reflex is to add people, and there the per-person cost shows up as context switching. Splitting attention across many open items is not free: the American Psychological Association notes that "even brief mental blocks created by shifting between tasks can cost as much as 40 percent of someone's productive time." So piling more concurrent work onto a person does not raise throughput — it lowers it, which by Little's Law makes cycle time worse, not better. A good lead feels this in their gut. As one wrote: "I try to protect my crew from working on too many different types of projects concurrently because it makes it impossible to really go deep which causes the output to suffer." The fix for a slow team is almost never more. It is less, finished.

And the environment is loud. Microsoft's June 2025 Work Trend Index found that "employees are interrupted every two minutes during core work hours—275 times a day—by meetings, emails, or chats," and that "nearly half of employees (48%)—and more than half of leaders (52%)—say their work feels chaotic and fragmented." That is what a high-WIP system feels like from the inside: not lazy, drowning.

AI is quietly inflating your WIP

There is a 2026 reason this is getting harder, and it follows the same pattern showing up everywhere: AI accelerates the individual while quietly degrading the system. AI is brilliant at helping you start. Draft the doc, spin up the pilot, open the branch, kick off the analysis — the cost of beginning a new piece of work has collapsed. The cost of finishing it has not. So WIP inflates while throughput holds, and Little's Law does the rest: cycle times climb even as everyone feels more productive.

The clearest evidence is the "workslop" research from BetterUp Labs and Stanford, published in Harvard Business Review in September 2025. AI-generated work that looks done but isn't "shifts the burden of the work downstream, requiring the receiver to interpret, correct, or redo the work." The cost is not theoretical: workers spend "an average of one hour and 56 minutes dealing with each instance," an "invisible tax of $186 per month" per person, which "for an organization of 10,000 workers" runs "over $9 million per year." That is WIP by another name — half-finished work handed sideways, still in the system, still in the queue.

It compounds at the org level too. OutSystems' April 2026 State of AI Development report found that "nearly every organization surveyed, 96%, is already using AI agents in some capacity," yet only "12% have implemented a centralized platform to manage sprawl," and "94% of organizations report concern that AI sprawl is increasing complexity, technical debt, and security risk." Started everywhere, finished and governed almost nowhere — a textbook WIP explosion, one pilot at a time. The same engineer who quoted Reinertsen warned that "AI-driven development threatens to increase, not decrease individual engineer utilization," pushing teams straight up the wrong end of that curve.

The defense is to keep finishing visible and starting expensive — to treat an open item as a cost, not a credit. That is partly a tooling choice: when the conversation, the canvas, and the action plan live in one place instead of scattered across tabs, the pile of in-flight work is something the team can actually see and drain, rather than a queue hidden inside fifteen apps. Keeping work and the talk about it together — which is what Coommit is built for — is a way of keeping WIP honest.

Stop starting, start finishing

The remedy is almost embarrassingly simple to state and hard to do, because it means saying no to work you are capable of doing. A few rules that follow directly from Little's Law:

None of this requires anyone to work harder. That is the point — and the part that makes it a tough sell, because it offers no one to blame and nothing heroic to do. Just less in flight, finished sooner.

Conclusion

A slow team is usually not a lazy team. It is an overloaded queue, and queues obey a law. Little's Law says cycle time is work in progress divided by throughput, so the fastest lever you have is almost never to push harder — it is to carry less at once. Kingman's curve says the same thing with teeth: a team run near full capacity isn't a touch slower, it is nineteen times slower to respond, and one bad week from gridlock.

The 2026 twist is that AI makes starting nearly free while finishing stays expensive, so the queue fills faster than ever unless you defend it on purpose. The move is the oldest one in operations and the hardest one in practice: stop starting, start finishing, and leave the team room to breathe. If your team feels slow, do not ask who to push. Ask how much is in flight — and then have the discipline to start less, so you can finish more.