Many systems do not fail during the work.
They fail between people.
The parent says, “I told you about the form.”
The colleague says, “I thought you were handling that.”
The student says, “I showed the tutor, but I did not know what to do next.”
The project says “waiting” because nobody can tell who owns the next move.
The task crossed a boundary.
The state did not travel with it.
Quick Read
In one sentence: a handover contract simplifies life by defining the minimum information, ownership, evidence and next action that must cross a boundary whenever responsibility changes hands.
In safety-critical work, healthcare, aviation, engineering and operations, handoffs are recognised risk points because information can be lost when ownership changes. Standardised handoff structures exist precisely because memory and informal conversation are unreliable carriers of operational state.
Daily life contains the same pattern at smaller scale.
If another person must continue the work, the handover should contain enough state that continuation does not require archaeology.
Handover Contracts Are Different From Ownership
Ownership says who carries the current outcome.
A handover contract says what must happen when ownership changes.
Without a handover contract, ownership can move nominally while the old owner still carries the hidden context.
Handover Contracts Are Different From Runbooks
Runbooks describe how to perform a known procedure.
Handover Contracts describe what state must accompany the transfer into that procedure.
The runbook says how to continue.
The handover contract makes continuation possible.
The Minimum Handover Contract
- Object: what exactly is being handed over?
- Current state: where is it now?
- Outcome: what must happen next?
- Owner: who now carries it?
- Deadline or trigger: when does the next move matter?
- Dependencies: what is it waiting on?
- Evidence: what has already been done or verified?
- Escalation: what condition requires a different route?
Most ordinary handovers need only a subset.
The principle is sufficiency, not bureaucracy.
Node 1: Parent-to-Parent Handovers
Family coordination often fails through half-transfers.
“Can you handle the dentist?”
Handle what?
Book?
Reschedule?
Take the child?
Pay?
Bring the previous report?
A clearer handover is:
The appointment is booked for Tuesday 4 PM. I cannot take her. Please own transport and attendance. The confirmation is in the shared calendar.
Now the transfer has an object, state, owner and evidence.
Node 2: Student-to-Teacher or Tutor Handovers
A student asking for help should hand over enough evidence for diagnosis.
- Question.
- Attempt.
- Where the reasoning stopped.
- What rule or concept the student thought applied.
This is far more useful than:
I don’t understand this.
The handover contract teaches the student to transfer state, not helplessness.
Node 3: Teacher-to-Student Handovers
Feedback also needs a complete transfer.
“Work on algebra” is not enough.
A stronger handover says:
Your main error is expanding negatives across brackets. Correct Questions 3, 5 and 8, then do these two transfer questions tomorrow without notes.
The learner receives state, evidence and next action.
Node 4: Shift and Work Handovers
Work handovers should make unfinished state explicit.
Current state → what changed → what remains → what is blocked → what needs watching → next owner.
This prevents the receiver from repeating completed work or missing a developing risk.
Idempotence benefits because the receiver can tell what must not be executed twice.
Node 5: Handover Between Tools
Digital tools also hand work to one another.
Email becomes task.
Task becomes calendar event.
Form becomes spreadsheet entry.
Automation becomes human review.
Every boundary needs enough metadata to preserve identity and state.
If the task loses its source link, owner or deadline during transfer, the new system has received an object without context.
Node 6: Handover at Exceptions
Escalation is a handover.
When a problem moves to a more capable owner, send:
- what happened;
- what was expected;
- what has been tried;
- what failed;
- current impact;
- what decision or capability is needed.
This makes Escalation efficient instead of merely louder.
Node 7: Handover at Recovery
A system returning from crisis often changes owner again.
Emergency operator hands back to normal operator.
Parent support hands back to child ownership.
Temporary tutor scaffold hands back to independent student execution.
The handback needs the same clarity as the emergency handover.
This protects against temporary support becoming permanent dependency.
Node 8: Handover of Temporary Systems
Temporary arrangements often survive because nobody knows who owns retirement.
A proper handover says:
You own this temporary arrangement until the review date, including either renewal or closure.
This connects with Sunset Rules.
Handover Contracts Need Shared State Names
State Machines become powerful at handovers because both sides can use the same language.
Waiting.
Blocked.
Submitted.
Verified.
Closed.
Shared state names reduce interpretive load.
Handover Contracts Need Acknowledgement
A transfer is not complete because the sender sent it.
The receiving system must accept ownership.
Sent is not handed over. Acknowledged ownership is handed over.
This is particularly important where consequence is high.
The Reverse Test: What Would the Receiver Have to Ask?
Imagine the original owner disappears immediately after the handover.
What would the receiver still need to know?
That missing information belongs in the contract.
The Rotation Test: Does the Sender Think the Handover Is Better Than the Receiver Does?
Senders often optimise for speed.
Receivers pay the reconstruction cost.
A good handover is measured by continuation cost on the receiving side.
The Time Test: Has Ownership Actually Moved?
Some “handovers” leave the old owner chasing, reminding and checking forever.
If the old owner still carries all follow-up responsibility, ownership did not move cleanly.
Handover Contracts for Students
- Show the attempt when asking for help.
- Carry the exact correction back from teacher or tutor.
- Record what is now owned by the student.
- Make the next retrieval or practice action explicit.
- Use one canonical misconception state rather than scattered feedback.
Handover Contracts for Families
- Name the exact outcome being transferred.
- Make dates and documents visible.
- Require acknowledgement for important transfers.
- Do not assume “I mentioned it” transferred ownership.
- Hand temporary support back deliberately when the condition ends.
Handover Contracts for Work
- Current state.
- Next action.
- Owner.
- Deadline.
- Dependencies.
- Evidence.
- Escalation boundary.
- Acknowledgement.
When Handover Contracts Fail
- Too vague: “Please handle this” carries no state.
- No acknowledgement: sender assumes transfer while receiver never accepted it.
- Context dump: too much information hides the next action.
- No deadline: ownership moves but urgency disappears.
- No evidence: completed work gets repeated.
- No escalation: the receiver gets trapped outside their capability.
- Ghost ownership: the old owner still carries the follow-up load.
A Seven-Day Handover Experiment
- Day 1: identify one recurring transfer that creates confusion.
- Day 2: define the object and outcome.
- Day 3: add current state and next action.
- Day 4: add owner and trigger.
- Day 5: require acknowledgement.
- Day 6: ask the receiver what was still unclear.
- Day 7: remove any handover detail that does not reduce continuation cost.
Further Reading and Evidence
- AHRQ resources on structured clinical handoffs and communication reliability.
- WHO patient-safety materials on communication during transitions of care.
- eduKateSG: How to Simplify Life | Runbooks.
- eduKateSG: How to Simplify Life | Ownership.
Final Thought: Responsibility Should Not Travel Alone
When responsibility moves, context must move with it.
A clean handover transfers enough of the past that the next person can build the future without guessing.