Decide whether ownership moves tonight

You stop. Someone else starts. If the context lived in chat, they rebuild it for an hour or they ping you while you are asleep. A handoff is the smallest package that lets them take a first step. It is not a diary.

A status update is for when the work is still yours tomorrow. A handoff is for when someone else owns the next move. Pick one. A status that pretends to transfer ownership leaves out proof.

Use end-of-day status update when the ticket stays with you. Use restart coding where you left off tomorrow when the only reader is you and the work is code. When someone else continues while you are offline, write state, proof, next move, and blockers. Add do not redo when they might repeat a failed experiment. Five lines, one screen. Link a design doc. Do not paste it.

Async habits around the note: async communication for distributed teams. Overlap rules: timezone collaboration without chaos. The handoff is what you leave at that boundary.

SituationWrite thisKeep it to
You resume tomorrowA status in four bucketsSomething you will reread at the desk
A teammate continues the same ticketThe handoff fieldsOne screen
A follow-the-sun relayThe handoff, with the same facts on the ticketOne story, stored in both places
Someone outside the repo needs newsPlain status, no branch namesA few sentences
You will be out for daysHandoff, plus do not redoFinished before you leave

Who may change the branch, the document, or the config before you are back? Someone else means a handoff. Only you means a status. The canonical place is the ticket, the pull request, or one shared document. "See the thread" fails when the thread scrolls. The latest note in the agreed place is what they should believe.

Write state a stranger can check

State is what is true right now. A person with access should confirm every clause without asking what an adjective meant.

Name the objects that locate the work. Branch name. Pull request link. Environment. Document version. Ticket status. If a flag is involved, the percentage and the region. Leave the tour out. "Checkout is still weird" does not locate anything. "Pull request 482 is open against main. Preview is green except the payment webhook. Production has not moved. The flag is off." That locates the work in one breath.

Example. Assumptions: you are leaving a payments change; a preview environment exists; production is unchanged; the webhook path is the part that fails. A weak close: "Wrapped up. Checkout still weird. Ping me if you need anything." A usable close: "PR 482 open against main. Preview green except the payment webhook. Production unchanged. Flag off." The first hands over a mood. The second hands over a place they can open.

"Almost done" forces a search for the red path. Write it: "PR 482 open. Webhook path red. Next step is the preview secret, then a redeploy."

Skip in-jokes. If two pages disagree, say which one wins: "Verify steps on the ticket are current. The pull request description is a day behind." Partial deploys need counts. "Flag on for 10 percent in region A only. Region B untouched. Query linked, window from 12:00 UTC." "The rollout is looking okay" cannot be checked at 08:00.

Attach proof that runs without you

Proof is how the next owner checks your state without using your memory as an API. A link, a command, a test name, a screen they can capture again, a dashboard query with a pinned window. "It works on my machine" is not proof. "Tests are green" is not proof unless the invocation is in the note.

Example. Assumptions: local tests pass; the preview URL lives in the pull request description; you have not clicked the webhook paths on that preview. Honest proof: "Unit tests passed via npm test from services/payments. Preview URL is in the PR description. Webhook paths on preview have not been clicked yet." The short version, "tests green," hides the gap you already know about. They will meet that gap at their sunrise and assume you never looked.

Read the proof as a stranger. Name the VPN. Name the variable, not its value. A screenshot that lives only on your desktop is not proof. Pin a dashboard window with a UTC start, or they open an empty chart.

Support proof is the reproduction. Attach the HAR, name the fixture, and say whether production reproduces it, and where. "The customer is upset" schedules a meeting. A HAR produces a config diff. QA returning a build starts with build id, step, expected, and actual. "QA failed" is not proof. Vault path and key name only. Confirm they can open that path, or access is the blocker. If a secret landed in a draft, rotate it.

Name one physical next move

The next move is the first action they take, not a theme for their morning. Name a person or a rotation, a timezone, and a window when you know them. The action has to be physical enough that they can begin without booking time to interpret you.

A weak line: "Continue checkout." A line they can execute: "In PaymentsController, replace the stub in confirmWebhook with the signed payload check described on PAY-218. Add one failing test before you change the production code."

A weak line: "Look into performance." A line they can execute: "Run benchmark.sh --scenario=checkout on branch perf-12. Paste the current p95 and the new p95 into PERF-44."

If you cannot name a file, a command, a frame, or a runbook step, you still have a topic. Sometimes the honest move is "write the missing reproduction." Why remote workers need a clear next action is the general standard. A handoff is stricter, because the reader did not share your afternoon. One move, not a menu. If three are possible, pick the one you would do with twenty more minutes.

Example. Assumptions: you stop at 17:00 in America/Los_Angeles; the next owner starts around 08:00 in Europe/Berlin; the preview secret is in a vault; you have not redeployed. Next move: "Berlin owner, from about 08:00 Europe/Berlin. Set the preview webhook secret from vault path payments/preview. Redeploy. Click one success path and one failure path. Comment pass or fail on PR 482." "Ping me if needed" asks them to wait.

Name the rotation and where the schedule lives. "Whoever is around" sits all morning. Design, ops, and drafts use the same shape: one frame, one runbook step, or one section, specific enough to start without a call.

Put a name and a UTC time on every blocker

A blocker with no name waits forever. A blocker with no clock waits until someone feels rude. Write who owes what, by when, in UTC. If nothing stops the next move, write "none."

Example. Assumptions: the preview cannot be fully checked until a secret exists; the platform rotation can read the vault; without that secret the Berlin morning cannot do the clicks. Blocked: "Platform on-call, schedule linked from the payments rotation. Preview webhook secret, needed before 14:00 UTC. Config read on the service is already confirmed." They know who to nudge, and they know the minute at which nudging is late rather than early.

A risk you can work past belongs in state, not here. "Error budget is at 40 percent. Expanding the flag is not automatic." If they can start, it is not a blocker. How to report blockers without sounding passive is the correction for "waiting on infra." Add a name and a deadline. If you owe the next fact, say so: "I will post the config diff at 15:00 UTC." Silence gets duplicated at their sunrise.

"Needs product" is not a line. "The product owner chooses expand or hold. Options are in the pull request comment from 15:40 UTC. Needed before 18:00 UTC." If either option can be built behind a flag, the choice is not blocking, and the next move should name the default. Several debts need several sentences, each with a clock.

Record the moves the next owner must not redo

Skip this field only when you did not experiment. If you cycled a pool, reverted a commit, wrote to a customer, or left a superseded pull request open, write the action, the UTC time, and why it stays done.

  • Do not restart the worker pool. It was cycled at 16:00 UTC after the preview deploy.
  • Do not merge pull request 480. It is superseded by 482.
  • Do not email the customer. Comms owns that thread until Monday at 16:00 UTC.

The next shift will repeat an experiment it cannot see. The sentence is cheaper than that repeat.

Example. Assumptions: the flag is on for 10 percent in region A; a query shows the error rate; a full enable has its own checklist. State: "Flag on for 10 percent in region A only." Proof: "Query linked, window from 12:00 UTC." Next: "Watch the error budget until 18:00 UTC, then post expand or rollback." Do not redo: "Do not set the flag to 100 percent. Region B is out of scope."

Same field, other work. "Section 3 was rejected at 14:10 UTC. Do not put that paragraph back." "Do not restart service S. Already restarted at 16:00 UTC." "A 30 second timeout bump at 15:20 UTC changed nothing. Look at the signature check."

Paste the handoff template before you leave

Decide whether ownership moves tonight You stop. Someone else starts. If the context lived in chat, they rebuild it for an hour or they ping you while you are asleep. A handoff is the smallest package that lets them take a first step. It is not a diary. A status update is for when the work is still yours tomorrow. A handoff is for when someone else owns the next move. Pick one. A status that pretends to transfer ownership leaves out proof. Use end-of-day status update when the ticket stays with you. Use restart coding where you left off tomorrow when the only reader is you and the work is code. When someone else continues while you are offline, write state, proof, next move, and blockers. Add do not redo when they might repeat a failed experiment. Five lines, one screen. Link a design doc. Do not paste it. Async habits around the note: async communication for distributed teams. Overlap rules: timezone collaboration without chaos. The handoff is what you leave at that boundary. SituationWrite thisKeep it toYou resume tomorrowA status in four bucketsSomething you will reread at the deskA teammate continues the same ticketThe handoff fieldsOne screenA follow-the-sun relayThe handoff, with the same facts on the ticketOne story, stored in both placesSomeone outside the repo needs newsPlain status, no branch namesA few sentencesYou will be out for daysHandoff, plus do not redoFinished before you leave Who may change the branch, the document, or the config before you are back? Someone else means a handoff. Only you means a status. The canonical place is the ticket, the pull request, or one shared document. "See the thread" fails when the thread scrolls. The latest note in the agreed place is what they should believe. Write state a stranger can check State is what is true right now. A person with access should confirm every clause without asking what an adjective meant. Name the objects that locate the work. Branch name. Pull request link. Environment. Document version. Ticket status. If a flag is involved, the percentage and the region. Leave the tour out. "Checkout is still weird" does not locate anything. "Pull request 482 is open against main. Preview is green except the payment webhook. Production has not moved. The flag is off." That locates the work in one breath. Example. Assumptions: you are leaving a payments change; a preview environment exists; production is unchanged; the webhook path is the part that fails. A weak close: "Wrapped up. Checkout still weird. Ping me if you need anything." A usable close: "PR 482 open against main. Preview green except the payment webhook. Production unchanged. Flag off." The first hands over a mood. The second hands over a place they can open. "Almost done" forces a search for the red path. Write it: "PR 482 open. Webhook path red. Next step is the preview secret, then a redeploy." Skip in-jokes. If two pages disagree, say which one wins: "Verify steps on the ticket are current. The pull request description is a day behind." Partial deploys need counts. "Flag on for 10 percent in region A only. Region B untouched. Query linked, window from 12:00 UTC." "The rollout is looking okay" cannot be checked at 08:00. Attach proof that runs without you Proof is how the next owner checks your state without using your memory as an API. A link, a command, a test name, a screen they can capture again, a dashboard query with a pinned window. "It works on my machine" is not proof. "Tests are green" is not proof unless the invocation is in the note. Example. Assumptions: local tests pass; the preview URL lives in the pull request description; you have not clicked the webhook paths on that preview. Honest proof: "Unit tests passed via npm test from services/payments. Preview URL is in the PR description. Webhook paths on preview have not been clicked yet." The short version, "tests green," hides the gap you already know about. They will meet that gap at their sunrise and assume you never looked. Read the proof as a stranger. Name the VPN. Name the variable, not its value. A screenshot that lives only on your desktop is not proof. Pin a dashboard window with a UTC start, or they open an empty chart. Support proof is the reproduction. Attach the HAR, name the fixture, and say whether production reproduces it, and where. "The customer is upset" schedules a meeting. A HAR produces a config diff. QA returning a build starts with build id, step, expected, and actual. "QA failed" is not proof. Vault path and key name only. Confirm they can open that path, or access is the blocker. If a secret landed in a draft, rotate it. Name one physical next move The next move is the first action they take, not a theme for their morning. Name a person or a rotation, a timezone, and a window when you know them. The action has to be physical enough that they can begin without booking time to interpret you. A weak line: "Continue checkout." A line they can execute: "In PaymentsController, replace the stub in confirmWebhook with the signed payload check described on PAY-218. Add one failing test before you change the production code." A weak line: "Look into performance." A line they can execute: "Run benchmark.sh --scenario=checkout on branch perf-12. Paste the current p95 and the new p95 into PERF-44." If you cannot name a file, a command, a frame, or a runbook step, you still have a topic. Sometimes the honest move is "write the missing reproduction." Why remote workers need a clear next action is the general standard. A handoff is stricter, because the reader did not share your afternoon. One move, not a menu. If three are possible, pick the one you would do with twenty more minutes. Example. Assumptions: you stop at 17:00 in America/Los_Angeles; the next owner starts around 08:00 in Europe/Berlin; the preview secret is in a vault; you have not redeployed. Next move: "Berlin owner, from about 08:00 Europe/Berlin. Set the preview webhook secret from vault path payments/preview. Redeploy. Click one success path and one failure path. Comment pass or fail on PR 482." "Ping me if needed" asks them to wait. Name the rotation and where the schedule lives. "Whoever is around" sits all morning. Design, ops, and drafts use the same shape: one frame, one runbook step, or one section, specific enough to start without a call. Put a name and a UTC time on every blocker A blocker with no name waits forever. A blocker with no clock waits until someone feels rude. Write who owes what, by when, in UTC. If nothing stops the next move, write "none." Example. Assumptions: the preview cannot be fully checked until a secret exists; the platform rotation can read the vault; without that secret the Berlin morning cannot do the clicks. Blocked: "Platform on-call, schedule linked from the payments rotation. Preview webhook secret, needed before 14:00 UTC. Config read on the service is already confirmed." They know who to nudge, and they know the minute at which nudging is late rather than early. A risk you can work past belongs in state, not here. "Error budget is at 40 percent. Expanding the flag is not automatic." If they can start, it is not a blocker. How to report blockers without sounding passive is the correction for "waiting on infra." Add a name and a deadline. If you owe the next fact, say so: "I will post the config diff at 15:00 UTC." Silence gets duplicated at their sunrise. "Needs product" is not a line. "The product owner chooses expand or hold. Options are in the pull request comment from 15:40 UTC. Needed before 18:00 UTC." If either option can be built behind a flag, the choice is not blocking, and the next move should name the default. Several debts need several sentences, each with a clock. Record the moves the next owner must not redo Skip this field only when you did not experiment. If you cycled a pool, reverted a commit, wrote to a customer, or left a superseded pull request open, write the action, the UTC time, and why it stays done. Do not restart the worker pool. It was cycled at 16:00 UTC after the preview deploy.Do not merge pull request 480. It is superseded by 482.Do not email the customer. Comms owns that thread until Monday at 16:00 UTC. The next shift will repeat an experiment it cannot see. The sentence is cheaper than that repeat. Example. Assumptions: the flag is on for 10 percent in region A; a query shows the error rate; a full enable has its own checklist. State: "Flag on for 10 percent in region A only." Proof: "Query linked, window from 12:00 UTC." Next: "Watch the error budget until 18:00 UTC, then post expand or rollback." Do not redo: "Do not set the flag to 100 percent. Region B is out of scope." Same field, other work. "Section 3 was rejected at 14:10 UTC. Do not put that paragraph back." "Do not restart service S. Already restarted at 16:00 UTC." "A 30 second timeout bump at 15:20 UTC changed nothing. Look at the signature check." Paste the handoff template before you leave

State: branch or doc, link, environment, flag or version
Proof: command, URL, test name, or what a screenshot must show
Next move: owner, timezone, start window, first physical action
Blocked: who owes what, by when UTC, or none
Do not redo: action already taken, with UTC time, or none

Fill those lines on the ticket. One screen. Link the timeline if it is long. Do not paste it.

Run this check before the laptop closes.

  1. The next owner is a name or a rotation, not "the team" and not "someone."
  2. Every time in the note is UTC, including the one you nearly left in local time out of habit.
  3. Each link opens from a clean session, or you wrote which network path it needs.
  4. Do not redo is filled in if you tried a step that failed or that must not be repeated.
  5. They can run the proof. You confirmed the access, or the missing access is the blocker and it has a clock.

They open the ticket, run proof, and do the next move. A ping before that means the handoff failed. If proof fails, the escalation names who, what, and a UTC time. Then they update state and, if their shift ends, leave the next note in the same place. Write yours in the chair. The command and the vault path fade within half an hour. Edit the ticket later. Do not add a second version in chat.

Keep the same fields when the relay changes

Do not keep a template per department. State, proof, next move, blockers, and do not redo stay fixed. The nouns change.

Example. Assumptions: you finish at 17:00 in America/Los_Angeles; the next engineer starts in Asia about two hours later; most days you share no comfortable live window. Leave the branch, the pull request, what done meant on your shift, and one risk. They pull, run the listed checks, and continue only the named move. If a check fails, they write a blocker. Overlap is for a decision already written down. Those rules are in timezone collaboration without chaos.

Three shifts use the same fields. Asia leaves proof of the overnight tests. Europe runs that proof, then the named move, and leaves an explicit decision. The Americas shift continues only when the decision is written, then leaves staging verification and do not redo. Drop proof and the next hop books a meeting at a bad hour.

Support needs the symptom, the UTC start, the HAR, and whether production reproduces. If the HAR is missing, capturing it is the next move. Product needs the decision, the options link, and implement or hold. Incidents stay short: proof first, one next step, and do not redo for mitigations already applied. Time off adds who may change scope. "Post expand or hold before 18:00 UTC" is a next move. "Think about the rollout" is not.

Vault paths only. No secret in the note or the screenshot. One canonical home. Latest note wins. "Click one success path and one failure path on preview" travels. "Kick the tires" does not.

Write the note in ninety seconds when you are out of time

Ownership can move when a call starts in two minutes. You still write the handoff. Formatting can wait. The fields cannot.

  1. State. One sentence on where the work sits. About fifteen seconds.
  2. Proof. A link, a command, or a pointer to the file that shows it. About twenty seconds.
  3. Next move. The physical first action, and who does it. About twenty seconds.
  4. Blocked. Who owes what, by when in UTC, or the word none. About fifteen seconds.
  5. Do not redo. The step they must not repeat, or none. About twenty seconds.

Paste the five lines before you join. If you only wrote state, finish the rest after the call and before you go offline. "Ping me if you need anything" shows up after chaotic evenings, which is when the fields matter most.

Example. Assumptions: the incident channel is noisy; you are about to join a bridge; the next region picks the work up in three hours; you have already applied one mitigation. A ninety-second note can read: "State: checkout returns 502 on preview after 3DS, started 14:20 UTC. A single production region does not reproduce it. Proof: the HAR is on the ticket, and the test fixture is named in the comment. Next: Denver on-call compares preview and production gateway config since deploy 8821, and posts the diff before 21:00 UTC. Blocked: none. Config read is already confirmed. Do not redo: do not restart the worker pool. It was cycled at 16:00 UTC."

If they could not start within about five minutes from that note, rewrite proof or next before you leave.

When the work stays with you, use end-of-day status update. To resume your own branch, use restart coding where you left off tomorrow. Another person gets the five fields.

Then stop. Their first minutes belong on the job.