The short answer
Protect three to four hours of genuine overlap, use it for the things that need a conversation, and write everything else down properly. Teams that do this work well across large distances. Teams that rely on catching someone at their desk do not.
The failure mode is not people working the wrong hours. It is a question asked at the end of one day, answered at the start of another, and a day lost per exchange.
What the overlap is for
| Use the overlap for | Handle asynchronously |
|---|---|
| Decisions with several options | Status updates |
| Anything contentious | Code review, mostly |
| Debugging together | Routine questions with a clear answer |
| Design discussion | Handover notes |
| Onboarding conversations | Documentation and reading |
The mistake is spending the overlap on a status meeting that could have been three sentences in writing, then having no time left for the decision that actually needed talking through.
Write handovers that are usable
A good end-of-day note takes five minutes and saves an hour. It says what was done, what is in progress and where it stands, what is blocked and on whom, and what they plan to pick up next.
- Where the work actually is, not just that it is going well
- Anything you need answered before you start again
- Decisions taken and the reason, so nobody relitigates them
- Anything you noticed that someone else should know
Teams that keep these in a channel rather than direct messages get a second benefit: the history is searchable, and the answer to a recurring question is already written.
Unblock people asynchronously
The most expensive pattern is a developer stopping work because a question cannot be answered until tomorrow. Reduce it by making more answerable without a person.
- Document the decisions that recur, so the answer already exists.
- Agree that a reasonable assumption plus a flagged note beats stopping.
- Name a second person who can answer when the first is asleep.
- Keep a written record of decisions so the reasoning is available.
- Prefer several smaller pieces of work, so being blocked on one does not stop everything.
The second point changes the most. Telling someone explicitly that a documented assumption is preferable to waiting removes a day of delay per question.
Where the real limits are
Incident response is the genuine constraint. If something breaks outside the overlap and only the augmented developer understands that part, you have a problem that no amount of documentation solves at three in the morning.
That argues for pairing on anything critical, and for keeping production knowledge inside your own team even when the building was done elsewhere.
Be honest about the cost
A small overlap window is a real constraint, not a detail to gloss over. It slows decisions, it makes debugging harder, and it puts more weight on documentation than most teams are used to.
It is often still the right trade for access to people you could not otherwise hire. Just price the friction in rather than discovering it in month two.