Most handoffs fail for a simple reason. They take too long to write, so people skip them. Then the next person spends an hour reconstructing what a ninety-second note could have told them. This is a checklist short enough that you will actually fill it in.
The goal is not a beautiful document. The goal is that someone in another time zone can pick up your work and keep going without messaging you. Below is the checklist, then a worked example, then how to make it a habit.
The checklist
Copy this. Paste it wherever your team keeps handoffs. Fill in the blanks at the end of your day. It has six lines, and most of them are one sentence.
Handoff, [date]
1. Done and safe to build on: [What is finished and merged, or safe to rely on.]
2. In progress, next step is: [What is half done, and the exact next action to take.]
3. Blocked on: [What is stuck, and on what or whom. Write "nothing" if truly clear.]
4. Watch out for: [The one thing most likely to bite the next person.]
5. You can go ahead and: [What the next person is free to do without you.]
6. Please wait for me on: [What should not move until you are back.]
Links: [Ticket, pull request, and the thread where the key decision was made.]
That is the whole thing. Seven fields, and two of them are often "nothing" or a single link. If it takes more than ninety seconds, you are writing a story instead of a state.
Why each line is there
Every field earns its place by killing a specific follow up question.
- Done and safe to build on stops the next person from redoing work or wondering if a branch is trustworthy.
- In progress, next step is is the most important line. Not what you did, but the exact next action, so someone can sit down and start typing instead of first figuring out where you left off.
- Blocked on tells the next person what to chase, or reassures them that nothing is stuck.
- Watch out for passes on the trap you already paid to discover. This single line saves the most time of any field on the list.
- You can go ahead and plus Please wait for me on draw the line between permission and boundary, so the next person moves fast on what they own and leaves alone what they do not.
- Links removes the search. The ticket, the pull request, and the thread where the decision was made, so nobody has to hunt.
A filled-in example
Here is the checklist used for real, so you can see the shape of a good one. Say Sarah in Tokyo is handing off to Alex in Amsterdam at the end of her day.
Handoff, Tuesday
1. Done and safe to build on: The new checkout validation is merged and live on staging. Safe to build on top of it.
2. In progress, next step is: The refund flow is half wired up. The API call works, but the success screen is not connected yet. Next step is to hook the success state to the existing toast component in CheckoutView.
3. Blocked on: Nothing right now.
4. Watch out for: The refund endpoint returns a 200 even when it fails quietly, so do not trust the status code alone. Check the body for an error field.
5. You can go ahead and: Merge the refund branch if CI is green and the success screen works.
6. Please wait for me on: Do not change the refund amount rounding logic. There is a reason it is the way it is, and I want to explain before anyone touches it.
Links: [ticket] [pull request] [the Slack thread where we decided to keep partial refunds out of scope]
Read that as Alex. You know exactly what to do next, what to fear, what you may merge, and what to leave alone. You did not have to message anyone. That is a handoff that took Sarah ninety seconds and saved Alex an hour.
Make it a habit, not a hero effort
A checklist only works if it is the same one every day, in the same place. Pick one spot: a pinned channel, a standing doc, a template your team pastes from. If you want a fuller starting point to adapt, this free engineering handoff template covers the same fields in more detail. Then set a small trigger. Stop coding five minutes before you log off. Those five minutes are not lost time. They are the cheapest hour of the next person's day, bought in advance.
Do not aim for perfect. A rough handoff that hits all six fields beats a polished one that skips the "watch out for" line. The traps are where the value is. Get those down first and let the prose be ugly.
One more thing keeps the habit alive: make it two-sided. When the next person picks up your handoff and it saved them, have them say so, even just once in a while. When a field was missing and cost them time, have them name which one. That feedback loop is how a team learns which lines actually matter for its work, and it turns the checklist from a chore into something people trust because they have felt it pay off.
When the checklist runs out
Even a good handoff cannot cover the question you did not see coming. The next person needs one detail that was clear in your head and never made it onto the list. That is not a failure of the checklist. No list predicts every question.
This is the small job StandIn does after the handoff is written. You write a short brief at the end of your day, and while you are off, it answers your teammates from what you actually wrote down, with a source under each answer. When the answer is not in the record, it says so instead of guessing. The checklist gets the work moving. StandIn catches the follow up that would otherwise sit in your inbox until morning.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.