The short version
- Most handoffs are status updates dressed up as handoffs. A declared handoff transfers state, not information.
- The difference: a status update describes what happened. A declared handoff tells the next person exactly what to do next — and gives them the authority to do it.
- A complete declared handoff has five parts: current state, blockers with owners, decisions made, next actions with explicit ownership, and ETA back.
- Each section is doing work. Skipping any one of them creates a predictable failure mode.
Most distributed teams have a handoff practice. Engineers post updates before logging off. Tickets get comments. Slack messages say "heading out, picking this up tomorrow." Teams treat this as handoff infrastructure. It is not.
What they have is status updates — information about what happened, formatted for someone who was present and needs a summary. What they need is declared handoffs — state transfers formatted for someone who was not present and needs to act.
The distinction sounds subtle. The operational difference is 30 to 45 minutes of morning context reconstruction per engineer per day, or 5 minutes. Teams that have not made this distinction explicit are paying the higher cost every morning, in every timezone.
What a Declared Handoff Actually Is
A declared handoff is a structured transfer of working state from one engineer — or one shift — to the next, made explicit and complete before the outgoing person goes offline.
The word "declared" does the work. Declarations are explicit: they say something directly, not by implication. They are timestamped: the incoming engineer knows when the state was current. And they are attributed: there is a person who declared this, who can be contacted if the incoming engineer has a question the declaration does not cover.
The word "state" also matters. State is different from information. Information is data — the commit was pushed, the ticket was updated, the PR was opened. State is context — the commit fixed the rate limit issue but introduced a new edge case in the token refresh flow, the ticket is blocked by an external dependency that Alex owns, the PR is ready for review but should not be merged until the load test passes. State is what allows the next person to act. Information is what allows the next person to read.
How It Differs from a Standup and a Status Update
| Standup | Status update | Declared handoff | |
|---|---|---|---|
| Question answered | What did you do? | Where does this stand? | What does the next person need to do? |
| Time orientation | Retrospective | Present-state snapshot | Forward-looking + actionable |
| Audience | Team / manager | Stakeholders | The next engineer who touches this |
| Explicit ownership | Implied | Sometimes | Required |
| Decision record | Not covered | Not covered | Required |
| Enables async action | No | Sometimes | Yes, by design |
The Five-Part Format
Part 1: Current state. A description of where the active work stands right now — not a history of what was done, but the current condition. What is working. What is broken. What is deployed, tested, or pending. Written for someone who has not seen the code in 24 hours and needs to know where to start.
Common mistake: writing a retrospective instead. "Spent the day on auth middleware, fixed the rate limiter, updated the tests" — this is a diary entry, not a state declaration. The incoming engineer does not need to know what you did. They need to know what the system is doing now.
Part 2: Blockers with owners. Each active blocker, with the specific next action and the person who owns that action. Every blocker in a declared handoff should be unambiguously actionable even by someone who was not present when the blocker appeared.
Common mistake: listing blockers without owners. "Blocked on Stripe API" tells the incoming engineer nothing useful. "Rate limit on Stripe webhook endpoint; ticket PROD-1247 open with Alex — if no update by 12:00 SG time, escalate via Stripe support channel" tells them exactly what to do without asking a question.
Part 3: Decisions made. Any call made during the shift that affects what the next engineer will find when they start. Decisions to remove a feature from scope, to change a technical approach, to defer a dependency — these need to be declared explicitly. Decisions that live only in the head of the person who made them are invisible to the next shift.
Common mistake: omitting decisions because they felt obvious in the moment. They are never obvious to someone who was not present.
Part 4: Next actions with explicit ownership. A specific list of what needs to happen next, with each item owned by a named person. Not "someone should look at the SSO test" — but "Alex: review test/auth.spec.ts L142–178 for the token refresh race condition. Can defer to v1.1 if it does not block the milestone."
Common mistake: vague collective next steps. "We should review the tests" creates the double-pick-up problem: two engineers both start reviewing, or neither does because each assumed the other would.
Part 5: ETA back. When the outgoing engineer will be online again. This shapes every decision the incoming team can make: whether to wait on a blocker, whether to escalate, whether to make a call themselves or hold for the primary.
Common mistake: omitting it because it feels unnecessary. It is the single most useful piece of scheduling information the incoming shift can have.
The declared handoff in StandIn
StandIn's wrap protocol structures all five sections for engineers and stores them in the governance layer. Teammates in the next timezone start their shift with complete declared state — not a Slack feed to scroll, not a standup to attend. The handoff is already done.
Request accessWhat Happens When Each Section Is Skipped
Skip current state: The incoming engineer spends 20–40 minutes reading commits, PRs, and Jira tickets trying to reconstruct where the work stands. Some context is lost regardless — the reasoning behind choices is never in commits.
Skip blockers with owners: Blockers are discovered by the incoming shift when they run into them, not before. The incoming engineer has to chase down context, find the right ticket, identify the right owner — adding an hour of friction to what should have been a clean continuation.
Skip decisions made: The incoming shift makes decisions that conflict with or reverse decisions from the outgoing shift. Work gets duplicated or undone. The original decision-maker returns and has to reconstruct reasoning in a post-mortem conversation.
Skip next actions with ownership: The double-pick-up problem. Two engineers start the same work. Or neither starts it because ownership was unclear and each assumed the other had it.
Skip ETA back: The incoming team cannot calibrate whether to wait, escalate, or act independently on any blocker that requires the outgoing engineer. Minor delays become major ones.
Common Questions
How long should a declared handoff take to write?
Under two minutes for an engineer who has been working on the code all day. If it takes longer, the scope is too broad or the format is too complex. A handoff covers active work — what you touched today and what the next person will touch tomorrow. It does not require documenting the entire system or summarizing the entire sprint.
Who reads it?
The next engineer to work on the relevant code or task. Write for that person. If you would not need to say something to them if they walked up to your desk right now, you do not need to put it in the handoff. If you would, it must be there.
What if there is nothing new to declare?
Declare that explicitly. "No changes since last wrap. Auth middleware still on staging, blocker still open (PROD-1247). Nothing new for the next shift." This is itself useful information — the incoming engineer knows that the state they last saw is still current, and that there is no new context to absorb.
Is the declared handoff the same as the engineering wrap?
The terms are often used interchangeably. In StandIn's vocabulary: an engineering wrap is the habit (the act of posting before going offline), and the declared handoff is the output (the structured record that transfers state). The wrap is what you do. The declared handoff is what you produce when you do it.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.