Ask a team how many things are in progress and then ask how many closed in the last two weeks. In organizations that can't answer "when," the first number is large and stable and the second is small and moves around.
That pairing is the diagnosis. It isn't a statement about effort. Everyone in that team is working. It's a statement about how much is open at once, and about what having a lot open does to the time between starting something and finishing it.
Hands-on time and elapsed time aren't the same number
A piece of work has an amount of attention it requires. Call that the hands-on time. It also has an elapsed time, which is how long it takes from start to finish on a calendar.
Those two numbers only look similar when very little is in flight. As more work opens up, elapsed time separates from hands-on time and keeps going, because the work spends most of its life not being touched. It waits for the person who has context to come back to it. It waits for a decision from someone who's mid-way through three other things. It waits at a handoff for the next step to have room.
This is why estimates stop meaning anything under load, and why the team giving them isn't wrong. Two days of hands-on time is an accurate estimate. It just doesn't predict a date, because the date is set by the waiting, and the waiting is set by how much else is open.
It's also why adding a status meeting doesn't help. The information problem is real, but the meeting reports on a system whose elapsed times have become unstable. It doesn't stabilize them.
Context switching charges twice
The cost of moving between partial commitments isn't only the time to reload. It's that each item picks up more handoffs, because a person who can't finish something in one sitting is more likely to pass it along in an incomplete state.
Every one of those handoffs is a place where context gets described rather than held, where something gets dropped, and where the work can sit until the next person has capacity. Work that's reopened after a gap frequently redoes part of what was already done, because the reason a particular choice was made no longer exists anywhere except in someone's memory of a week they've since worked through twice.
None of this shows up as a problem in any individual case. It shows up as elapsed times that no longer correlate with size.
A limit is a local operating rule
The mechanism that makes this manageable is a cap on how much can be open at once. I want to be precise about what a limit is and isn't, because it's frequently installed as a number pulled from an article and then abandoned when it doesn't fit.
There's no correct number. The right limit depends on how much demand arrives, how much capacity exists, how the work is shaped, how many dependencies sit outside the team, and how fast decisions come back. A team with slow external decisions needs a different limit than a team that decides for itself, and the same team needs a different one after a reorganization changes its dependencies. The limit is chosen locally, checked against what actually happens, and adjusted.
What the limit does is force a choice at the moment work starts rather than weeks later. At the cap, starting something new requires that something else finish, pause explicitly, or be displaced. That's the entire mechanism. The number matters much less than whether that choice is real.
Two things need definitions for it to work at all. "Active" has to exclude waiting, or the cap counts things nobody is touching and the whole exercise becomes theater. And a paused item needs to name what it's waiting on and who owns clearing it, or pausing becomes a way of hiding work outside the count.
Breaches are information about the system
When a team goes over its limit repeatedly, the useful reading is that demand, routing, dependencies, or decision speed exceed what the team can carry. It's a measurement, and it's one of the more valuable ones available.
The unhelpful reading, which is common, is that the team lacks discipline. I've never found that to be the cause. People start work because starting is the response available to them when a request arrives and refusing isn't. If someone breaches the limit to take on an urgent request from a senior leader, the limit did its job by making that visible. The next question is about routing, not about the person.
A limit that's never breached is usually set too high to be doing anything.
What it costs
The uncomfortable part isn't the limit. It's what the limit reveals, which is that the organization has committed to more than it can carry and has been managing the gap by keeping things open.
Once the system is full, starting more work does not increase throughput. It increases waiting.