It is Friday afternoon, and you are finally finished.
You attach the file, add a short message—“For your action”—and press Send. The task comes off your list. You close the tabs that have been open all week and turn your attention to whatever comes next.
On Monday morning, the replies begin.
“Which version should I use?”
“Has the client approved this already?”
“Am I supposed to send this, or are you?”
“What did you agree on during the last call?”
“Why did we choose Option B?”
You thought you handed over the work.
What you actually handed over was the work plus the job of reconstructing everything you already knew.
That is the hidden cost of a weak handoff. One person experiences completion while the next person experiences confusion, delay, and work that should not have needed to happen again.
Sending something is not the same as handing it over
This becomes especially important once you start looking beyond your own assigned task.
In Turn Assigned Tasks Into Visible Value, the move was to ask what the assignment is supposed to make possible after it leaves your hands. A handoff is where that question becomes real.
Your part may genuinely be finished. But the larger work often is not.
The salesperson closes the agreement, and the delivery team has to fulfill it. The analyst completes the report, and the manager has to make a decision from it. One project member finishes a component, and another must build the next piece. A supervisor goes on leave, and somebody else has to keep the work moving while she is away.
In each case, responsibility crosses a boundary.
A file may cross with it.
A usable understanding may not.
A handoff is not the transfer of a file. It is the transfer of responsibility in a usable state.
You sent the file. You did not send your memory.
One reason weak handoffs happen is that the sender has been living inside the work.
You remember the meetings. You know which alternatives were rejected. You remember why the customer hesitated, which number is still provisional, what the boss said was non-negotiable, and which small issue could become serious if nobody watches it.
None of that feels like “context” to you anymore.
It feels obvious.
Then another person opens the file.
They were not in the meeting.
They did not hear the client say, “This date matters more than the price.”
They do not know that Version 6 is actually final even though Version 7 exists because somebody experimented with another layout.
They cannot see why you chose one approach over another unless the reasoning survived somewhere outside your head.
This is one of the traps of expertise. The more familiar you are with the work, the easier it is to underestimate what somebody else cannot see.
What feels unnecessary to explain may be exactly what the next person needs to continue intelligently.
A weak handoff makes people pay twice
Suppose you spent three hours understanding a customer problem.
You talked with the client, checked previous correspondence, clarified the constraints, explored two options, and finally reached agreement on what should happen next.
Then you hand the account to somebody else with the message:
“Please handle.”
The new person now starts asking the same questions you already answered.
They read old emails. They try to infer which option was accepted. They schedule another call because they are not confident enough to proceed.
The organization has already paid for the thinking once.
Now it is paying again.
This happens in small ways every day. A colleague searches ten messages to find the decision somebody could have stated in one sentence. A replacement employee spends two hours figuring out a process the departing employee understood perfectly. A delivery team discovers midway through the project that the salesperson promised something that never appeared in the handoff.
The cost is not only time.
Weak handoffs create hesitation. They create avoidable errors. They blur ownership. They keep experts permanently involved because nobody else has enough context to act confidently.
Sometimes they create blame.
“I thought you were doing that.”
“I thought it was already approved.”
“Nobody told me the client expected Friday.”
The work did not fail because nobody cared.
Responsibility became blurry while crossing from one person to another.
A strong handoff does not mean explaining everything
The answer is not to send the next person your entire history of the project.
More information can make a handoff worse.
Twenty forwarded emails are not necessarily context. A forty-page document may contain the answer and still leave the receiver unable to find it. A two-hour briefing can bury the two decisions that actually matter.
A good handoff transfers the state of the work.
What can the next person safely treat as finished?
What is still unresolved?
What must happen next?
Who owns that move now?
What standard, promise, risk, or constraint should guide the decision?
That is very different from giving somebody everything you know.
The goal is not information transfer for its own sake.
The goal is continuity.
Leave them ready to continue
Before responsibility changes hands, answer four questions.
What is done?
Be clear about what the next person can treat as complete.
“The proposal is done” may still be too vague. Has the client approved it? Has pricing been confirmed? Is this the final version? Has the internal review happened?
State the usable result.
What is still open?
Do not hide uncertainty inside a polished handoff.
Perhaps the customer agreed to the scope but has not confirmed the date. A number still needs verification. One dependency could delay the next phase. The legal team has not yet approved a clause.
Open work is not a failure.
Invisible open work is dangerous.
What happens next—and who owns it?
“For your information” is not ownership.
Neither is copying five people into an email and hoping one of them understands that they are now responsible.
Name the next move and the owner clearly enough that nobody has to infer the transfer.
“The next step is to confirm the August 24 schedule with the client. Ana owns that confirmation by Tuesday.”
Now responsibility has somewhere to land.
What does good look like?
The next person may know what to do and still not know what matters most.
What promise must be protected? What standard determines whether the work is acceptable? What source should they rely on? What limitation should they not accidentally remove?
Sometimes one sentence is enough:
“The client cares most about having supervisors practise the conversations, so do not replace the role-play block if the schedule has to be shortened.”
That is not extra documentation.
That is judgment traveling with the work.
Consider the salesperson who has already won
A salesperson closes a new client.
From her perspective, the difficult work is done. She understands why the client bought, what almost stopped the sale, which outcome matters most to the decision-maker, and what expectation finally made them say yes.
Then the delivery team receives the contract.
The contract contains the price, dates, scope, and formal deliverables. Everything appears complete.
But the team does not know that the client is particularly worried because a previous provider cancelled twice. They do not know that punctuality became a major reason the client chose this company. They do not know that the executive sponsor said, “I can tolerate changes in content. I cannot tolerate another late start.”
Nobody lied.
Nothing important was missing from the contract as a contract.
But something critical was missing from the handoff.
The delivery team received the transaction.
They did not receive the meaning behind one of the promises.
A strong handoff would not require forwarding every sales conversation. It would preserve the piece of context that changes how the next team should behave.
That is what continuity requires.
Do not use handoff as another word for escape
There is a necessary boundary here.
Making the handoff part of the work does not mean you can transfer unfinished responsibility whenever the work becomes inconvenient.
“I handed it over” is not the same as “I completed my promise.”
That distinction matters because Finish What You Start owns another part of this problem. If you agreed to produce the final draft, sending a half-finished draft to someone else does not make it finished. If the unresolved issue is still yours to settle, identifying it in the handoff does not automatically transfer responsibility.
A clean handoff requires honesty about where your promise ends and another person’s begins.
Sometimes your part is genuinely complete.
Sometimes the responsible move is to say:
“This is not ready to hand over yet. I still owe you one decision.”
That can protect the next person from inheriting work they never agreed to own.
Make sure responsibility actually crossed
For routine, low-risk work, sending the handoff may be enough.
For important work, transfer sometimes needs acknowledgment.
If a project depends on somebody taking ownership, do not assume that because their name appeared in the email they understood the responsibility had shifted. They may believe you are still leading it. They may be away. They may disagree with the deadline. They may lack something necessary to proceed.
A simple confirmation can prevent days of drift:
“You own the customer confirmation from here. Do you have what you need to move?”
The point is not bureaucracy.
It is shared reality.
A responsibility has not fully changed hands if the sender believes the transfer happened and the receiver does not.
The best questions after a handoff are different questions
A strong handoff will not eliminate conversation.
Nor should it.
The next person may challenge your assumption. They may see a better option. They may need to exercise judgment in a situation that has changed since you handed it over.
Those are useful questions.
What you want to reduce are the questions caused by information that should already have crossed the boundary.
Not:
“Which file?”
But perhaps:
“Given what changed yesterday, should we still use this approach?”
Not:
“What did the client actually ask for?”
But:
“If the client now wants both outcomes, which one should we protect first?”
Good handoffs do not eliminate thinking.
They allow the next person’s thinking to begin farther forward.
Your work should travel farther than your memory
This is where handoff becomes more than an administrative skill.
If every useful piece of work requires you to remain beside it forever, your contribution has a very short range.
The project still depends on your memory. The customer relationship still depends on your presence. The decision still depends on you explaining what happened before. Other people may hold the files, but you still hold the work together.
A strong handoff loosens that dependence.
Another person can continue. They can make a judgment. They can improve what you started. They can take the responsibility somewhere you no longer need to go.
That does not make you less valuable.
It means your work has become more useful than your personal availability.
So before you press Send and remove the task from your list, look across the boundary.
Does the next person know what is done?
What remains open?
What they own now?
What matters enough to protect?
Can they begin from where you stopped—or will they have to return to where you began and reconstruct the path for themselves?
Your work matters more when the next person can continue from where you stopped instead of starting again from where you began.
The next article asks a different question. Once the work itself reaches completion, how do you close it with evidence of what actually happened rather than merely reporting what the team did? Continue with Finish With Proof, Not a Progress Report.