There is a moment every engineering manager knows. A feature was supposed to take two weeks. It's been four. The engineer is not slacking off — they're working hard. The problem is invisible: the work keeps stopping.
It stops waiting for a product decision. It stops waiting for design review. It stops waiting for another team to finish their part. It stops waiting for QA. It stops waiting for a meeting that keeps getting rescheduled. It stops waiting for someone to approve the release. The work touches active time for maybe eight hours across those four weeks. The rest is waiting.
This is not an edge case. This is the default condition of most product teams.
Little's Law and What It Means in Practice
John Little's Law is simple: the average number of items in a queue equals the average arrival rate times the average time in the system.
In plain English: if you have a lot of work sitting around (high WIP) and you're not finishing it proportionally faster, your cycle time goes up. More items in flight doesn't mean more gets done — it means things wait longer.
This is why adding people to a late project makes it later. You increase WIP, which increases queue length, which increases wait time. The new people aren't immediately productive — they're adding load before they can add output. The cycle time for everything gets worse.
The teams that ship fastest are usually not the teams with the most people working the hardest. They're the teams with the lowest WIP and the shortest queues.
What the Fast Teams Do Differently
The teams with the best shipping velocity share one characteristic above all others: they treat waiting as a failure condition, not a normal state.
That sounds aggressive. What it means in practice:
They can see where work is queued. They have enough visibility into the system to know when something has been waiting too long. Not a full project management suite — just a clear signal that work in "design review" has been there for six days and that's longer than usual.
They have explicit escalation for blocked work. When something is waiting on a decision, there's a named person and a time bound. "If we don't have an answer by Thursday, we escalate to X" — not as a punishment, but as a mechanism to prevent indefinite deferral.
They limit WIP deliberately. Not because they're philosophically opposed to multitasking, but because they know that more work in flight means longer wait times for everything. They push back on adding new work until existing work is closer to done.
They reduce the number of handoff points. They co-locate decisions, combine reviews, and create shared contexts so that work doesn't have to fully stop and restart between functions.
None of this is revolutionary. All of it is rarely done consistently.
