How much time-zone overlap does a distributed team need?

Every distributed engagement eventually produces the overlap question, and it is usually answered with a number of hours. The number matters less than what the overlap is being used for — four hours spent in meetings is worth less than ninety minutes spent unblocking people.

What overlap is actually for

Three things genuinely need people awake at the same time:

• Unblocking.Someone is stuck and the answer lives in another person’s head. This is the highest-value use of overlap by a wide margin, because the alternative is a day lost per question.
• Decisions with several viable options.Written exchange is good at conveying a decision and bad at making one where the trade-offs are live.
• Incidents.Anything happening now.

Everything else — status, progress, handover, review, most planning — is better in writing, and is frequently better because the team is distributed, since writing it down leaves an artefact that a meeting does not.

So how much

Two to three hours is enough for most engineering work, provided the team writes things down. Below about two hours the unblocking loop starts to fail: a question asked at the end of the window waits a full day for its answer, and a stuck person costs far more than the overlap would have.

Closely coupled work — a pair debugging a live problem, a team in the discovery phase of something ambiguous — wants more, perhaps four. Well-separated work with clear interfaces can run on an hour, or on none.

India and the UK give roughly four and a half hours of natural overlap on standard hours, which is comfortable. India and the US east coast gives two to three with a modest shift on one side. India and the US west coast requires someone to shift meaningfully, and pretending otherwise produces a rota that quietly burns people out.

Spend the window well

The common failure is filling the overlap with ceremonies, so the only hours where people can help each other are spent listening to status updates.

• Put the standup at the very start or the very end of the window, not the middle. The middle is the most valuable part and a meeting cuts it in half.
• Keep a shared list of blockers visible before the window opens, so it starts with the questions rather than with working out what they are.
• Do reviews asynchronously. A code review does not need both people present; a design disagreement does.
• Protect the window. If it is the only time people can reach each other, it should not be where the all-hands is scheduled.

Making the non-overlapping hours productive

The offset is only a cost if work stops when the other side sleeps. What prevents that:

• Work sliced so each person has a full day of it.Enough to proceed without needing an answer mid-way. A planning decision made at the start of the day, not a property of the team.
• Decisions written down where they can be found.A short decision record answers tomorrow’s question without waking anyone.
• A second thing to switch to when the first is blocked.Explicitly assigned, not improvised.
• Access to everything needed.An environment that requires someone else to grant something is a half-day stall every time.

The handover habit

The most reliable practice in distributed teams is also the dullest: each side writes a short note at the end of their day. What moved, what is blocked, what the other side should pick up. Five minutes, and it converts the offset from a gap into a relay.

Teams that do this well often find the offset is a net advantage on incident work — something broken at the end of one day is being looked at while the first team sleeps.

Be honest about who is shifting

If the arrangement requires one side to start at seven or finish at ten, say so in the engagement rather than letting it happen informally. Unacknowledged shifted hours are a leading cause of turnover on distributed teams, and turnover costs far more than the overlap was ever worth.

Our staff augmentation engagements state the overlap window and who is shifting to create it, because it is a working condition rather than a scheduling detail. If your requirement needs more overlap than the geography naturally gives, that is a conversation worth having before the contract rather than after.