When delivery slows down, the first question leaders ask is about people. Are they working hard enough? Do we have the right skills? Should we hire more?
It is a natural question. It is usually the wrong one.
In most teams I work with, the work is not stuck in anyone's hands. It is stuck between them. Waiting for a review. Waiting for a product decision. Waiting for a test environment. Waiting for someone in another team to answer a question in a channel they check twice a day.
The people are busy. The work is waiting.
Busy Is Not the Same as Flowing
Look at any single task from the moment someone starts it to the moment a customer can use it. Then split that time into two parts: time when someone was actively working on it, and time when it was waiting.
Teams that do this honestly for the first time are usually surprised. The active time is often a small fraction of the total. The rest is queues.
This is why adding people rarely helps. If a task spends most of its life waiting, a faster developer saves very little. Adding more developers often makes it worse, because there are now more tasks competing for the same reviewers, the same decision-makers, and the same environments.
You cannot fix a flow problem by making each person busier.
Where the Waiting Hides
Waiting time rarely appears in reports. It hides in a few familiar places.
The Review Queue A change is finished but sits for a day or two before anyone reviews it. Then comments arrive, the author has moved on to something else, and the change waits again. A small fix can take a week to merge without anyone doing anything wrong.
The Decision Gap The developer reaches a point where the specification is unclear. They ask. The product manager is in meetings. The developer guesses, or switches to another task. Either way, something is now waiting or will need rework.
The Shared Environment There is one staging environment, and three teams need it. Testing is scheduled, delayed, and repeated when someone else's change breaks it.
The Cross-Team Dependency The feature needs a small change in a service owned by another team. That team has its own priorities. The request joins their backlog.
The Release Ritual Code is ready, but releases happen on a fixed schedule, or need a specific person to approve them. Finished work waits for the calendar.
None of these is dramatic. Together, they can double or triple the time from idea to customer.
Why Leaders Miss It
Handoff problems are hard to see from above because every individual looks productive. Developers are coding. Reviewers are reviewing. Product managers are in back-to-back meetings. Everyone is at full capacity.
That is exactly the problem. When everyone is fully loaded, there is no slack to pick up waiting work quickly. Queues grow. Full utilisation feels efficient and produces slow delivery.
The metrics most teams track make it worse. Story points, tickets closed, hours logged: all of them measure activity. None of them measures how long work waits.
What Actually Helps
The fixes are usually cheaper than hiring, and faster to show results.
- Measure the wait, not just the work. Track how long tasks spend in each state: in progress, waiting for review, waiting for testing, waiting for release. You do not need a new tool. A week of honest notes is enough to see where the queues are.
- Limit work in progress. Fewer tasks open at once means each one moves faster. It feels slower at first. It is not.
- Make review a priority, not a favour. Agree that reviewing a teammate's change comes before starting new work. A team that finishes together delivers faster than a team where everyone starts alone.
- Put decisions closer to the work. If developers need a product answer several times a day, the product owner needs to be reachable several times a day, or the team needs the authority to decide within clear limits.
- Remove shared bottlenecks. One staging environment for five teams is a queue by design. Temporary environments per change, or better test coverage, remove the wait entirely.
- Release when ready. If releasing is risky, make it safe and small, then do it often. A release schedule that exists to manage fear is a handoff in disguise.
The Question to Ask Instead
Next time delivery feels slow, do not start with "who is not performing?"
Start with "where is the work waiting?"
The answer will usually point to a handoff: between people, between teams, or between a finished change and a customer who can use it. Fix the handoffs, and the same team, with the same people, often delivers noticeably faster.
Not because they work harder. Because the work stops waiting for them.
