Waiting is often treated as a hygiene problem: clear the column, chase the owner, get the number down. That instinct is understandable. A long waiting list looks like a team that is not moving. Sometimes that is true. Often it is incomplete.
A piece of work waits for a reason. A decision has not been made. A dependency sits with another person. Coverage was never named before someone went away. The item is not idle in the abstract — it is paused inside a real operating pattern. If you only count waiting items, you see volume. If you read them, you see how execution actually happens.
Read the wait, not only the count
Three waiting items on one owner is a load problem. Three waiting items that all depend on the same confirmation are a bottleneck. Work that has been waiting for a day is not the same as work that has been waiting for a week. Age, owner, and reason change the meaning of the same status.
- Waiting that clusters on one person is a capacity signal.
- Waiting that clusters on one confirmation is a decision signal.
- Waiting that has no named owner is not waiting. It is abandoned in slow motion.
Teams that hide waiting work do not become faster. They become harder to read. The useful move is to keep waiting in the open, with an owner still attached, so the stall is part of the operational picture rather than a private embarrassment.
Once waiting is visible, the conversation changes. You are no longer asking whether people are busy. You are asking which waits are decisions, which are capacity, and which are simply work that no longer has an owner.