Leave work someone else can continue

Two pages of background and not one line of state

The first time I handed a maintenance retainer to another freelancer, I was going away for ten days and wanted to be thorough. I wrote her nearly two pages: the client's history, why the theme had been customised the way it was, which person at the client to email for what, the hosting quirks I had learned the hard way. It felt generous. I sent it on the Friday and closed the laptop feeling organised.

On Monday morning she sent three questions. Which branch is the live one? Did the plugin update you mentioned actually go out? Is the contact form fix waiting on the client or on you? Every question was about the state of the work right now, and my two pages had answered none of them. She was polite about it. I was the one who felt silly, answering from a holiday rental on my phone.

That is the trap with handoffs. When you know a piece of work well, everything about it feels relevant, so you write the history. The person taking over needs something much smaller and much harder to write: where things stand, how to check that, what to do first, what is waiting on whom, and what not to repeat. Five fields, one screen. Background can be a link.

First decide whether ownership is actually moving

Before writing anything, answer one question honestly: who may change the branch, the document, or the config before you are back? If the answer is someone else, you owe a handoff. If it is only you, a status update is enough, and end-of-day status update covers that shape. If the only reader is you tomorrow and the work is code, restart coding where you left off tomorrow is the closer fit.

The difference is not length. A status assumes the reader shares your context and only needs the delta. A handoff assumes they share none of it and must take a real step from the note alone. A status that pretends to transfer ownership usually leaves out the proof, because you never needed proof when the work was yours.

Put the handoff where the work lives: the ticket, the pull request, or one shared document. "See the thread" stops working the moment the thread scrolls, and "I emailed it" fails as soon as a third person joins. Whatever the agreed place is, the latest note there is the one they should believe.

A handoff assumes they share none of it and must take a real step from the note alone.

State: what is true right now, in nouns a stranger can check

State is a description of the present that someone with access could confirm clause by clause, without asking what you meant by an adjective. The way to get there is to name the objects that locate the work: branch, pull request, environment, document version, ticket status, and if a flag is involved, the percentage and where it applies.

Take a running example I'll use for the rest of this guide. You are building a bookings import for a client's site. Bookings arrive as a CSV export from their old system and need to land in the new database without duplicates. It is 17:30 for you and a backend developer six hours behind you is taking over for the rest of their day.

A weak close: "Import is mostly working, a few duplicate issues left. Should be close!" A usable close: "Branch import-bookings, PR 317 open against main. Staging has the import code but has not run it on real data. The June sample file imports 412 rows locally; 14 of them are duplicates the check should have caught. Production untouched."

The first version hands over a mood. The second hands over a place they can open and a number they can reproduce. "Mostly working" and "close" make the next person search for the broken part themselves, and they will not know they have found it until they have spent an hour on it.

Two habits help. If two pages disagree, say which one wins: "The verify steps on the ticket are current. The PR description is a day behind." And if a rollout is partial, give counts and a window rather than a feeling: "Flag on for the two test accounts only. Everyone else sees the old import page." "The rollout is looking okay" cannot be checked by someone who wasn't watching.

Proof that runs without you in the room

Proof is how the next owner checks your state without using your memory as an interface. A link, a command, a test name, a query with a pinned time window, a screenshot they can recreate. "It works on my machine" is not proof. "Tests are green" is only proof if the note says which tests and how to run them.

I learned this from a relay handoff that went wrong in a small, irritating way. I wrote "all import tests passing" and logged off. The developer picking it up ran the suite and got eleven failures. The tests depended on a seed file I had generated by hand weeks earlier and never committed, so on every machine but mine they failed. He spent his first hour assuming he had broken something, then another half hour working out that he hadn't. My note was true and useless at the same time.

Honest proof for the bookings import reads like this: "Import tests pass with npm test -- import from the repo root. They need fixtures/bookings-seed.sql, now committed in PR 317. Staging has not run the import yet, so there is no staging proof." That last sentence matters. Saying what you have not checked is part of proof, because the gap you already know about is exactly the one they will hit first, and they will assume you never looked.

Read the proof as a stranger would. Name the VPN or network path it needs. Name the environment variable, not its value. A screenshot that only exists on your desktop is not proof; attach it. If a dashboard is involved, pin the window with a UTC start, or they open an empty chart.

Support and QA work the same way. Support proof is the reproduction: the request capture, the fixture, and whether production reproduces it. "The customer is upset" schedules a meeting, while a captured request leads to a config diff. QA proof starts with the build, the step, the expected result, and the actual one. For secrets, give the vault path and key name only, and confirm the next owner can open that path. If they can't, that is a blocker with a clock, not a detail. If a secret ever lands in a draft note, rotate it rather than just deleting the line.

One next move, physical enough to start cold

The next move is the first action they take, not a theme for their afternoon. It needs to be physical enough that they can begin without first booking time to interpret you.

A weak line: "Look into the duplicates." A line they can execute: "Run npm run import -- --file samples/june.csv --dry-run on import-bookings. It should report 398 rows. If it still reports 412, the duplicate check in BookingMatcher is ignoring the time zone on the booking date; start there."

A weak line: "Check with the client about the format." A line they can execute: "Open the client's sample file july-export.csv in the ticket and confirm the date column is day-first like June's. If it isn't, note it on the ticket; don't change the parser yet."

If you cannot name a file, a command, a screen, or a runbook step, you still have a topic, not a move. Sometimes the honest next move is "write the missing reproduction," and that is fine. Why remote workers need a clear next action covers the general habit. A handoff is stricter, because the reader did not share your afternoon and cannot ask you what you meant.

Give one move, not a menu. If three are possible, pick the one you would do with twenty more minutes. Then name who does it and when, if you know: "Backend, after your lunch, from about 16:00 UTC. Dry run first, then the duplicate check." "Whoever is around" sits untouched all afternoon, because everyone assumes someone else is around.

Every blocker gets a name and a UTC time

A blocker with no name waits forever. A blocker with no clock waits until someone feels it would be rude to keep waiting. Write who owes what, by when, in UTC. If nothing stops the next move, write "none" so they don't wonder.

For the bookings import: "Client to send the full July export (not the sample) before Thursday 10:00 UTC. Asked in the ticket at 15:10 UTC today. Without it, the import can be tested but not signed off." The next owner now knows who to nudge, where the ask already sits, and the moment at which nudging stops being early and starts being late.

A risk they can work past is not a blocker. "The client's old system may export a different date format in July" belongs in state. "Needs the client" on its own is not a line; "The client chooses between importing cancelled bookings or skipping them. Options are in the ticket comment from 13:40 UTC. Needed before Thursday" is. If either option can be built behind a flag, the choice isn't blocking, and the next move should name the default. How to report blockers without sounding passive is the longer fix for lines like "waiting on infra."

If you owe the next fact yourself, say so with a time: "I'll post the July file's row count at 08:00 UTC tomorrow." Otherwise they will go looking for it, and you will both do the same work.

Write down what must not be redone

This is the field people skip, and it is the one I'd keep if I could keep only one. Debugging and setup are mostly experiments, and experiments are invisible in a diff. If you restarted something, reverted something, emailed someone, or tried an idea that failed, the next owner cannot see it unless you write it.

The story that convinced me: on a remote team I once rebuilt the staging search index to test a theory about stale results. It took about forty minutes, search was half-broken on staging while it ran, and the theory was wrong. I didn't mention it in the handoff, because it hadn't worked and felt like noise. The next morning a colleague had the same reasonable theory and rebuilt the index again. Another forty minutes, another round of a designer asking why staging search was empty. One sentence from me would have saved all of it.

The field looks like this:

• Do not rerun the full June import on staging. It ran once at 14:20 UTC and created duplicates that are now flagged, not deleted.
• Do not merge PR 312. It is superseded by 317.
• Do not email the client about cancelled bookings. The question is already in the ticket and they reply there.

Each line names the action, the time if it matters, and why it stays done. Failed ideas count too: "Matching on email plus date was tried at 15:00 UTC. Families book under one email, so it merges real bookings. Don't go back to it."

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, in the chair, while the details are fresh. The exact command and vault path fade within half an hour of closing the editor. If the background is long, link it. Do not paste it in, because the five fields will drown.

Before the laptop closes, I run five checks:

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 I nearly left in local time out of habit.
3. Each link opens from a clean session, or the note says which network path it needs.
4. Do not redo is filled in if I tried anything that failed or must not be repeated.
5. They can actually run the proof. I confirmed their access, or the missing access is listed as a blocker with a clock.

The receiving side has a simple job when this works: open the ticket, run the proof, do the next move. If they need to ping you before that, the handoff failed, and the useful response is to fix the note rather than just answer the ping. When their shift ends, they leave the next note in the same place, so there is one story, not two versions drifting apart in chat. Async communication for distributed teams covers the response windows that make this reliable.

The same five fields for freelancers, support, design and relays

I don't keep a template per type of work. The fields stay fixed and the nouns change.

Freelancer to freelancer. When client work moves between freelancers, state needs two things a team handoff often skips: what the client has been told, and who the client thinks is their contact this week. The retainer handoff from the start of this guide would have been fine with five lines: live branch and staging link; the plugin update tested on staging but not live; next move to apply it live on Tuesday morning after the client's weekly backup; contact form fix blocked on the client choosing a recipient address; and do not touch the old theme folder, because a child theme depends on it. That is shorter than the two pages, and it answers all three of her Monday questions.

Design. State is the file and the frame or version. Proof is a link to the exact frame, not the whole file. Next is one frame or one decision. Do not redo covers rejected directions: "The darker header was rejected at 14:10 UTC. Don't bring it back."

Support. State is the symptom and when it started. Proof is the reproduction and whether production shows it. If the reproduction is missing, capturing it is the next move.

Relays across three zones. Asia leaves proof of the overnight run. Europe runs that proof, does the named move, and records a decision. The Americas shift continues only once the decision is written, then leaves staging verification and do not redo for the next morning. Drop proof at any hop and the next one ends up booking a call at a bad hour. The scheduling side of that is in timezone collaboration without chaos.

Time off. Add one line on who may change scope while you are away. Without it, the next owner either freezes or makes product decisions they weren't sure they were allowed to make.

The ninety-second version when a call is about to start

Ownership sometimes moves when you have two minutes before a call. You still write the handoff. Formatting can wait; the fields can't.

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 first physical 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.

Here is one written in a hurry before a client call: "State: July import on staging stopped at row 2,180 of 4,906 with a date parse error. Proof: error and row number in the ticket comment, sample row attached. Next: backend checks whether row 2,180 has a two-digit year; if yes, add the format to the parser and rerun from that row with --resume-from 2180. Blocked: none. Do not redo: do not restart the import from zero, the first 2,179 rows are in and deduplicated."

If you only managed state before the call started, finish the rest after it and before you go offline. "Ping me if you need anything" tends to appear on exactly the chaotic evenings when the fields matter most, and it asks the next person to wait for you instead of starting.

A good test for any of these notes: could they have started real work within five minutes of opening it? If not, rewrite proof or next move before you leave. Everything else in the handoff is nice to have. Those two are what let someone else carry on while you are asleep, on holiday, or on another call, and the effort of writing them is always smaller than the morning someone loses without them.