Where does work actually wait?
Improving individual productivity does not necessarily improve the overall flow of value.
Most organisations are good at measuring how busy people are. Very few can tell you how long a piece of work spends waiting for someone to be free to look at it.
Those two numbers are not the same thing, and the second one usually matters more.
When a piece of work takes six weeks to reach a user, it is tempting to look for the person or team who was slow. Follow the work closely, though, and a different picture tends to appear. A few days of genuine effort are scattered through those six weeks. The rest is waiting: for a ticket to be prioritised, for a dependency to be released, for a review, for an environment, for an approval, for the next planning cycle to come round.
Activity and flow are different measures. Activity asks whether people are busy. Utilisation asks how fully their time is booked. Flow asks how quickly and how predictably value moves from a request to an outcome. An organisation can be very busy, very fully utilised, and very slow all at the same time. In fact high utilisation is one of the most reliable ways to create queues, because a fully booked team has no spare capacity to absorb the next request without making something else wait.
The waits are easy to miss because nobody owns them. A handoff between two teams belongs to neither. An approval gate looks like diligence from the inside. A dependency on a shared platform team is simply “how things are done here”. Each one is locally reasonable. Together they can account for most of the elapsed time, and they rarely show up on anyone’s dashboard.
What to look for
Queues form wherever work arrives faster than it can be taken on. Dependencies create waits whenever one team needs something from another before it can continue. Handoffs lose context as well as time, so the work often comes back with questions. Approval gates batch decisions into meetings that happen on a calendar rather than when the work is ready. Coordination delays appear whenever several people need to agree on the same thing at the same time.
None of these is a sign of bad people. They are properties of the structure the work has to pass through, which means they can be changed by changing the structure rather than by asking individuals to try harder.
Noticing where work waits is the first step. Once you can see the waits, you can start asking why the structure produces them, and which ones are worth the effort to shorten.
If you could remove only one of those waits, which would change the end-to-end time the most — and who would need to agree to it?
The answer is rarely the longest wait. It is often the one that causes the most re-work or re-planning downstream.
Rich Allen
Rich Allen is a UK-based sociotechnical architecture consultant. He helps organisations improve the flow of value through people, teams, technology and organisational structure. He is the author of User Needs Mapping: Aligning Teams Around What Matters, a long-standing Team Topologies Valued Practitioner and the creator of the Fast Flow Toolkit.
He works with engineering and product leaders to make the flow of work visible and to change team boundaries on evidence. Flow Awareness Sessions are a low-commitment place to start.
Have a question worth exploring together?
Sometimes an outside perspective helps make a difficult organisational problem clearer. If one of these questions resonates, I’d be happy to explore it with you.