Designing Timezone Overlap

Most distributed delivery arrangements treat timezone overlap as a given. The teams are where they are, the clocks are what they are, and the resulting window of shared waking hours is the constraint everyone works inside. Somebody books a daily call near the edge of it, someone else quietly stops attending, and over the following months a slow attrition of shared context sets in that nobody attributes to the calendar.

This is a design failure, and usually one on the buying side. Overlap is a quantity: you can increase it, move it, protect it or waste it. What you cannot do is leave it unspecified and expect it to land somewhere useful, because the default allocation is whatever the most senior person's calendar leaves over, which is reliably the worst available.

The two failure modes are symmetrical. Teams with too little overlap find that decisions take days, that ambiguity compounds silently, and that the remote team becomes an order-taker because asking a clarifying question costs more than guessing. Teams that spend all of their overlap on synchronous status reporting have recreated a co-located communication pattern across a gap that cannot support it, and their engineers at the far end of the day are permanently tired. So the useful question is not how many hours you overlap. It is what you spend them on.

What overlap is actually for

Overlap has four legitimate uses. Everything else can and should move out of it.

Decisions with real ambiguity. Not decisions in general — decisions where the options are not yet enumerated, the trade-offs are contested, or the right answer depends on tacit context nobody has written down. These converge far faster live than in a thread, because the expensive part is the framing rather than the choice, and framing is iterative. A decision that can be stated clearly enough to write down can almost always be made asynchronously.

Pairing and deliberate knowledge transfer. Two people on the same problem at the same time is the highest-bandwidth mechanism available for moving tacit knowledge, and the most effective defence against the context loss that erodes distributed teams over quarters. This is the use of overlap cut first and the one that should be cut last.

Incident response. When production is broken, serialised communication is intolerable: you need the people who understand the system and the people who can authorise action in the same conversation. Unlike feature work, this is a use where geographic spread is a straightforward asset.

Relationship maintenance. Unstructured time where people who work together speak to each other as people. This sounds like the soft item and is load-bearing: the willingness to ask a slightly embarrassing clarifying question prevents most rework, and it decays across distance without maintenance.

Notice what is absent. Status is absent — and progress reporting, round-robin ceremonies and demos to stakeholders who could watch a recording are the default consumers of overlap in most organisations. An arrangement that spends its four shared hours on a standup, a planning session and a governance call has spent the entire budget on the lowest-value category.

Activity	Needs overlap	Why
Framing an ambiguous decision	Yes	The options are not yet known; iteration is the point
Choosing between stated options	No	Write them down, set a deadline, decide in the thread
Pairing on hard code	Yes	Tacit knowledge transfer has no async equivalent
Code review	No	Serialised by nature; latency is the only cost
Live incident	Yes	Serialised communication is intolerable under time pressure
Sprint demo or daily status	No	Record or write it; questions go to a thread
Onboarding a new joiner	Yes, heavily	Front-load it; the cost of skimping compounds for months

Follow-the-sun is mostly a myth for feature work

The promise is seductive: three teams, eight hours apart, work moving around the globe without stopping, a three-fold speed-up for no additional headcount. It does not work this way for feature development, and the reason is structural rather than cultural. Handing off partially completed intellectual work costs in proportion to the context nobody has written down, and in feature work the unwritten context is most of it: the approaches already tried and abandoned, the reason the obvious solution does not work, the thing someone noticed in the logs at four o'clock and has not yet explained. Transferring that costs an hour at each end, so you have spent two hours of your eight-hour gain before anyone writes a line of code. Do it twice a day and follow-the-sun is slower than one team working normal hours. Continuous handoff also means nobody holds an unbroken thread of thought for long enough to solve a hard problem.

Where it genuinely works is where the unit of work is small, self-describing and arrives in a queue: production support, triage, monitoring, on-call rotation, operational toil. Here the context is in the ticket and the system rather than in someone's head, and the benefit is real. An engineer in Bengaluru picking up an alert at two in the afternoon local time, rather than a London engineer being paged at two in the morning, is better for everyone involved, and it is a legitimate and humane reason to run a distributed operation.

Designing the handover artefact

Where handover is genuinely needed — support rotations, an escalation crossing regions, a piece of work that must move — the artefact is the mechanism, and it should be a designed deliverable with a defined shape rather than a courtesy note. A handover that works contains the current state of the world rather than a summary of activity: what is broken or at risk right now and who is affected; what was attempted and what the attempt showed, including the approaches ruled out and why; what the next person should try first and what the fallback is; the open questions with a name against each; and anything that becomes urgent within twelve hours if nobody touches it. Written before the handing-over engineer leaves, not after. Ten minutes, in a durable place, in the same structure every time — because a consistent template means the receiving engineer knows where to look, which drops the read cost to a minute or two, whereas an unstructured narrative has to be read in full every time.

The eleven-hour question

This is the cost model that should govern every overlap decision you make. An engineer hits an ambiguity. It is small — the specification does not say what happens when the field is empty. They could guess. Instead they ask, in the right channel, tagging the right person. That person is asleep. Eleven hours later, they answer.

Count what happened. The engineer either moved to other work, incurring a context switch in each direction, or guessed, incurring a risk of rework that surfaces days later. Either way the original work queues for eleven hours, and if the answer generates a follow-up the cycle repeats and two days have gone on a question that would have taken forty seconds in a shared room. Scale that up: a team of eight hitting three such questions each per week generates two dozen cross-timezone blocking events, and even at half a day apiece that is a large fraction of the calendar spent waiting — invisible in every metric most organisations track, because nobody logs it and everybody looks busy. It is the queueing dynamic in why-busy-teams-are-slow-teams, with the waiting states created by geography rather than by work in progress.

The interventions follow from the model. Reduce the number of questions by improving specification quality at source and by pushing decision rights to the team doing the work, which is the highest-leverage change available. Reduce the cost of each by ensuring more than one person can answer it, so ambiguity is not hostage to one individual's sleep. Reduce latency by putting a deliberate answering window inside the overlap rather than hoping. And accept that some questions should be resolved by the team guessing well, which requires that they know enough about the intent to guess well.

Staggered core hours, and who pays

Four hours of overlap is roughly the point where a distributed arrangement stops feeling like two organisations. Two hours is workable if the work is genuinely well decomposed and the written culture is strong. Under two hours, the relationship becomes transactional regardless of anyone's intentions, because there is no room for anything beyond the most urgent synchronous traffic.

Between Western Europe and South Asia the natural overlap is comfortable — afternoons in Bengaluru against mornings in London — which is one reason that corridor works well. Between North America and South Asia it is not, and somebody has to shift. Who shifts is not a logistical detail; it is the clearest signal your organisation sends about whether the distributed team is a partner or a supplier.

The defensible answer is that the cost is shared and rotated. If the client-side team never moves an hour and the delivery team routinely works until nine in the evening, you have designed a hierarchy and everyone can see it. Attrition follows, and attrition is how context loss actually happens. Rotate the inconvenient slot between locations on a published schedule, move it between individuals so nobody carries the late shift indefinitely, and give the time back genuinely rather than notionally — a late call means a late start, enforced by the manager rather than left to the individual to claim.

A meeting budget

Treat overlap as a fixed budget, start from zero rather than from the existing calendar, and require every recurring synchronous meeting to justify its line. The test is one question: does this produce an output that could not be produced by writing, a recording and a threaded discussion with a deadline? If it could, but writing is more effort, the meeting still loses — that effort is paid once by the writer and saved many times over by the readers.

In practice a healthy distributed team spends its overlap on four things. A short live conversation each day covering blockers and coordination, capped at fifteen minutes and cancelled when nobody has anything. One longer working session per week for the ambiguous decisions and design arguments that have accumulated, agenda published in advance. Recurring pairing blocks booked as standing commitments, because ad hoc pairing across a gap never happens. And a protected block of open availability — not a meeting, just a commitment that certain people are reachable and will respond in minutes rather than hours.

Everything else goes to the written channel: planning becomes a proposal with a comment period, the demo becomes a recording, and the retrospective becomes a written collection round followed by a live discussion of the two or three things that genuinely need arguing about. See asynchronous-first-delivery for the mechanics.

Writing overlap into a statement of work

Overlap that is not contractual is overlap that erodes. The first busy quarter, the first change of manager on either side, and the informal arrangement quietly reverts to whatever is convenient for the party with more power. Write it down.

The things worth specifying are concrete and few. The guaranteed daily overlap window, in a named timezone, with daylight-saving behaviour made explicit, because an arrangement that silently loses an hour twice a year produces two confusing months every year. Which side absorbs the inconvenient hours, and how that rotates. A response-time expectation for blocking questions raised inside the window, distinct from the expectation outside it. The named role on the client side accountable for being available in it, since an unnamed availability commitment is not a commitment. The handover artefact where one applies, including its structure and its author. And what the overlap is reserved for — plus the clause preventing later meetings from consuming it without explicit agreement.

Then specify the decision rights, because that clause determines whether overlap is a communication channel or a permission queue. Write down which decisions the delivery team makes alone, which require consultation, and which require approval; keep the third list short and shrink it on a schedule. An engagement where the team must seek approval for routine technical choices will spend its entire overlap on approvals and produce exactly the passive, order-taking behaviour the client later complains about — a behaviour the contract created.

What to do on Monday

Open the calendar of one distributed team and colour every recurring meeting inside the overlap window. Total the hours as a percentage of available overlap. Then sort those meetings into the four legitimate categories — ambiguous decisions, pairing, incident response, relationship — and total again. The gap between the two numbers is the size of the problem, and in most organisations it is the majority of the window.

Next, ask the delivery team for the three things they most recently waited on someone else to answer, and how long each took. Not a general impression — three specific instances from the last fortnight. That produces a concrete list of ambiguity sources and their latency cost in twenty minutes, and it usually points at one or two individuals who are structural single points of answer.

Then make one change this week. Cancel or record the largest status-shaped meeting in the window, move the recovered time to a protected pairing or availability block, and say plainly what the time is for. Measure the same three-question latency again in a month.

If you are writing or renewing a statement of work this quarter, add the overlap clause before it goes to procurement. A shared-inconvenience rotation is far easier to negotiate at contracting time than eighteen months later, once the pattern of who moves their day has hardened into an assumption about who works for whom.