A decision log is simple when everyone shares an office and a clock. Spread the same team across three time zones and the log becomes the only place the decision actually lives, because no two people are always online to talk it through. Here is how to keep one log working when Tokyo, Amsterdam, and a third office are rarely awake together.
Why the log carries more weight when you are spread out
In one office, the log is a backup. If it is unclear, you turn around and ask. Across three time zones, there is often no one to turn to. The person who made the call is asleep, and the person who needs it cannot wait. The log stops being a backup and becomes the primary handoff. That raises the bar: it has to be clear enough to act on with no live follow up.
Step 1: Pick one log and one format
Scattered notes are the first thing that breaks a distributed team. If Sarah keeps decisions in a doc, Alex keeps them in chat, and the third office keeps them in tickets, no one can find the whole picture. Agree on one log, in one place, with one set of fields. It does not matter much which tool. It matters a great deal that there is only one.
Keep the fields short so busy people in every zone will actually fill them: what was decided, who decided, who approved, why, status, and a link to the source.
Step 2: Write in each other's absence
The whole point of the log is to speak for you while you are offline. So write each entry as if the reader cannot ask you anything, because they cannot. Spell out the reason. Name the approver. Avoid shorthand that only makes sense if you were in the room. A good test: would someone in the third office, coming online hours from now, understand this without a single reply from you?
Step 3: Use time stamps everyone can read
"Let's decide tomorrow" means three different days across three zones. Write dates and times in a form that does not depend on where you sit. A full date and a fixed reference like UTC removes the guesswork. When a decision has a deadline, write the deadline in that same neutral form, so no one is off by a day.
Step 4: Make handoffs explicit
The riskiest moment is the gap between zones, when work passes from one waking team to the next. Close each of your days by noting what is decided, what is still open, and what the next person can move on without you. Sarah in Tokyo ends her day where Alex in Amsterdam begins his. If her last entry says clearly what is settled and what is not, Alex starts with answers instead of a queue of questions aimed at someone asleep.
Step 5: Separate proposed from decided
Distributed teams get burned when someone treats a maybe as a yes. A status field fixes this. Mark each entry proposed, decided, or reversed. A proposal waiting on the third zone should never read like a settled call. When the approver comes online and agrees, the status flips to decided, and everyone downstream can trust it.
A handoff that works, start to finish
Picture one decision crossing all three zones. Sarah in Tokyo proposes moving a database migration to the weekend. She logs it: decision stated, her name as owner, status proposed, reason written out, and a note that it needs the platform owner's sign-off. Then she logs off.
Alex in Amsterdam comes online, reads the entry, and adds the two risks he sees in the comments. He does not change the status, because it is not his call to approve. He just adds context and moves on. Hours later, the platform owner in the third zone reads the entry and Alex's notes, agrees, and flips the status to decided with a one line reason. By the time Sarah is back, the decision is settled, the reasoning is on the page, and no one waited on a live meeting. Three people in three zones made one clean decision without ever being awake together.
What to do when the log and reality disagree
Sometimes work moves faster than the log, and someone acts on a decision that was still marked proposed. Do not scold. Fix the record first: update the status, note who actually made the call, and add why it moved ahead. Then, if there is a real gap, raise it. The log is only trusted if it matches what happened, so keeping it honest matters more than keeping it tidy. A wrong status that no one corrects teaches the team to stop trusting the log, and once that trust is gone across time zones, you are back to waiting on people.
Step 6: Review on a rotation
Give the log a light weekly review, and rotate who does it across the three zones. This does two things. It catches stale entries before someone acts on them, and it keeps every office fluent in the log rather than leaning on one owner in one zone. When the reviewer changes hands with the sun, no single time zone becomes the bottleneck.
What good looks like
You know the log is working when a teammate coming online can answer their own decision questions from it, without pinging anyone and without waiting for a morning that is hours away. The measure is not how complete the log looks. It is how rarely someone has to wait for a person to get an answer that is already on record.
Where StandIn helps
A well kept log answers questions, but only if the asker knows to open it and can find the right entry. StandIn closes that last gap. You write one short brief at the end of your day, and while you are off, it answers your teammates from what you wrote, with a source under each answer, and says so when the answer is not on record. Across three time zones, that means the person coming online gets a scoped, sourced answer in their own morning, instead of holding their work until yours.
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.