You Buy Timezone Overlap in Hours and Then Spend It All on Meetings

Overlap hours are the most expensive thing on a distributed team and the least carefully spent. An organisation will negotiate hard to get four hours of shared working time with an offshore team, agree a premium for it, then fill three of those hours with a standup, a sprint ceremony, a design review and an all-hands. What is left is the actual purpose of the overlap: the moment a developer is blocked and needs an answer from someone who is not in the room with them.

The failure is not that meetings are bad. It is that overlap is treated as ordinary working time when it is a rationed resource. Anything that could have happened in writing, at any hour, should not be occupying a slot that only exists for a few hours a day.

What overlap is actually for

There are exactly three things that need shared clock time, and none of them is a status update.

The first is unblocking. A developer hits an ambiguity in a requirement, a permissions error on an environment they do not control, or a decision that is not theirs to make. Every hour they sit blocked is an hour of paid capacity producing nothing. If the person holding the answer is asleep, the block lasts until tomorrow, and one blocked afternoon costs more than a week of well-run meetings.

The second is genuine disagreement. Two engineers who read the same document differently will not converge over comments. Written threads are good at conveying positions and bad at resolving them, because the cost of one more reply is low and the cost of conceding feels high. Twelve minutes on a call ends it.

The third is anything with a whiteboard in it: early architecture, data modelling, a debugging session where two people need to look at the same output. These are exploratory and their shape is not known in advance, which is precisely what asynchronous formats handle worst.

Everything else is reportable. Progress, blockers already logged, decisions already made, demo recordings, review comments. If your overlap is full and your engineers are still waiting on answers, you have spent the budget on the wrong category.

The arithmetic nobody runs

The useful exercise is to price an overlap hour and compare it to what it is being used for. Take the team's blended hourly cost, multiply by the number of people in the room, and ask whether the meeting produced a decision that only synchronous time could produce.

Activity	Needs overlap?	Better home
Daily status round-robin	No	Written update in a channel, posted at end of each side's day
Unblocking a stuck developer	Yes	A named, reachable person during overlap
Sprint planning	Partly	Async proposal circulated first, short call to resolve disputes
Code review	No	Pull request comments, with escalation to a call if a thread hits three replies
Architecture debate	Yes	Scheduled, with a written position paper sent in advance
Demo	No	Recording, watched on the viewer's own time
Retrospective	Yes	The one ceremony where tone matters and text flattens it

The pattern is that anything with a known agenda and a predictable output can be written down. Anything whose output is unknown before it starts needs people talking. Most recurring meetings on a distributed team fail this test, which is why the standup is the first thing to cut and the retrospective is the last.

How many hours you need in the first place depends on the model. A team doing exploratory product work with daily direction changes needs more than a team maintaining a defined backlog, and the practical guidance on how many hours of timezone overlap different working models actually require is worth reading before you fix a number in a contract. Buying eight hours when you need three is expensive; buying two when you need five produces a team that is permanently one day behind.

Protect the window with structure, not goodwill

Telling people to have fewer meetings does not work, because each meeting is individually defensible. What works is making the window structurally unavailable for the wrong things.

1. Declare a no-meeting core inside the overlap. If overlap is 13:00 to 17:00 UK time, block 14:00 to 16:00 for nothing but ad hoc questions and pairing. Nobody books it. It exists to be interrupted.
2. Move ceremonies to the edges. Standup, if you keep it at all, goes at the very start or end of the window where it costs the least contiguous time.
3. Name an escalation path per side. One person on each side is reachable during overlap without a calendar invite. Not a rota nobody remembers: a named person, stated weekly.
4. Set an async-first default with an explicit break clause. Everything starts in writing. When a thread reaches three replies without resolution, whoever notices books ten minutes. The rule matters more than the number.
5. Require a written artefact before any synchronous design discussion. A one-page position, circulated the previous day. The reading happens on each participant's own time, so the call starts at the disagreement rather than at the background.
6. Audit the calendar monthly. Delete anything whose output was a document that could have been written alone.

The last one is the only step with teeth, and it is the one most teams skip.

Where the real cost hides

The visible cost of poor overlap use is a full calendar. The invisible cost is decision latency: the number of working days between a question being asked and answered. On a badly run distributed team this settles at one to two days by default, because questions get asked at the end of one side's day and answered at the start of the other's, and each round trip burns a full cycle.

Decision latency compounds in a way meeting hours do not. A feature that requires four clarifications takes at least four days longer than the same feature built beside the person who has the answers, regardless of how fast anyone types. This is the number to instrument if you want to know whether your overlap arrangement is working, and it is a far better signal than anything on a timesheet. The broader argument for measuring a development team by outcomes rather than activity applies directly here: hours in meetings is an input, days waiting for answers is a result.

Overlap use is also the thing that most sharply separates the two common engagement models. A dedicated team versus staff augmentation comparison is partly a comparison of who absorbs the coordination load. Augmented individuals sit inside your ceremonies and inherit your meeting culture, so your overlap problem becomes theirs. A team with its own lead concentrates the coordination into fewer channels, and one person's overlap window carries the cross-timezone traffic for several engineers.

What to do this week

Export the last month of calendar data for everyone on the distributed side. Mark each recurring meeting as unblocking, disagreement, whiteboard, or reportable. Delete or move the reportable ones and see what fraction of the window you get back. Most teams recover between a third and a half of their overlap in one pass.

Then measure decision latency for two weeks: log the timestamp when a question is asked and when it is answered, and look at the distribution rather than the mean. The long tail is where the money goes.

If you are setting an engagement up rather than repairing one, the window design belongs in the first fortnight, not after the first missed deadline. Our approach to building dedicated development teams treats overlap hours as a designed resource with a stated purpose, and the onboarding sequence for a new dedicated team sets the communication defaults before habits form. Fixing a calendar culture after six months is much harder than choosing one at the start.