⚡The short version: the overlap math
Every time-zone decision reduces to one number: how many hours per day both teams are working and reachable at the same time. Raw offset is not that number — a nine-hour offset sounds fatal until you realize that 8:00 AM in New York is 5:30 PM in India, which is a perfectly usable ninety-minute window if both sides protect it.
The table below shows realistic daily overlap for common pairings, assuming standard working hours with modest flexibility at the edges. As of writing these offsets are accurate, but daylight-saving transitions shift several of them by an hour twice a year — verify before committing a team to a schedule.
| Pairing | Typical offset | Realistic daily overlap | What the window is good for |
|---|---|---|---|
| US West – US East | 3 hours | 4–5 hours | Full synchronous collaboration if wanted |
| US East – UK / Western Europe | 5–6 hours | 3–4 hours | Daily standup, pairing, live reviews |
| US East – Eastern Europe | 6–7 hours | 2–4 hours | Standup plus one focused working block |
| US East – India | 9.5–10.5 hours | 1–2 hours | One daily sync plus async everything else |
| US West – India | 12.5–13.5 hours | 1 hour at the edges | Handoff-style work; meetings need one side flexing |
| US – Australia | 14–17 hours | 0–1 hour | True follow-the-sun or email-class async only |
The viable pattern is not "how big is the offset" but "what work requires synchrony". Architecture debates and incident response need overlap; feature implementation does not. Staff the synchronous work into the window and let everything else go async.
🧮Doing the overlap math honestly
Teams routinely overestimate overlap by counting theoretical hours instead of protected hours. A two-hour theoretical window becomes zero usable hours if it lands during one side lunch, gets consumed by recurring meetings with other stakeholders, or is treated as bookable time by everyone in the company. The honest calculation: take the raw overlap, subtract standing commitments, and see what is actually left for your team.
Then assign the window a job. The strongest pattern is a fixed daily anchor — a twenty-to-thirty-minute sync at the same time every day, plus a reserved "golden hour" twice a week for anything that needs live discussion: design reviews, planning, retrospectives. Everything that lands outside the window by default becomes a written artifact instead of a request to flex someone evening.
Finally, distribute the flexing fairly. If the same engineers take every 7 AM or 9 PM call, you have built an attrition machine. Rotate the burden, put it in writing, and treat chronic violation of the policy as a management failure rather than a personal inconvenience.
✍️Async-first practices that actually work
Async-first is a writing discipline, not a tool purchase. The teams that make it work share a small set of habits: decisions are made in documents, not in calls; status lives in the tracker, not in someone memory; and a message is expected to contain everything the reader needs to act without a follow-up round-trip. That last habit — complete messages — is the single highest-leverage behavior, because a vague "can we talk about the API change" costs a full day at a nine-hour offset.
The practices that consistently hold up: written RFCs for anything architectural, with a comment window and a decision owner; short recorded walkthroughs for anything visual, which replace most "let me show you" meetings; a decision log that records what was decided, by whom, and why, so the team eight hours away wakes up to context instead of surprises; and explicit response-time norms, so people know whether an unanswered message means "thinking" or "never saw it".
The practice that does not work is async theater — tools installed, habits unchanged. If the lead still makes decisions in calls and announces them verbally, the documents become archaeology. Async-first has to start with whoever has the most authority, or it does not start at all.
Complete messages
Every request includes context, the decision needed, the options considered, and a deadline. Round-trips are the tax; completeness is the deduction.
RFCs for architecture
A short document, a 48-hour comment window, a named decision owner. Slower for one day, faster for the whole project — and the reasoning is preserved.
Recorded walkthroughs
A five-minute screen recording beats a meeting for demos, design reviews, and bug reports, and it can be watched at 1.5x by the person eight hours away.
A decision log
One running document of what was decided and why. The cheapest insurance against relitigating settled questions across the offset.
Response-time norms
Written expectations per channel: chat within a working day, RFC comments within 48 hours, incidents immediately. Ambiguity here reads as silence or urgency, and both are corrosive.
🤝Handoff protocols: where distributed teams live or die
A handoff is the deliberate transfer of in-progress work across the offset, and it is the highest-friction moment in any distributed team. Done well, the receiving engineer starts productive work in minutes. Done badly, they spend their morning reconstructing context, and the theoretical speed gain of two shifts evaporates into "what did you mean by this" messages.
The protocol that works is short and rigid: before logging off, the outgoing engineer leaves a handoff note on the active ticket with the current state, the next concrete action, anything that is blocked and why, and a pointer to the branch or draft. The note is written for a stranger — assume the reader has none of the day context. The receiving engineer first act of the day is reading handoffs, and questions go on the ticket, not into a private chat, so the answer is visible to the next shift.
Two rules keep it honest. No work without a ticket — unwritten work cannot be handed off. And no silent takeovers — if the receiving engineer changes direction on someone work, they write why, so the original owner is not surprised twelve hours later. These rules feel pedantic for a week and then become the reason the team trusts the process.
Measure your handoff quality with one number: how often the receiving engineer ships forward progress without needing a synchronous answer. If that number is high, your documentation culture is real. If it is low, no tool will save you.
📅Meeting discipline across the offset
Meetings are the most expensive artifact on a distributed team because they consume the scarcest resource — overlap hours. The discipline is a simple budget: decide how many overlap hours per week the team has, treat them as a finite currency, and spend them only on work that genuinely requires synchrony.
The tests for "requires synchrony" are stricter than most teams apply. A status update does not require it — that is what the tracker is for. A decision that can be made in an RFC with a comment window does not require it. What does: conflict that has stalled in writing, design sessions where the shared whiteboard is the medium, incident response, retrospectives, and the human connection that keeps a team from becoming a ticket-processing queue. The last one is real — budget for it deliberately rather than pretending it is free.
| Meeting | Cadence | Length | Keep or kill |
|---|---|---|---|
| Daily sync in the overlap window | Daily | 20–30 min | Keep — the anchor of the whole system |
| Written standup in the tracker | Daily | 5 min to write | Keep — replaces most status talk |
| Design review / golden hour | 2× per week | 60 min | Keep — the highest-value synchronous block |
| Sprint planning | Biweekly | 60–90 min | Keep, with pre-reads mandatory |
| Retrospective | Biweekly | 45 min | Keep — distributed teams degrade silently without it |
| Recurring status meeting | Weekly | 60 min | Kill — replace with a written weekly summary |
| All-hands with both shifts live | Monthly | 60 min | Reduce frequency, record always |
🧰Tooling: less than you think, stricter than you think
Distributed teams do not fail from missing tools; they fail from inconsistent use of ordinary ones. The stack below is deliberately boring. What matters is that each tool has one job, everyone uses it the same way, and the written artifacts live where the next shift will look for them.
| Category | Job it does | The discipline that matters |
|---|---|---|
| Issue tracker | Single source of truth for all work | No work without a ticket; status current at end of day |
| Chat | Fast questions, social glue, alerts | Not a decision archive — decisions get written up elsewhere |
| Docs / RFC space | Decisions, designs, runbooks | Comment windows and decision owners on everything |
| Code review | Async review across the offset | Review SLAs so nobody waits a full day for an approval |
| Recorded video | Walkthroughs, demos, bug reports | Default for anything visual; meetings are the exception |
| Time-zone overlay | Scheduling sanity | Book inside the overlap; flexing rotates and is visible |
🌅Follow-the-sun: the myth versus the reality
The follow-the-sun pitch is seductive: one shift hands work to the next, development continues around the clock, and the product ships twice as fast. It is the most oversold idea in distributed work. What the pitch ignores is that engineering is not an assembly line — the handoff between shifts is lossy, and the loss scales with how interdependent the work is. Two teams working on the same tightly-coupled feature across a twelve-hour offset do not go twice as fast; they go slower than one team, plus coordination cost.
Where follow-the-sun genuinely works is work that partitions cleanly: QA running test cycles on code the day shift froze, DevOps and on-call coverage where the night region owns the alert queue, support tiers, and well-specified standalone modules with stable interfaces. The common property is a crisp boundary — the receiving shift executes against something defined rather than co-creating something ambiguous.
The honest framing for a product team: you are not buying twice the speed, you are buying longer daily coverage and faster turnaround on certain classes of work, at the price of rigorous handoff hygiene. Teams that internalize that framing get real value. Teams that believe the two-times-speed story reorganize around it, miss the expectation, and conclude that distributed teams do not work — when what did not work was the story.
Dedicated teams built around real overlap, not sales claims
If a vendor pitches follow-the-sun as a velocity multiplier on tightly-coupled product work, treat it as a sales claim, not an engineering plan. Ask which specific work streams partition cleanly, and structure the engagement around those.
⏱️The management overhead, stated honestly
Distributed teams cost more management effort than co-located ones, and pretending otherwise is how budgets and patience get blown. The overhead is not a defect — it is the price of the access and cost advantages that motivated the distribution in the first place. The mistake is not paying the price; it is being surprised by it.
In our delivery experience, the steady-state overhead lands in these ranges. None of these are measured industry statistics — they are observed ranges from running distributed teams since 2018, and your numbers will vary with team maturity and offset size.
See how our dedicated teams run across time zonesDedicated team cost: the real monthly math
| Overhead item | Typical cost | Notes |
|---|---|---|
| Writing and maintaining handoffs / docs | 30–60 min per engineer per day | Highest at first; drops as the habit forms |
| Coordination and planning by leads | 4–8 hours per lead per week | A distributed lead is a part-time program manager |
| Longer decision latency | Hours to a day per cross-offset decision | RFC windows and decision owners cap the damage |
| Onboarding a new team member | 1.5–2× co-located time | Documentation quality is the lever |
| Travel / periodic co-location | Quarterly or twice-yearly meetups | Expensive per event, cheap per unit of trust built |
Budget the overhead before you sign anything. A distributed team that saves 40 percent on rates and costs you an unmanaged coordination burden is not a savings — it is a deferred invoice. A well-run one, with the practices in this article actually enforced, is the strongest resourcing model most product companies have access to.