The short version
- An engineering handoff passes the state of your work to the next engineer: what is in progress, what is blocked, what is waiting for review, and what you decided.
- Write state, not status. "Branch is ready except the migration test" beats "making progress."
- Use the same format every time, so the reader knows where to look.
- The next person reads it before asking anything.
An engineering handoff is the written note that passes the state of your work to the next engineer, whether they pick it up tomorrow, in the next time zone, or after you go on leave. The template below is a copy-and-paste format for end of day, end of sprint and mid-project handoffs.
Engineering handoffs fail in a predictable place: the reasoning. The ticket shows what changed. The branch shows the code. Neither shows that you suspected the cache, tried a fix that did not work, and decided to wait for the vendor. That is the context the next person needs and cannot find.
The template
Engineering handoff: [your name], [date and time zone]
In progress
- [Ticket or PR]: where it stands, what is left, the next step.
Blocked
- [Item]: blocked on [person or thing], since [when], what unblocks it.
Waiting for review
- [PR link]: what it does, who should review, anything risky.
Decided today
- [Decision]: why, and who decided. Link to the thread or log entry.
Looks odd but is fine
- [Thing]: why it is expected, so nobody wastes time on it.
Next person should
- [The one or two things to do first.]
Links
- [Dashboards, docs, threads, runbooks.]Write state, not status
"Working on the auth refactor" is status. It tells the reader nothing they can act on. "Auth refactor is on branch feat/token-rotation. Tests pass except the migration test, which fails because the staging database is behind. Next step: run the migration on staging, then rerun" is state. The reader can start working the moment they finish reading.
A quick test: could the next engineer continue your work without messaging you? If not, the handoff is missing something.
A 90-second checklist
Before you log off, check that the handoff answers these:
- What is in progress, and what is the next step for each item?
- What is blocked, and on whom?
- Which pull requests need review, and is anything risky?
- What did you decide today, and why?
- Is anything broken on purpose, or odd but expected?
- What should the next person do first?
Versions for end of day, end of week and end of sprint
End of day: the template above, kept short. On a distributed team this is the most important handoff, because the next shift starts while you are asleep.
End of week: add a short "this week" summary at the top: what shipped, what slipped, and anything to watch over the weekend. It is the handoff people read on Monday morning, so make the first lines count.
End of sprint: add the work moving to the next sprint, with the state of each item and anything learned that changes the plan. Unfinished work handed over with its state picks up in hours; handed over as a ticket title, it picks up in days.
Handing over a project mid-flight
When a project changes hands for good, a single note is not enough. Add three things to the template: the history of the main decisions and why they were made, the people outside the team who matter to the project, and the known risks. Then overlap for a few days if you can, with the new owner making the calls while you are still there to answer questions. The same applies when picking a project back up after time away: read the last handoff first, then the decisions made since.
Where engineering handoffs lose context
Context gets lost in the same few places on most teams:
- Decisions made in chat that never reach the ticket.
- Reasons for a fix that live only in a reviewer's head.
- Half-finished investigations with no notes.
- Work that depends on someone outside the team, with no record of what they promised.
A consistent template catches most of these. Writing decisions down where people can find them catches the rest; see the guide to a decision log for engineering teams.
Running handoffs without a sync meeting
- Pick one place for handoffs: a channel, a doc, or the team's tool.
- Set a time each day by which the handoff is posted.
- The incoming engineer reads it before asking anything.
- Questions the handoff did not answer go back to the author in writing, and the answer goes into the next handoff.
For handoffs between time zones, including the four fields every handoff needs and how to tell whether yours are working, see the guide to async handoffs across time zones. For an on-call rotation, use the on-call handoff template. For leave, write a handover document as well, and see the guide to covering for a teammate on leave.
Where StandIn fits
StandIn is a personal knowledge base, built on the work that you already do, that answers your teammates when you're away, in chat and email. After you log off, the next engineer can ask your StandIn about your branch, your blockers or today's decisions, and get the answer from your brief, in your words, with the source. When the answer is not there, it never guesses. See how it works for engineering teams.
Parker Miller
Founder, StandIn
Parker Miller founded StandIn. He writes about coverage, handoffs, and what it takes for software to answer for a team from what people actually wrote down.
More about StandInWhen 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.