Your team has a packed calendar. Everyone is booked solid, the project tracker shows twenty active items, and nobody has a free afternoon. Yet when the quarter ends, only a handful of things have actually shipped. Customers are still waiting, and leaders are wondering where all that effort went.

It looks like a paradox, but it isn't. A team juggling twenty projects usually finishes fewer of them than a team focused on five. The reason comes down to simple queue logic, the same math that governs the line at a coffee shop. Once you see it, a full schedule stops looking like proof of productivity, and you start asking a better question: what are we actually finishing?

Picture a coffee shop with one barista who makes one drink per minute. If three people are ahead of you, you wait about three minutes. If fifteen are ahead, you wait about fifteen. The barista isn't working any slower. The line is simply longer, and every order in it has to wait its turn.

This relationship has a name: Little's Law. In plain terms, the average time an item spends in a system equals the amount of work in the system divided by how fast the system completes work. Managers call that amount of unfinished work work in progress, or WIP. If your team finishes two projects a month and has twenty underway, the average project will take around ten months from start to finish.

Notice what doesn't appear in that equation: effort. Adding more projects doesn't make the team faster. It only makes the line longer. Every new project you start pushes back the finish date of everything already in the queue, even if nobody notices it happening. Most managers approve new work one request at a time, so they never see the full line forming behind the counter.

Takeaway

Starting a project doesn't move it closer to done; it just joins the line. If you want work to finish faster, shorten the line before you try to speed up the barista.

The coffee shop analogy actually flatters most teams. A barista finishes one drink before starting the next. Knowledge workers rarely do. They answer an email about Project A, join a meeting on Project B, then try to pick up Project C where they left off yesterday.

Each jump carries hidden costs. There's ramp-up time, the minutes spent remembering where you were and what you planned to do next. There's lost context, the detail that slipped away while you were elsewhere and now has to be rediscovered or, worse, gets missed entirely. The software consultant Gerald Weinberg estimated that every additional project a person juggles eats a meaningful share of their time in switching overhead alone. You don't need to accept his exact figures to recognize the pattern from your own week.

Then there's the biggest cost of all. Half-finished work delivers no value. A product feature that is 80 percent built can't be sold. A hiring plan that is mostly drafted fills no seats. Ten projects at half completion look impressive on a status report, but customers can't use any of them. Spread attention thin enough and everything moves, but nothing arrives.

Takeaway

Value only arrives when work is finished, not when it's started. Five completed projects are worth more than ten that are halfway there.

The fix sounds almost too simple: put a limit on how much work can be in progress at once. Toyota made this idea famous with its kanban system, where new work only enters production when there is capacity to handle it. Software teams adopted the same principle and gave it a memorable phrase: stop starting, start finishing.

You don't need special tools to try it. Pick a rule your team can remember. No new project begins until one ships. Each person owns no more than two active tasks. Anything new goes into a visible backlog instead of straight onto someone's plate. With fewer items moving, the board becomes readable, and everyone can see what's done, what's stuck, and why. Expect some discomfort at first, because idle hands feel wrong even when the system is working better.

That visibility is the real gift. When teams are overloaded, busyness hides problems. A blocked project just sits quietly while people work on something else. Limit WIP, and the blockage becomes obvious, because work stops flowing until someone deals with it. A slow approval process, an overloaded specialist, unclear priorities: these finally surface where leaders can fix them.

Takeaway

A WIP limit is less a productivity trick than a diagnostic tool. When work stops flowing, it shows you exactly where the system is broken.

Peter Drucker warned that nothing is quite so useless as doing efficiently what should not be done at all. Busy teams often fall into a version of that trap: efficiently starting work that won't be finished for months.

The practical framework is simple. Count what's in progress. Divide by what you finish each month to see your real lead time. Then set a limit and protect it. Measure success by what ships, not by how full the calendar looks.