The short version
- A decision handoff passes the state of every open decision to the next person or time zone: what was decided, what is waiting, and who can decide what.
- It is the working core of async decision making, where decisions get made in writing instead of in a meeting.
- Most decisions get lost overnight, between one office logging off and the next logging on.
- Name who may decide while the owner is offline, and what they may decide.
A decision handoff is the short written note that passes the state of open decisions from one person or time zone to the next: what was decided today, what is still waiting and on whom, and who may decide what while the owner is offline. It is what makes async decision making work, because a decision made in writing is only useful if the next shift can find it and act on it.
On a team spread across time zones, the work never stops, but the people do. When the Tokyo office logs off, Amsterdam is halfway through its morning. If a decision was made in an afternoon thread, the morning team either finds it, misses it, or makes a different one. The handoff is how they find it.
What async decision making is
Async decision making means making a decision in writing, over hours or days, instead of in a meeting. Someone writes the proposal, the people affected comment in their own time, and a named owner decides by a set deadline. Nobody needs to be online at the same moment.
It suits most decisions on a distributed team, because a meeting that suits everyone usually suits nobody. It fails in two ways: when there is no named owner, so the proposal collects comments forever, and when the decision is made but never handed to the people who were asleep. The first is fixed by naming a decider. The second is fixed by the handoff. For larger proposals, a written RFC process gives async decisions a clear structure.
Which decisions need a handoff
Not every decision. Hand off the ones the next shift will run into:
- Decisions made today that change what the next team should do.
- Decisions waiting on someone, with a deadline that falls in the next shift.
- Decisions you would have made yourself if the question had come up, written down so the next shift does not have to wait for you.
- Anything reversed or changed today, so nobody follows the old answer.
What to include in a decision handoff
| Field | What to write |
|---|---|
| Decided today | Each decision in one line, with the owner and a link to where it happened |
| Changed today | Any earlier decision reversed or replaced, and what replaced it |
| Waiting | Each open decision, who must make it, and by when |
| You may decide | What the next shift may decide without waiting, and the limits |
| Must wait | What has to wait for the owner, and why |
| Urgent contact | Who to reach if something cannot wait, and how |
Keep it short. A handoff that takes more than five minutes to write will be skipped on busy days, which are the days it matters most. The decisions themselves also go in the team's decision log, so the handoff can link to them instead of repeating them.
Who decides while the owner is offline
The hardest moment is a question that needs a decision when the owner is asleep. Without a rule, the next shift either waits a full day or guesses. Write the rule down in advance, for each area of work:
- Decisions that are easy to undo: the next shift decides and notes it in the handoff.
- Decisions that are costly to undo: the next shift decides only if waiting would cost more, and says why.
- Decisions that cannot be undone: they wait.
The reversible vs irreversible decisions guide explains how to sort decisions into those groups, and a decision authority map names the stand-in for each area.
When the next shift wants to reverse a decision
Sometimes the morning team disagrees with what the evening team decided. The rule is the same as for any decision: they take it to the owner, with what is new, rather than doing it their way without telling anyone. If it is urgent and reversible, they may change course and say so clearly in their own handoff. Two teams undoing each other's decisions every night is a sign the owner is unclear, not that the handoff failed.
What decision velocity means
Decision velocity is how quickly a team gets from a question to a decision that sticks. On distributed teams, the biggest drag on it is waiting: for the owner to wake up, for a meeting slot, for someone to find the thread. Every handoff that names who may decide removes a day of waiting. The decision velocity assessment gives a quick read on where your team loses time.
For how handoffs fit with logs, records and authority maps, see the guide to a system of record for decisions.
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. When you log off in Tokyo, a teammate in Amsterdam can ask what you decided and get the answer from your brief, in your words, with the source. When the decision is not there, your StandIn never guesses: it says so and points to who can decide. See how this works for teams working across time zones.
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 StandInEvery answer, on the record.
Your StandIn answers only from what your team wrote down, names who decided what, and keeps a record of every answer. Nothing it says is a guess.