ASYNC WORK GUIDE • 9 MIN READ

How to Write a Decision Doc That Survives a 12-Hour Time Zone Gap

Published September 26, 2026 by SyncHours Team

A decision made in a live meeting has a quiet assumption baked into it: everyone who should weigh in is either in the room or can be scheduled into one. That assumption fails once a team spans a real time zone gap — someone is always asleep for whatever slot the meeting lands on, which leaves two bad options: exclude them from decisions that affect their work, or let scheduling the meeting itself become the bottleneck. A decision doc with a defined structure and a real deadline replaces the meeting entirely for most decisions, not just the parts that happen to be schedulable.

The four parts

  1. Context. What's actually being decided and why now — enough background that someone reading cold, with no meeting to fill in gaps, understands the stakes.
  2. Options. Every option seriously considered, with the real tradeoffs for each — not a strawman list where one option is obviously correct. If people can't see what was ruled out and why, they'll re-litigate it in the objection window instead of engaging with the actual recommendation.
  3. Recommendation. A specific, named choice — not "thoughts?" A decision doc that doesn't recommend anything isn't a decision doc, it's a discussion prompt, and discussion prompts don't have deadlines.
  4. Deadline to object. An explicit date and time, in a zone-neutral format, after which the recommendation ships by default unless someone raised a substantive objection before then. This is the part that actually replaces the meeting — it converts "everyone must agree live" into "anyone can object async, and silence is consent."

A worked example

A team with an engineering lead in San Francisco and a new hire in Singapore needs to decide whether to shift core hours to gain more overlap — the exact scenario the hiring across time zones framework flags as a real tradeoff once a role scores high enough to need it. Here's the doc:

Context: We hired a backend engineer in Singapore (SGT, UTC+8). Our current core hours are 9am–6pm PST, which gives zero working-hours overlap with Singapore — see the PST/SGT pairing. She's been joining calls at 9–10pm her time for a month, which isn't sustainable long-term.

Options considered:
(a) Leave core hours as-is, accept she stays mostly async — low disruption to the existing team, but she's excluded from real-time collaboration almost entirely.
(b) Shift the whole team's core hours 3 hours earlier (6am–3pm PST) — recovers a real overlap window with Singapore, but pushes early risers among the existing SF team into a 6am start.
(c) Add a single fixed overlap meeting at a fringe hour for both sides, rotated per the fair rotation formula, without changing anyone's core hours.

Recommendation: Option (c). A full core-hours shift optimizes for one hire at real cost to five existing team members; a single well-placed, rotated touchpoint gets most of the collaboration benefit without that cost.

Deadline to object: If no objection is raised by Friday, October 2, 2026, 6pm UTC, we'll implement (c) starting the following Monday.

Every person on the team, regardless of time zone, gets at least one full working day inside that window to read it and respond — which is the actual design constraint behind the deadline, not an arbitrary date.

How long the objection window should actually be

Size the window to the widest gap on the team, not to how urgent the decision feels. A team entirely within a 5-hour spread can reasonably use a 24-hour window — everyone gets a working day inside it. A team with a 12+ hour spread, like the example above, needs closer to 48–72 hours, because a single 24-hour window can land entirely inside one person's weekend or rest hours depending on when it opens. Rushing the window to match how urgent the decision feels defeats the purpose — it just re-creates the exclusion problem the doc was supposed to fix, on a delay instead of live.

Where this breaks down

  • No named decision owner. If objections come in and conflict with each other, someone has to actually own the final call — state who that is in the doc up front, before objections arrive, not after.
  • The deadline isn't enforced. If a missed deadline quietly turns into "let's just get on a call," the doc was theater — the entire value is in actually shipping the default when the window closes.
  • Objections without alternatives. "I disagree" isn't an objection a decision owner can act on — a real objection names what's wrong with the recommendation specifically, or proposes a different option.

Not every decision belongs in this format — genuinely exploratory conversations, where nobody has a recommendation yet, need a different tool (a working doc, or an actual synchronous discussion with whoever's available). This is specifically for decisions where someone already has enough context to recommend something and just needs a real, time-boxed way to surface disagreement without a meeting. Pair it with an async standup for day-to-day unblocking, and this for anything bigger than a single-person blocker.