A lot of ‘in progress’ work isn’t progressing. It’s waiting for a decision, a review, an approval, or someone with the right knowledge to become available. It looks active on the report. Much of its life is spent sitting still.
When too much work enters the system at once, queues build up behind every decision point, every approval, every person with specialist knowledge. The more loaded the system becomes, the longer those wait times get. That is not a people problem. It is how overloaded systems behave.
Little’s Law makes this precise: the more work you put into a system, the longer each item waits to move through it. The relationship is mathematical. Adding more work in progress doesn’t speed things up. It slows everything down.
You can see it when you look carefully. Work that has been in progress for two weeks has typically received a few hours of real attention. The rest of its life has been spent in a queue, appearing active on a report while barely moving. The team is busy. The work is not.
There is a compounding problem underneath this. When priorities aren’t clear enough to determine what can genuinely wait and what can’t, teams hedge. They keep multiple pieces of work alive rather than making the harder call about what to put down. That adds more into an already loaded system, which lengthens the queues, which extends the wait times further. The system is working exactly as an overloaded system does. The experience from inside it is a team working hard and not making the progress the effort should produce.
Many leaders don’t see this because they read work in progress as work happening. The gap between those two things is where lead times stretch, where commitments get missed, and where teams end up exhausted without a clear sense of what actually moved.
The response that makes things worse is adding more. More people, more process, more urgency. More work entering a system that’s already backed up doesn’t clear the backlog. It lengthens it.
What actually helps is reducing what’s in progress. Not permanently, and not dramatically, but enough to create space in the system. When fewer items are in flight, the queues behind each decision point shorten. Context switching reduces. Work that was technically in progress but functionally parked starts to move again. That space is what allows the real constraints to become visible, which is where the useful work begins.
A useful starting point: pick three pieces of work that have been in progress for more than two weeks and trace where each one actually is. Not where it sits on the board. Where it is right now, and what it’s waiting for. That trace usually surfaces the same two or three bottlenecks repeating across the system, and gives you something specific to act on rather than a general sense that things are slow.
The goal isn’t to push harder. It’s to shorten the wait time. That’s what actually moves work through.
If you want to do that work properly — mapping real flow, identifying the bottlenecks, running the improvement activity — Lean Consulting is where it happens.