Follow-the-Sun Without the 24-Hour Availability Expectation

Follow-the-sun works when a piece of work can be put down in one zone and picked up in the next without a conversation. It fails, expensively and quietly, when the only way to pick up the work is to ask the person who put it down, because at that point the model does not hand work between zones. It just keeps everyone available in all of them.

"We hired for coverage and built a team where everyone is always on."

What follow-the-sun promised

The original promise is attractive and still sound: with people in three regions, work in progress never has to stop. A problem found in Singapore at 16:00 can be worked in Amsterdam at 11:00 and finished in San Francisco at 09:00. Elapsed time collapses, and nobody works a night shift to achieve it.

That promise rests on one assumption which nobody writes down: that the work is transferable. Everything else in the model is logistics. If the assumption holds, follow-the-sun is genuinely the most humane way to run fast global work. If it does not hold, the model converts into a rota where each zone is nominally responsible for continuity and actually dependent on the previous zone's author.

How it drifts into always-on

The drift is gradual and every step is reasonable.

It starts with one person staying online for twenty minutes to walk the next zone through something tricky. It works well, so it happens again. Then it becomes an expectation, then it is on the calendar as an overlap call, and then the calendar call is not enough so people message each other directly outside it. Six months in, the team has follow-the-sun on paper and three zones of people who check their phone in the evening, which is a pattern fixing always-on on your own team looks at in more detail.

Nobody decided this. Each individual instance of staying online was generous and correct. The aggregate is a team that has taken the risk of incomplete handoffs and turned it into unpaid availability.

The handoff is the whole model

If you only change one thing, change what gets written when work is put down. The handoff is not documentation and it is not a status report. It is the state of one piece of work, written so a competent colleague can continue it without you: current state, open questions, blockers, next actions. Four fields, ninety seconds, covered in full in the end-of-day handoff.

The reason handoff documents still leave people online is that they answer the questions the author anticipated. The next zone reliably has one more. This is exactly the seam StandIn is built for: your brief carries the work into the next time zone, and the person does not have to. The same four fields, mostly pre-drafted from the work you already did, confirmed in ninety seconds. Then while you are off, your StandIn answers questions from that brief in your words, with a source under every answer, and when the answer is not there it says so and names who to ask.

The follow-the-sun model then does what it claimed: the work moves, the people do not. See working across time zones for how that plays out on a three-zone team.

What kinds of work actually travel

Be selective. Not all work is a good candidate, and forcing the model onto work that resists it is how teams end up doing the same investigation three times in one day.

Travels well	Travels badly
Well-specified implementation work	Ambiguous discovery where the question is still forming
Review, QA, and verification passes	Work where the next step depends on a judgement call
Incident follow-up with a written timeline	Live incidents mid-diagnosis
Long-running builds, migrations, backfills	Customer conversations mid-negotiation

The right-hand column is not a failure of the model, it is the boundary of it. Work in that column should stay with one zone and one owner, and the handoff should say so explicitly: "do not pick this up, I will continue tomorrow" is a complete and useful handoff line.

A one-item test for your model

Pick one piece of work currently in flight. Ask the person who owns it to write the four fields, then ask someone in the next zone to read only that and say what they would do next. Do not let them message the author.

Three outcomes. They describe a sensible next step, and your model works for that class of work. They describe the wrong next step, and the handoff is thin in a specific, fixable way. They say they would have to ask, and you have just found the exact question that is costing you a night. Run it on five items and you will have a precise picture of where your continuity actually comes from.

If the honest answer is that continuity comes from one or two people being reachable, start with coverage across time zones without turning everyone into on-call.

Common Questions

Does follow-the-sun require three full teams?

No, but it requires each zone to have enough capability to make progress unaided. A single person in a zone with no peer can receive work but cannot resolve ambiguity in it, so the model degrades into a relay. Capability per zone matters more than headcount per zone.

Is follow-the-sun the same as on-call?

No, and conflating them is the most common structural mistake. Follow-the-sun moves planned work between working hours. On-call handles unplanned incidents outside them. One is a delivery model, the other is a risk model, and they need separate rotas, separate expectations, and separate compensation.

How do we stop the overlap calls creeping back?

Give the calls an explicit purpose that is not information transfer, and cancel them when there is nothing of that kind to discuss. A standing call whose agenda is "sync" will always refill with context that should have been written down.

What is the earliest sign the model is failing?

The same item appearing in two zones' handoffs with no progress between them. That means the receiving zone read the handoff, could not act on it, and waited. Two consecutive days of that is a clear signal to look at the handoff rather than the people.