Time Zone Overlap: How Much a Team Needs
By Mark Fulton · 2026-09-16 · 12 min read
Most distributed teams need two to four hours of daily overlap, not six or eight. The number depends on one thing: how much of your work needs a live answer before the day ends. If decisions can wait until tomorrow morning, two hours is plenty. If a customer incident or a production deploy needs two people in the same conversation on the same day, you want three or four. Past four hours, extra overlap stops buying coordination and starts buying meetings, because a calendar will expand to fill whatever window you leave open. The real skill is not maximising overlap. It is deciding what is allowed inside it.
Every tool in this category answers the same question. You type in two cities, it draws a grid, it tells you the window is three hours. Useful, and then you are on your own. Nobody tells you whether three hours is enough, what should happen in them, or what to do when it is zero. That is the part worth writing down.
How much overlap does a distributed team need?
Start by counting the decisions, not the hours.
Over a normal week, how many times did somebody stop, wait, and lose the rest of their day because the person who could answer was asleep? Not "would have been nicer to talk live". Actually blocked, with nothing else to pick up. For most product teams that number is small, between zero and three times a week, because good written context removes almost all of it. For an on-call rotation, a live sales motion, or a support queue with an hourly SLA, it is several times a day.
That count maps cleanly onto an overlap target.
The decision tree:
Does any part of the work need a live answer on the same calendar day?
- No. Nothing breaks if a question sits overnight. You need zero to one hour of scheduled overlap. Run fully written. Keep one weekly live slot so people stay human to each other, and rotate whose evening it costs.
- Yes. Continue.
How often does that happen?
- A few times a month (a design review, a quarterly plan, an incident). You need one to two hours, and you do not need them every day. Two fixed days a week is enough, and everyone gets three clean days.
- A few times a week. You need two to three hours daily. This is where most product and engineering teams actually sit.
- Several times a day (live support, trading, on-call, agency work with client calls). You need four or more hours, or you need to stop treating it as one team and split the coverage into two regional pods with a handoff.
Whose day pays for the overlap?
- If the window sits inside normal working hours on both sides, you are done.
- If one side has to start early or finish late, that cost has to rotate or be paid for. A permanent 10pm call for the same person is attrition with a delay fuse.
What goes in the window?
- Whatever survives the test in the next two sections. Everything else moves out.
Notice what the tree does not ask: how many time zones you span. Two hours of overlap with a team that writes well beats six hours with a team that spends them reading a status list aloud. The Microsoft study of remote work's effect on collaboration among information workers, covering 61,182 US employees over the first six months of 2020, found that firm-wide remote work pushed communication toward asynchronous media and made collaboration networks more static and siloed. The shift to written work is the easy half. Keeping the network from siloing is the half your overlap hours are for.
What does the overlap actually look like for common city pairs?
Here is the arithmetic, done properly. Every row assumes a 09:00 to 17:00 local working day on both sides, and every offset is the one in force on 16 September 2026, when the United States and Europe are on daylight or summer time and Australia is not yet. That last clause matters and is the reason most overlap tables on the internet are wrong for part of the year.
| Pair | Daily overlap | Window (first city) | Window (second city) |
|---|---|---|---|
| San Francisco / New York | 5h | 09:00 to 14:00 | 12:00 to 17:00 |
| San Francisco / Mexico City | 7h | 09:00 to 16:00 | 10:00 to 17:00 |
| New York / Sao Paulo | 7h | 09:00 to 16:00 | 10:00 to 17:00 |
| New York / Buenos Aires | 7h | 09:00 to 16:00 | 10:00 to 17:00 |
| New York / London | 3h | 09:00 to 12:00 | 14:00 to 17:00 |
| New York / Lagos | 3h | 09:00 to 12:00 | 14:00 to 17:00 |
| New York / Berlin | 2h | 09:00 to 11:00 | 15:00 to 17:00 |
| London / Cape Town | 7h | 09:00 to 16:00 | 10:00 to 17:00 |
| London / Sao Paulo | 4h | 13:00 to 17:00 | 09:00 to 13:00 |
| Berlin / Bengaluru | 4.5h | 09:00 to 13:30 | 12:30 to 17:00 |
| London / Bengaluru | 3.5h | 09:00 to 12:30 | 13:30 to 17:00 |
| London / Singapore | 1h | 09:00 to 10:00 | 16:00 to 17:00 |
| San Francisco / Sydney | 1h | 16:00 to 17:00 | 09:00 to 10:00 next day |
| New York / Bengaluru | 0h | none | none |
| New York / Sydney | 0h | none | none |
| Berlin / Sydney | 0h | none | none |
Three things fall out of that table.
The Americas are one working day. San Francisco to Buenos Aires, New York to Sao Paulo, San Francisco to Mexico City: all five to seven hours, no early starts, no late calls. If overlap is the constraint on your hiring, this is the cheapest fix available.
Europe to India is the workable long-haul pair. Three and a half hours from London, four and a half from Berlin, entirely inside both sides' normal hours. The US to India equivalent is zero on a strict nine-to-five, which is why teams that span those two end up with a standing 8am Eastern or 9pm India slot. We worked through that specific case in best meeting times for US and India teams.
Anything to Australia from the Northern Hemisphere is effectively zero, and it stays zero in September because Australia has not turned its clocks forward yet.
Those offsets shift on four different dates a year. The United States runs daylight time from the second Sunday in March to the first Sunday in November, which in 2026 means 8 March to 1 November per NIST. The European Union's summer time runs from the last Sunday in March to the last Sunday in October under Directive 2000/84/EC. New South Wales starts daylight saving on Sunday 4 October 2026. Those three rules do not line up, so an overlap window computed today is wrong for several weeks in spring and autumn. The mechanics of that drift, and what it does to a standing invite, are in daylight saving and recurring meetings.
What work genuinely requires live overlap?
Four categories, and the list is shorter than most calendars suggest.
Anything with an unknown shape. A problem nobody has framed yet, where the first ten minutes are spent working out what the question is. Writing that down takes longer than talking it through, because you cannot write the summary until you already understand it.
Anything where disagreement is likely and cheap to resolve out loud. Two engineers who want different approaches will burn four asynchronous rounds and a day and a half on a thread. Twenty minutes live settles it, and one of them writes the decision down afterwards.
Anything with real-time state. An incident in progress, a deploy going sideways, a customer on the line. The facts change while you type.
Anything where the relationship is the point. Onboarding a new hire, a hard performance conversation, the first call with a new counterpart. Tone does not survive a document.
If a piece of work is not in one of those four buckets, it does not have a claim on the overlap.
What should never take an overlap slot?
Status. If the meeting exists so people can say what they did, it is a document. Written status also gets read by the people who could not attend, which is the entire point of a distributed team.
Information broadcast. Roadmap readouts, all-hands, announcements, demos. Record them. A recording is better than the live version for everyone in the wrong time zone and for everyone who joins next quarter.
Work that one person could do alone. Watching someone else code, write, or design is not collaboration. It is an audience.
Meetings without a written question at the top. If nobody can state the decision the meeting is meant to produce, the meeting is a placeholder, and placeholders are exactly what eats a two-hour window.
Anything that could be a comment on a document. Reviews, approvals, feedback rounds. These are the natural home of written work and they get worse when rushed into a live slot.
The pattern underneath all five: the overlap is for the work that needs two brains at once. Everything else needs two brains, in sequence, with good notes in between.
How do you protect the overlap from meeting creep?
Left alone, the window fills. Four things that hold the line.
Name the window and publish it. "Core hours are 14:00 to 17:00 UTC" written in one place beats everyone inferring it from calendars. Give it a name people can say out loud.
Cap it. Decide the fraction of the overlap that can be booked. Half is generous, a third is better. The rest is for the unplanned conversation that is the actual reason overlap exists. If somebody has to book a slot to ask a quick question, the window is already full.
Require a written question on every invite. Not an agenda. One sentence naming the decision the meeting will produce. Invites that cannot pass this test usually delete themselves before anyone has to say no.
Put a standing block on the calendar. Not a meeting, a block, so the window looks occupied by default and someone has to actively take it. If you already run your own day in blocks, this is the same move applied to the team. Our guide to time blocking your day covers the individual version, and the time blocking planner will lay out the team window the same way.
Review the booked fraction once a month. It only ever drifts upward.
How do you hire against a time zone constraint?
Decide the constraint before you open the role, and write it as a window rather than a country.
"Must overlap 14:00 to 17:00 UTC" is a real requirement that a candidate can answer honestly. "Must be in Europe" is a proxy that rules out a Lagos-based candidate with a perfect three hours against New York and admits a Lisbon-based one who wants to work a Portuguese evening. From the table above, Lagos and London have identical overlap with New York. A country filter cannot see that; a window can.
Two further rules worth holding to.
Build redundancy at the edges. If exactly one person in a region can answer a given class of question, your overlap is one illness away from zero. Two people with partial coverage beat one with perfect coverage.
Be honest in the job description about who pays. If the role requires a 7am start or a 9pm call, say so on the posting. Candidates will accept it. What they will not accept is discovering it in month two.
How do you keep everyone's local hours visible?
Most overlap failures are not arithmetic failures. They are somebody forgetting, at 5pm on a Thursday, that 5pm for them is 11pm for the person they just pinged.
The fixes are boring and they work. Put the city and UTC offset in every profile. Write times in UTC in any written plan, or in both zones with the zone named, never "3pm" on its own. And keep a clock for each region somewhere a person actually looks, on a second monitor or a pinned tab, so the other side's local time is a glance rather than a calculation.
For the underlying model of offsets, UTC and why the arithmetic changes twice a year, we wrote up time zones, UTC and DST explained. The definitive record of every zone's rules and every historical change is the IANA Time Zone Database, which is what your operating system, your calendar and this site are all quietly reading from.
Put your whole team on the world clock. Four cities are free with no signup and no account. Add labels and unlimited cities with Pro if your team spans more than that.
Frequently asked questions
How many overlap hours do remote teams need?
Two to four for most teams. Two is enough when decisions can wait overnight and the team writes well. Three to four when live support, on-call, or fast-moving client work means someone gets blocked several times a week. More than four is rarely a coordination requirement and usually just makes room for meetings. Count how often people were genuinely blocked last week and size the window to that number.
Can a team work with zero overlap?
Yes, and several well-known companies run this way, but zero overlap is a discipline rather than a default. It requires decisions written down in full rather than summarised, a norm that nobody is expected to reply within the day, ownership clear enough that work rarely needs a second person to proceed, and one live slot a week or a fortnight that rotates so the same person is not always awake at midnight. Zero overlap fails when a team keeps the synchronous habits and just removes the hours.
What should you do in overlap hours?
Unframed problems, live disagreements, anything with changing real-time state, and anything where the relationship matters more than the information. Keep status, broadcasts, demos, document reviews and approvals out of it. A useful rule: if a decent written summary would have done the job, it should have been written.
How do you handle a team spread across three continents?
Stop trying to find a window that includes all three, because on a strict nine-to-five it usually does not exist. New York to Berlin is two hours and Berlin to Bengaluru is four and a half, but all three together is close to nothing. Run overlapping pairs instead. Each region shares real hours with one neighbour, decisions get written down inside those hours, and the third region picks them up on its own morning. Work moves around the world in a chain rather than waiting for a moment when everyone is awake at once. Reserve the all-three call for a monthly or quarterly slot, rotate whose evening it costs, and record it.