Handoff
Why it matters
Each handoff is a chance for work to wait in a queue, lose context or be dropped because each side assumed the other had it. Counter to instinct, the more people and steps a process involves, the more the handoffs, not the tasks, decide how long the work takes and how often it goes wrong. Work often spends most of its time waiting between steps, which is why cycle time is far longer than the hours actually spent working. As a founder starts delegating, handoffs multiply, and every new boundary adds friction.
How to apply it
- Keep related work with one owner wherever you can. Fewer handoffs mean fewer places to fail.
- Give every unavoidable handoff a clear trigger, so both sides agree on the moment work has moved.
- Send the context with the work: decisions made, open questions and where the files are.
- Name one person on the receiving end. Work handed to "the team" is work nobody owns.
- When a process keeps breaking, check the handoffs first. The fault is usually at a boundary, not inside a step.
What it is
A handoff happens whenever responsibility for a piece of work moves: a salesperson passes a signed deal to onboarding, a designer sends files to a developer, a form submission triggers an automation, or one AI agent passes a task to another. Each time, the receiving side has to know that the work has arrived, what has already been done, and that it is now theirs.
Common mistakes
Handing over a task without its history, or announcing a handoff in chat and assuming it has been read. A handoff is complete only when the receiver confirms it.
