Questions we answerProcess and ownership
How do I fix handoff problems?
Work fails at the joins more often than in anyone's hands. Fixing it means agreeing what "ready" means at each boundary — and having someone own the outcome across it.
Free · a few minutes · starts from “Something in the team isn't working”
The short answer
Hand-off failures are usually definitional rather than behavioural: the sending side and the receiving side disagree about what finished means, and both are reasonable. Fix it by writing down, for each boundary, what has to be true before work moves — what is included, in what state, with what information. Then give one person accountability for the outcome across the boundary, not just for their side of it. Adding a coordination meeting instead is the common move and it manages the symptom indefinitely.
Hand-offs are where most avoidable rework is created, and they are unusually easy to fix cheaply — which makes them the best value available in a struggling process.
The reason they fail is rarely carelessness. It is that each side has a different and entirely sensible idea of what the work should look like when it moves, and nobody has ever written either down.
Is it really this?
Worth checking before you spend anything. These are the signals that tend to tell the two apart.
Signs it is
- Work comes back, and it comes back for the same reason each time.
- Both sides can describe what went wrong and each description is reasonable.
- There is a queue or a delay specifically at the boundary.
Signs it's something else
- The work is fine when it moves and the problem is that there is too much of it.
- One side cannot do their part at all, which is capability rather than coordination.
- The rework is caused by requirements changing upstream, not by the hand-off itself.
What's usually behind it
- Two teams with different definitions of done and no shared statement of it.
- Information that exists on the sending side and is never asked for by the receiving side.
- An outcome that nobody owns across the boundary, so both sides optimise their own half.
What people usually get wrong
- Adding a weekly sync, which manages the symptom permanently.
- Writing a long process document nobody reads, instead of a short definition of ready.
- Blaming the receiving side because they are the ones who raise it.
The options, and when each one fits
In no particular order. Which of these fits depends on your situation, not on the question you typed.
Define ready at the boundary
Both sides are reasonable and simply disagree about what finished means.
Give one person the outcome across it
Each side is optimising its own half at the expense of the whole.
Remove the hand-off
The split exists for historical reasons and the work could sit in one place.
When doing nothing is the right call
If the hand-off fails occasionally and is cheap to correct, formalising it may cost more than it saves. The test is repetition: the same failure at the same boundary three times is a process issue, not bad luck.
What the diagnostic asks
- Whether the problem is volume, a missing skill or unclear ownership.
- Who owns the work and how clear that is.
- How much of the process is written down.
- How long it has been happening.
“I don't know” is always an answer. Nothing is assumed on your behalf.
The routes it weighs
Every diagnostic weighs all ten routes. These are the ones that tend to matter for this question — a description of the rules, not a promise about your answer.
Process improvement
Change how the work flows — remove steps, name an owner, fix the hand-offs.
Redistribute
Move ownership of the work to where it fits, and make that explicit.
Develop
Build the capability in someone already in the team, with time and support.
Recruit
Recruit a new person for a durable, sizeable need that is central to the team.
Do nothing yet
Record the issue, set a revisit date, and decide what would change your mind.
What changes the answer
- An undocumented process makes every hand-off a negotiation.
- An owner accountable across the boundary changes the incentives on both sides.
- A genuine skill gap on the receiving side is a different problem with a different answer.
Get your own read
A handful of short questions, then the strongest route for your situation, what's also credible, what we still don't know and what would change our view. No account, no setup.
Related questions
- Projects keep slipping — what should I do?Repeated slippage is information. What matters is where it slips: consistently in the same place is a process problem, everywhere at once is usually over-commitment.
- Who should own this work?Ownership is accountability for an outcome plus the authority to decide. Anything less is a task list with someone's name on it, and it will not hold.
- Quality is slipping in my team. Is it people, process or workload?More often process than people. Slipping quality is usually a sign that the work has outgrown the way it is done, not that anyone has stopped trying.
- Nobody owns this work. What do I do?Give it an owner. That is almost always the first move, and it is faster and cheaper than anything else on the list.
- Is this a process problem or a people problem?More often process than managers expect. If your most capable person would struggle in the same seat, the work is badly shaped. If one person struggles where others do not, the answer is about that person.
- Should I fix the process before hiring?Usually yes, at least far enough to know what the new person would own. It is cheap and quick, and it either removes the need or tells you exactly what to recruit for. It stops being sensible once it becomes a reason never to decide.