Handoffs, Queues and Dependencies
Every transfer between people or teams adds delay and loses context. Counting them is a quick diagnostic.
Work passed from one party to another waits, and arrives with less context than it left. Both costs are predictable and neither appears in productivity figures.
The process issue in “Handoffs, Queues and Dependencies” is easier to diagnose when effort can be connected to projects without confusing activity with value. Used for internal transfer policy, see how the platform works can add time and workflow context, while the process outcome remains the source of truth for whether the system improved.
What a handoff costs
Queue time at the receiving end, which is usually the larger part of lead time.
For an independent perspective related to “Handoffs, Queues and Dependencies”, consult the Atlassian Team Playbook; it offers a useful external check on definitions, governance and the assumptions built into a proposed measure.
Context loss: the receiver knows less than the sender did.
Rework, when the missing context causes a wrong assumption.
And a question going back, which doubles the delay.
Counting them
Walk one process and count the transfers between people or teams.
Most organisations find more than expected, including ones that exist for historical reasons.
Each is a candidate for removal, and removing one is usually worth more than speeding up a step.
The specialist handoff
Work goes to a specialist for one small part and waits in their queue for days.
Frequently the part could be done by the sender with a short rule or a template.
Which converts a multi-day wait into five minutes, and is the highest-return handoff removal available in most processes.
Dependencies between teams
Team A cannot finish without team B, whose priorities differ.
This is where the longest waits live, because neither team's own measures capture it.
Both look productive; the work sits between them, which is exactly what end-to-end measurement reveals and what team-level measurement hides.
The approval handoff
Its own note covers approvals specifically.
The short version: most are a transfer to somebody who will say yes, and the delay is the whole of the cost.
What to do
Remove the handoff, where possible: give the sender the authority or the capability.
Batch less, so work does not wait for a weekly run.
Make the queue visible to both sides, which changes behaviour without any process change.
And establish a service expectation between teams, which is the minimum where the handoff must stay.
Measuring the cost
Time in queue at each handoff, as a share of lead time.
Rework attributable to context loss, where you record causes.
The first number alone usually makes the case, because it is frequently most of the elapsed time.
The counter-case
Some handoffs exist for good reason: segregation of duties, specialist judgement, safety checks.
Keep them and measure them, so the cost is known and accepted rather than invisible.
What to check
How many handoffs are in your main process?
Which queue is longest?
Is work waiting between two teams who both look busy?
And does each necessary handoff have a service expectation?