How much timezone overlap do you actually need?
Most companies buy more overlap than they use. Full working-day overlap sounds safe, costs a location premium, and then gets spent on a standup and a handful of messages that could have been written down. The useful question is not how many hours overlap, it is which specific activities in your week fail without a live conversation, because that list is shorter than it feels and it is the only thing overlap actually buys.
What genuinely needs synchronous time?
Four things: unblocking, decisions with more than two plausible answers, incident response, and the first weeks of a new person's tenure. Everything else in normal software delivery works asynchronously, often better, because writing forces precision that a call lets you skip.
Unblocking is the big one and it is time-sensitive rather than time-consuming. An engineer who hits an ambiguity at the start of their day and cannot resolve it until tomorrow loses a day. The same engineer with two hours of overlap loses twenty minutes. This is why the shape of the overlap matters more than its length: two hours at the start of their day is worth more than four hours at the end.
Decisions need live time when the options are genuinely balanced and someone has to weigh them out loud. Written decision-making handles the clear cases well and stalls on the ambiguous ones, which is exactly what you should spend overlap on.
What breaks when overlap is too small?
Cycle time on questions, first and most visibly. With under two hours of overlap, a single clarification can cost a full working day, and a chain of three clarifications costs most of a week. The work does not get worse, it gets slower in a way that is easy to blame on the team rather than on the arrangement.
Then incident response. If your production system needs a human within an hour and nobody on the team is awake, the arrangement has a gap that no amount of process closes. This is a genuine reason to require overlap or to buy a specific on-call arrangement, and it is a different requirement from daily collaboration.
The subtler failure is decision drift. When a team cannot cheaply ask, they guess, and reasonable guesses accumulate into a system that is slightly not what you wanted. Nobody notices for a month. The symptom is a demo where several small things are wrong in ways nobody objected to earlier, and the cause is almost always that asking was expensive.
| Overlap | Works for | Struggles with | What it needs to work |
|---|---|---|---|
| Under 2 hours | Well-specified, low-ambiguity work streams | Discovery, incidents, new joiners | Written specs ahead of time, a same-timezone decision maker on the team |
| 2 to 3 hours | Most ongoing product development | Same-day incident response | Overlap placed at the start of the team's day, not yours |
| 4 to 5 hours | Discovery, pairing, heavy stakeholder involvement | Little, at a cost premium | Discipline to not fill it with meetings |
| Full day | Incident-critical systems, embedded teams | Budget, and the talent pool it excludes | A genuine reason, tested against the calendar |
| None, follow-the-sun | Bounded, queue-shaped work such as triage or QA | Anything requiring judgement | Rigorous handover notes and clear ownership boundaries |
Where should the overlap sit in the day?
At the start of the remote team's working day, not the end of yours. This single choice does more for throughput than adding an hour, because it means questions raised during their day get answered while they can still act on the answer.
The common arrangement gets this backwards. A European team overlapping with a US client at the end of the European day means anything asked in the European morning waits until the following morning, which converts a two-hour delay into a twenty-four-hour one. Shifting the same overlap earlier costs nobody anything and removes most of the pain people attribute to distance.
It also decides where meetings go. Put the standup or sync at the beginning of the overlap window so the rest of it stays free for the ad hoc conversations that are the actual point. Overlap consumed entirely by scheduled meetings provides none of the unblocking value it was bought for.
How do you work well with little overlap?
By moving decisions ahead of the work rather than into it. Tickets that carry the acceptance criteria, the edge cases and the answer to the obvious question remove most of the need to ask. This is more work for whoever writes them, and it is the trade that makes low overlap viable.
Push decision authority into the team's timezone. Someone on their side must be allowed to make the small calls, with a stated boundary for what needs you. If every ambiguity escalates, the timezone gap becomes the throughput limit no matter how good anyone is.
Then make the handover explicit. An end-of-day written summary of what moved, what is blocked and what decision is needed turns an overnight gap into a queue rather than a stall, because the answer is waiting when they arrive. Teams that do this well often outperform colocated ones on decision quality, because the reasoning is written down and can be checked later.
Does follow-the-sun development work?
For a narrow class of work, yes: anything queue-shaped where a task can be picked up, completed and handed off without needing the previous person's reasoning. Support triage, test execution, monitoring and some data operations fit this shape and genuinely benefit from continuous coverage.
For feature development it usually does not, because handing partly finished thinking between people costs more than the extra hours gain. The idea that a feature is worked on around the clock assumes the constraint is hours available, and the constraint is almost always shared understanding.
There is a legitimate hybrid: one timezone builds while another handles operations and support for the same system. That splits by responsibility rather than by shift, which is the version that holds up, and it is worth being explicit that this is what you are buying rather than describing it as round-the-clock development.
How do you measure your real requirement?
Look back at two weeks of your own calendar and message history and mark every interaction with engineering that genuinely needed to be live. Not the ones that were live, the ones that had to be. Most people find the total is under four hours a week, clustered in a couple of windows.
Then check the other direction: over the same fortnight, how many times did an engineer have to wait on an answer from your side, and how long did each wait last? If your own answers routinely take a day, timezone is not your bottleneck and buying overlap will not fix it.
Do this before shortlisting suppliers, because overlap is one of the largest constraints on where you can hire and therefore on rate. A requirement of four hours is usually satisfiable across a wide range of locations; a requirement of a full working day narrows the field sharply, and it should be a decision rather than a default.
Common questions
- How many hours of timezone overlap do you need with a remote team?
- Two to three hours covers most ongoing product development, provided that window sits at the start of the remote team's day so questions get answered while they can still act on them. Discovery work, heavy pairing and new joiners benefit from four or more. Full working-day overlap is usually bought as insurance, costs a location premium, and is rarely justified by what a fortnight of calendar history shows was genuinely synchronous.
- What time of day should the overlap window be?
- At the beginning of the remote team's working day. Overlap placed at the end of their day means anything they discover in their morning waits until the next day for an answer, turning a short delay into a full day of lost work. Moving the same window earlier costs nothing and removes most of the friction people attribute to distance. Keep scheduled meetings at the very start so the rest stays free for ad hoc questions.
- Can a development team work with no timezone overlap?
- For queue-shaped work such as support triage, test execution or monitoring, yes, because tasks can be picked up and completed without needing the previous person's reasoning. For feature development it rarely works, since the real constraint is shared understanding rather than hours available. If zero overlap is unavoidable, it requires written specifications prepared in advance and a decision maker inside the team's own timezone.
- What goes wrong when there is not enough overlap?
- Three things. Question cycle time stretches, so a chain of clarifications can consume a week. Incident response develops a gap that no process closes if nobody is awake when production breaks. And decision drift sets in, where a team that cannot cheaply ask starts making reasonable guesses that accumulate into a system slightly different from what was wanted, usually noticed a month later at a demo.
- Is follow-the-sun development a good idea?
- Only for work that hands off cleanly. Passing partly finished feature work between timezones costs more in lost context than the extra hours gain. The version that holds up splits by responsibility rather than by shift: one location builds, another operates and supports the same system. That is worth describing accurately in the contract rather than calling it round-the-clock development.
