Four hours of shared working time is enough to run a serious engineering team, but it is not enough to run it the way most companies run co-located teams. The failure mode is predictable: a team treats the overlap as a shortened version of a normal day, fills it with meetings, and then wonders why nothing gets reviewed. <\/p>\n\n\n\n
This is an operational guide to spending those four hours correctly. <\/p>\n\n\n\n
The overlap window is the only time when a question can be asked and answered in the same conversation. Everything that does not require that property should happen outside it. <\/p>\n\n\n\n
That gives a simple rule: the overlap is for unblocking.<\/strong> Writing code, writing tickets, writing documentation, and running tests all work fine asynchronously. That can’t be said about resolving a disagreement about an interface. <\/p>\n\n\n\n Once you accept that rule, the agenda for the window almost writes itself. <\/p>\n\n\n\n The exact clock times depend on your time zone. The overlap starts at the beginning of one side’s day and the end of the others. <\/p>\n\n\n\n First 30 minutes: handover.<\/strong> The team that is finishing says what changed, what is blocked, and what the other side should pick up. The starting team asks clarifying questions. This is a shift handover, and it works best written first. <\/p>\n\n\n\n Next 90 minutes: review and decisions.<\/strong> Pull requests opened during the non-overlapping hours get reviewed here, while both authors and reviewers are available to discuss. Design questions that accumulated overnight get answered here. This is the highest-value block of the day and should be defended against meeting creep. <\/p>\n\n\n\n Next 60 minutes: pairing or deep questions.<\/strong> Anything that genuinely needs two people at once: a tricky bug, a migration plan, an unfamiliar part of the codebase. <\/p>\n\n\n\n Final 60 minutes: planning the asynchronous stretch.<\/strong> The side that is about to work alone confirms it has everything it needs for the next several hours. <\/p>\n\n\n\n Asynchronous work fails when knowledge lives only in conversations. Three artefacts carry most of the weight. <\/p>\n\n\n\n Decisions with reasons.<\/strong> Why, what was rejected, and what would make us revisit. An engineer reading this at 3am in another country needs reasoning. <\/p>\n\n\n\n Ticket acceptance criteria.<\/strong> A ticket that says “improve the import” will be built wrong somewhere in the world. A ticket that says what the input is, what the output is and what counts as done will not. <\/p>\n\n\n\n A running log of blockers.<\/strong> A list with an owner and a date, visible to both sides, reviewed in the handover. <\/p>\n\n\n\n None of these are exotic. It is the ordinary discipline that co-located teams get away with skipping because they can lean over a desk. <\/p>\n\n\n\n In most offshore development teams<\/a> that struggle, the problem is review capacity. <\/p>\n\n\n\n If all reviewers sit on one side of the overlap, every pull request waits for that side’s working hours. The queue grows, the branches age, and merge conflicts multiply. The fix is structural: make sure at least one competent reviewer is awake during each side’s working hours, even if that means investing in review skills on the remote side earlier than feels comfortable. Branch settings are where that intent becomes enforceable, because required approvals and code-owner rules decide who can clear a merge and who cannot.\u00a0<\/p>\n\n\n\nA workable shape for the four hours<\/strong> <\/h2>\n\n\n\n
What must be written down<\/strong> <\/h2>\n\n\n\n
The review bottleneck<\/strong> <\/h2>\n\n\n\n