We Lost 11 Hours a Week to Bad Handoffs: the 7 Steps That Fixed Our Singapore Rotation

The eleven hours were not in anyone timesheet. I found them by going through two weeks of threads and marking every one that had waited a full cycle for an answer that took ninety seconds to give. Eleven hours a week of work sitting still, across a team of nine, because a question was asked at the wrong end of a day and nobody had decided in advance who was allowed to answer it. None of it was a communication problem in the sense people usually mean. It was a design problem, and the seven steps below are the design we replaced it with.

Step 1: Map the real overlap window, in SGT

Start by throwing away the arithmetic. The difference between two working days tells you the nominal overlap, and nominal overlap is almost always a significant overstatement. Singapore at UTC+8 against a team in Central Europe gives something like three hours on paper. In practice the first of those is one team standing meeting, the middle is lunch somewhere, and the last is when one side is closing down.

So measure it instead. For two weeks, record the hours in which a question asked in one zone received an answer in the same hour. That number is your real overlap, and it is usually between one and two hours when people expected three or four. Write it down in Singapore time, as a window with a start and an end, and put it somewhere both teams can see.

Three things routinely eat the window, and all three are fixable without moving anyone working hours:

• Standing meetings scheduled into it, because it was the only time everyone was available. This is the most common and the most expensive.
• Lunch, which is rarely on a calendar and reliably removes an hour.
• Public holidays that do not match. Singapore and most European or North American calendars share almost nothing. A quarter with four single-sided holidays has four days where the window does not exist at all, and those days need a different plan rather than an apology.

Step 2: Decide whether you are continuing one thread or running two

There are only two workable models, and most struggling setups are accidentally attempting both at once.

Continuation. One piece of work travels around the clock. Zone A stops, Zone B picks it up, progress continues overnight. This is what people picture when they say follow the sun, and it is the more expensive of the two because every transfer costs context. It is worth paying for in exactly two situations: an incident or a hard external deadline, and work where the critical path is a single thread that genuinely cannot be parallelised.

Parallel ownership. Each zone owns its own threads end to end and the handoff carries only coordination, not work in progress. Nothing travels except information. This is the right default for roughly 80 per cent of delivery, it needs far less discipline to sustain, and it is what most teams should be doing while believing they are doing continuation.

Choose per workstream and write the choice down, because the hybrid that emerges by accident has the worst properties of both: the context cost of continuation and the ambiguity of parallel ownership. If you are standing a distributed team up from scratch rather than fixing one, the sequencing sits in our guide to building a remote developer team in Singapore.

Step 3: Make the handoff an artefact, not a meeting

A handoff call feels efficient and fails in one specific way: it exists only for the people who attended it. Anyone absent, anyone joining later, and anyone needing to know in three weeks why a decision was made has nothing. And the call tends to happen in the overlap window, which is the most valuable hour of the day and should not be spent on narration.

So the handoff is a written note, one per thread being passed, and it contains five things:

1. State, in one sentence. Where this thread is right now.
2. The single next action. One. If there are three, the thread is too big to hand over.
3. Ruled out, and why. The approaches already tried and rejected.
4. The one decision needed from the receiving zone, if there is one, phrased so it can be answered yes or no.
5. Where the work lives. Branch, environment, pull request, logs.

Item three is the one that gets left out, and it is the one that pays for the whole practice. Without it, the receiving engineer re-runs the investigation that was already completed, which is the most expensive duplicated work in a distributed team because it looks like progress while producing none. Item two is the discipline test: a thread needing a paragraph of next actions is a thread that should not move.

Keep the note under five minutes to write. We tried a richer template early on, and it was quietly abandoned inside two weeks, which taught me that the format has to survive a bad Friday or it does not exist.

Step 4: One named owner per thread, at every moment

The two states that destroy a rotation are two owners and no owner, and both are produced by the same omission: treating ownership as implied by the handoff rather than transferred by it.

Two owners looks collaborative and produces duplicated work, conflicting commits and a subtle mutual slowdown as each waits to see what the other does. No owner looks fine for about eighteen hours and then surfaces as a thread that nobody touched since Tuesday, with both zones assuming the other had it.

The rule we use is mechanical: a handoff note is not complete until the owner field names a person in the receiving zone, and that person acknowledges it with a single word when their day starts. Not a discussion, just an acknowledgement, which turns an assumption into a fact. If the acknowledgement does not arrive within the first hour of their day, the thread reverts to the previous owner automatically. That reversion rule sounds bureaucratic and is the single highest-value line in the whole protocol, because it makes dropped threads impossible rather than merely discouraged.

A thread with two owners moves slower than a thread with one. A thread with no owner does not move at all, and nobody notices for a day.

Step 5: Give blockers a path that does not wait for the overlap

This is where my eleven hours were hiding. A blocking question asked at the end of a Singapore day would sit in a queue with status updates and non-urgent requests, get seen by the other zone at the start of their day, and be answered: except that by then the person who needed it had gone home, so the answer was read the following morning. One ninety-second answer, two calendar days.

The fix has three parts, and none require anyone to work unusual hours:

1. Separate the channel. Blocking questions do not go where status goes. They get their own place, and that place is checked first in each zone, not scrolled through.
2. Name a standing decider per zone. One person per zone who can answer or unblock, by name, on a rota. “Ask the team” is how a blocker waits a day.
3. Write the default action. For each class of blocker, state what the blocked engineer should do if no answer arrives within the window: proceed with assumption X and flag it, or stop and switch threads. A default means a blocker never costs a full cycle, because the blocked person always has a defined next move.

That third item is what actually recovered the hours. Most blockers are not genuinely blocking, they are a request for permission to proceed with a reasonable assumption. Writing the assumption down in advance converts a day of waiting into a note on a pull request. One caution: this is a planned-work mechanism and not an incident mechanism. Out-of-hours incident response is a separate structure with different people and different measurement, and it belongs in an on-call rotation rather than here. Routing planned handoffs through the on-call engineer is a reliable way to break both.

Step 6: Protect the overlap window from meetings

Having measured the real window in step 1, the temptation is to fill it, because it is the only time everyone is available. Resist it completely. The window is for work that genuinely requires both zones live and cannot be done any other way:

• Decisions needing more than one round of back and forth.
• Pairing on something genuinely unclear.
• Design disagreements, which are miserable to resolve in writing.
• Anything with a person problem attached to it.

Everything else moves out, and the biggest single item to move is status. Status reporting is the purest possible waste of synchronous cross-zone time: it is one-directional, it needs no discussion, and it is better in writing because it becomes searchable. Replace the status portion of the call with the handoff notes from step 3, and most teams recover forty minutes a day of their most expensive hour.

One more protection: book the window as a calendar block on both sides, owned by the delivery lead, with a stated rule that anyone wanting it must say what two-zone decision requires it. Without an owner, the window is colonised within a month, which is how most teams end up believing they have a time zone problem.

Step 7: Measure round trip cost every fortnight

The protocol decays unless something counts it, and the thing worth counting is not meeting attendance or note compliance. It is this: how many threads waited a full cycle for an answer.

Every two weeks, go through the threads that moved between zones and mark each one that sat idle waiting on information. For each, ask which of the previous six steps would have prevented it. In our case the first review produced the eleven hour figure, and the distribution was blunt: most of it was step 5, a handful was step 4, and a couple of cases were threads too large to hand over at all, which is a step 2 problem.

Then change exactly one thing before the next review. The temptation after a first measurement is to rewrite the whole protocol, which makes it impossible to tell what helped. Fix the biggest category, measure again, repeat. Three fortnights is normally enough to get the number down to something you stop thinking about. For the wider delivery metrics this sits inside, we use the approach in our note on engineering productivity metrics, and the cost side of the different team shapes is in our team cost calculator.

The Four Ways This Goes Wrong

FAQ: Follow the Sun Handoffs

Method note: the seven steps, the five-field handoff note, the ownership reversion rule, the blocker default mechanism, the round trip measurement and the four failure modes are our own method, developed running delivery teams split between Singapore and other time zones. The eleven hours a week figure and the distribution of its causes are our own measurement on our own team, not a benchmark: run the step 7 review on your own threads rather than assuming the same split. Adjust the window and the rota to your actual zones, then hold the protocol fixed for three fortnights so that the measurements stay comparable.