A surprising amount of work fails in the space between two people.
Or two systems.
Or two stages of a process.
The first person finishes their part.
The second person begins theirs.
Somewhere between those two moments, context disappears.
A file is attached without explanation.
A ticket changes status.
A developer says, “It is ready.”
A report enters review.
A deployment is handed to operations.
A request moves from one department to another.
Everyone technically did their part.
And yet the next person still has to ask:
What exactly happened?
What is complete?
What remains?
What should I check?
What decision was already made?
What am I expected to do now?
The task may have been performed well.
The handoff was not.
That distinction matters because many workflows are designed around individual activities while treating transitions as administrative details.
In reality, transitions are part of the work.
A Handoff Is an Interface
Software engineers spend enormous effort designing interfaces between systems.
We define request formats.
Required fields.
Expected responses.
Error states.
Version contracts.
Authentication.
Retries.
Compatibility.
We know that if two systems communicate through an ambiguous interface, failures will appear quickly.
Human workflows deserve the same discipline.
A handoff between two people is also an interface.
So is a transition from development to QA.
From authoring to publishing.
From research to decision-making.
From sales to implementation.
From one automated service to another.
Whenever responsibility crosses a boundary, information must cross with it.
If that information is incomplete, the receiving side has to reconstruct the missing state.
That reconstruction is expensive.
“Done” Is Usually Not Enough
Imagine a developer finishes a task and writes:
Done.
What does that mean?
Code written?
Code reviewed?
Tests passed?
Merged?
Deployed?
Verified in production?
Ready for QA?
Blocked only by external configuration?
“Done” may be perfectly clear to the person who wrote it.
It may be nearly useless to the next person.
The same problem appears outside software.
A document is “ready.”
Ready for review?
Ready for signature?
Ready for publication?
Ready except for one missing attachment?
A handoff should define what the completion state actually means.
The receiving side should not have to reverse-engineer it.
Good Handoffs Preserve State
Yesterday’s article explored the idea that unconfirmed is a real state.
That principle extends naturally to handoffs.
A handoff should preserve enough state that the receiver knows where the work currently stands.
For example:
Completed: implementation and automated tests.
Verified: development environment only.
Pending: production configuration.
Known issue: one legacy browser remains untested.
Next action: QA validates the workflow using test case X.
Now the transition has structure.
The next person is not merely receiving an artifact.
They are receiving a state.
This is much more useful.
Ownership Must Move Explicitly
One of the most common workflow failures is ambiguous ownership.
Person A finishes their part.
Person B is expected to continue.
But nobody clearly states that responsibility has moved.
Now both may assume the other person owns the next step.
Or both may act simultaneously.
Or the task quietly waits.
The handoff should answer:
Who owns the next move?
This sounds obvious.
It is often missing.
Consider:
The fix is ready for QA.
Better:
The fix is ready for QA. QA now owns verification against the three acceptance cases below.
Now responsibility has crossed the boundary explicitly.
The task does not merely have a new status.
It has a new owner and a defined expectation.
Status Is Not Ownership
Workflow tools often confuse these ideas.
A task moves to:
Ready for Review
The system assumes the transition is self-explanatory.
But status tells us where the work is.
Ownership tells us who must act.
Those are different dimensions.
A task can be “Ready for Review” while no reviewer is assigned.
It can remain there for days.
Nothing is technically wrong with the status.
The workflow is still stalled.
This is why mature systems often need both:
state
and
responsibility.
State answers:
Where is this work?
Responsibility answers:
Who is expected to move it?
A good handoff makes both visible.
The Receiver Needs Context, Not History
There is another trap.
When someone asks for context, we send them everything.
Ten messages.
A long email thread.
A ticket with forty comments.
Three documents.
A meeting recording.
Technically, the information is available.
Practically, we have transferred the burden of interpretation.
A useful handoff does not dump history.
It compresses history.
The receiver should get the smallest amount of information that allows them to continue safely.
Perhaps:
What changed.
Why it changed.
Current state.
Important constraints.
Known risks.
Next action.
Links to deeper evidence if needed.
That is different from saying:
Everything is in the thread.
A thread is an archive.
A handoff is an operational summary.
The Best Handoff Reduces Questions
A useful way to judge a handoff is by what happens immediately afterward.
If the receiver needs to ask five questions before starting, the handoff was incomplete.
If they can begin confidently, it was probably good.
This does not mean eliminating all conversation.
Some work is inherently collaborative.
But routine transitions should not require repeated clarification.
A well-designed handoff removes predictable questions before they are asked.
For example:
Instead of:
Please review the report.
Try:
Please review the report for calculation accuracy and column alignment. The data source has already been verified. The only unresolved issue is the date-range behavior described in item 3.
The review becomes much more focused.
Define What the Receiver Should Verify
A handoff is stronger when the receiver knows what is expected of them.
Consider QA.
A developer says:
Ready for testing.
Testing what?
The entire feature?
One bug?
Regression behavior?
Performance?
Permissions?
Edge cases?
A strong handoff includes the acceptance boundary.
For example:
Verify that scheduling accepts future dates, immediate publishing remains unchanged, and repeated submissions do not create duplicate jobs.
Now QA knows the intended contract.
The developer has converted implementation into testable behavior.
That is an important transformation.
Handoffs Should Carry Evidence
Claims are useful.
Evidence is better.
Suppose someone says:
Deployment succeeded.
A stronger handoff might include:
deployment version,
commit SHA,
environment,
verification result,
health check,
and rollback point.
Not because every deployment needs bureaucratic ceremony.
Because evidence reduces uncertainty.
Similarly:
The database migration completed successfully. Schema version is now 18.4.2, row count matches the pre-migration expectation, and rollback package is preserved at revision 18.4.1.
Now the receiving operator knows much more than “it worked.”
Evidence makes the state inspectable.
The Handoff Should Preserve Why
This connects directly to the earlier article on decision trails.
Suppose a feature moves from architecture to implementation.
If the implementation team receives only:
Build this endpoint.
they may make reasonable local decisions that violate the original intent.
Perhaps the endpoint must remain read-only because another system owns the data.
Perhaps one parameter must remain nullable for backward compatibility.
Perhaps caching was explicitly rejected because freshness matters more than latency.
Those decisions belong in the handoff.
Not every discussion needs to travel.
The important reasoning does.
A good handoff preserves the constraints that shape the work.
Avoid Hidden Knowledge
Many fragile teams rely on invisible context.
One person “just knows” which server to restart.
Another person remembers the unusual deployment sequence.
Someone else knows that a field must remain empty for one legacy integration.
The workflow appears simple because complexity lives inside people.
Then someone is unavailable.
The system suddenly becomes difficult.
This is not merely a documentation problem.
It is a handoff problem.
If work depends on knowledge that cannot cross the boundary to another person, the process is not resilient.
The knowledge does not need to become a giant manual.
It needs to become transferable.
Handoffs Are Where Bus Factor Appears
Teams sometimes talk about “bus factor,” the number of people whose absence would seriously disrupt a project.
The concept can sound abstract until you examine handoffs.
Can another person deploy the system?
Can another person understand the current release state?
Can another person continue the investigation?
Can another person recover from a failed job?
Can another person understand why a particular architectural constraint exists?
If not, the issue is not simply that one person knows too much.
The workflow has failed to externalize enough state for responsibility to move.
Good handoffs gradually increase organizational resilience.
They make knowledge portable.
The Same Principle Applies Between Systems
The handoff problem is equally important in software architecture.
Imagine System A sends data to System B.
System A says:
Sent.
System B says:
Nothing received.
What happened?
Without a shared transaction identity, the systems have no common reference.
Now imagine every transfer carries:
a unique operation ID,
source revision,
timestamp,
schema version,
and expected acknowledgement.
The handoff becomes observable.
Both systems can talk about the same event.
This is the machine version of a good human handoff.
The principles are remarkably similar:
identity,
state,
ownership,
acknowledgement,
and evidence.
Contracts Reduce Ambiguity
APIs work well when their contracts are explicit.
Human workflows benefit from contracts too.
Not legal contracts.
Operational ones.
For example:
Authoring → Review
Authoring provides:
- completed draft,expected publication date.
- intended audience,
- unresolved questions,
- source references,
Review provides:
- approval,
- requested changes,
- or rejection with reason.
Now both sides know what the transition means.
This can be lightweight.
The purpose is not bureaucracy.
The purpose is predictable exchange.
Design the Failure Path Too
Most workflow diagrams show successful movement.
Draft → Review → Approved → Published.
What happens when review fails?
What happens when the reviewer finds conflicting information?
What happens when publication succeeds but notification fails?
What happens when the required approver is unavailable?
What happens when the receiving system rejects the payload?
The handoff needs failure semantics.
For example:
If review identifies factual uncertainty, return the item to authoring with a specific question.
If publication status is unconfirmed, verify authoritative state before retrying.
If the owner is unavailable for more than two days, transfer responsibility to the designated backup.
These rules prevent exceptional states from becoming improvisation.
Return Paths Are Part of the Handoff
A workflow is rarely a straight line.
Review sends work back.
Testing exposes bugs.
Production reveals behavior missed in staging.
A supplier rejects a request.
A document requires revision.
Return paths should be intentional.
A weak return says:
Please fix.
A stronger return says:
Verification failed because the calculation excludes records with null discharge dates. Expected behavior is documented in acceptance case 4. Returning to development.
Now the original owner knows:
what failed,
why,
and what condition will allow the work to move forward again.
The workflow maintains continuity.
Avoid Handoff Ping-Pong
Poorly defined boundaries create ping-pong.
Team A sends something to Team B.
Team B says it belongs to Team C.
Team C returns it to Team A for clarification.
The object moves.
Progress does not.
This is often a sign that responsibility boundaries are unclear.
A better workflow identifies:
who owns the decision,
who provides information,
who executes,
who verifies.
These roles do not always need formal RACI matrices or complex governance.
Sometimes a sentence is enough.
But someone should know where authority sits.
The Last Person Should Prepare the Next Person
There is a useful mental model:
Finishing your part includes preparing the next person to begin theirs.
That changes the definition of done.
A developer is not fully finished when the code works locally.
They are finished when the next stage has what it needs.
An analyst is not finished when the spreadsheet is complete.
They are finished when the decision-maker can understand what the numbers mean.
An author is not finished when the draft exists.
They are finished when the reviewer knows what kind of review is required.
This does not mean doing the next person’s job.
It means completing the interface between jobs.
Small Handoff Templates Can Help
Templates are useful when transitions repeat.
For example:
Current state:
Implementation complete and merged.
Evidence:
Tests: 42/42 passed.
Build: release-20260928.3
Known limitations:
Not yet verified under low-bandwidth conditions.
Next owner:
QA.
Next action:
Run acceptance cases 1–5.
Return condition:
Any failure that changes persisted state should return to development with reproduction steps.
This is not a report.
It is a packet of continuity.
If a handoff happens often, designing a small reusable format can remove a surprising amount of friction.
Automation Can Produce Better Handoffs
Workflow systems can help by generating some handoff information automatically.
When a deployment completes, the system can attach:
version,
environment,
timestamp,
test result,
and health status.
When a document moves to review, the system can preserve:
revision,
author,
changes since last review,
and unresolved comments.
When a background job finishes, the system can expose:
input version,
execution status,
output artifact,
and failure reason.
This is a good use of automation.
Not replacing judgment.
Reducing the clerical work required to preserve state.
Do Not Make the Receiver Reconstruct the Past
This principle captures most of the article.
When work crosses a boundary, the receiver should not need to reconstruct the past in order to continue the future.
They should not have to search a chat history to learn the latest decision.
They should not have to compare files manually to discover what changed.
They should not have to ask whether deployment actually happened.
They should not have to guess who owns the next step.
They should not have to infer which issue remains unresolved.
Good handoffs reduce reconstruction.
That is their job.
Handoffs Matter More Under Interruption
This series has returned repeatedly to unstable conditions.
Interrupted work.
Uncertain saves.
Missing information.
Changing priorities.
Handoffs become even more important in those environments.
If work can be interrupted at any time, every transition may become the point where someone else needs to continue.
The handoff is no longer merely collaborative etiquette.
It becomes resilience infrastructure.
A good handoff allows the work to survive a change of:
person,
device,
time,
location,
system,
or responsibility.
That is powerful.
A Workflow Is a Chain of Handoffs
We often describe workflows as sequences of tasks.
Task A.
Task B.
Task C.
But another perspective is more revealing.
A workflow is a sequence of state transitions.
A produces something B can use.
B transforms it into something C can use.
C creates the next state.
From this perspective, the quality of the workflow depends heavily on the interfaces between stages.
Excellent tasks connected by weak handoffs still produce a fragile process.
This is true in software architecture.
It is true in project management.
It is true in publishing.
It is true in research.
It is true in ordinary life.
The Handoff Is Part of the Product
Think about a good delivery experience.
The package arrives.
It is clearly identified.
Nothing is missing.
The recipient knows what it contains.
Instructions are present if needed.
The transfer is confirmed.
That is not separate from the product experience.
It is part of it.
The same is true of work.
A good artifact poorly handed off is incomplete.
A good solution with no operational context is incomplete.
A decision that cannot travel to the people implementing it is incomplete.
The boundary deserves design.
Build Continuity Into the Transition
The recent articles in Building What Matters have focused on preserving meaning through real-world complexity.
We kept decision trails.
We favored improvements that can survive.
We recognized that an operation can be unconfirmed without being failed.
Today adds another piece:
progress should survive the moment responsibility changes hands.
That requires more than transferring files.
Preserve state.
Preserve intent.
Preserve important constraints.
Name the next owner.
Define the next action.
Attach evidence.
Make failure and return paths explicit.
Do not force the receiver to reconstruct what the sender already knows.
The work itself matters.
But work rarely exists alone.
It passes between people, systems, stages, and days.
Every one of those transitions is an opportunity either to preserve momentum or lose it.
Design the handoff carefully.
Because sometimes the weakest part of a workflow is not where the work happens.
It is the few centimeters of empty space between one pair of hands and the next.