Follow the Sun Engineering

Follow-the-sun engineering is a model where work passes from one region to the next as each workday ends, so a project keeps moving around the clock. It only pays off when each handoff is written and self-contained, because the moment it requires a live meeting between two regions, you have reintroduced the very waiting the model was meant to remove.

That is the catch most follow-the-sun setups hit. The promise is continuous progress, but the daily sync forces someone in an early or late slot to attend, and the rest of the work waits for that sync to happen. The way out is to make each region's day answer for itself in writing. When the outgoing region's work keeps answering after they log off, the incoming region starts cold and still moves.

The promise and the catch

The appeal of follow-the-sun is real: a critical fix or a long build can advance while most of the company sleeps, because somewhere a region is awake and holding the baton. For incident response and for long-running delivery, that continuity is genuinely valuable.

The catch is that a baton only helps if it carries the full state of the work. If the handoff drops context, the receiving region spends its fresh hours reconstructing what the last region already knew, and the round-the-clock advantage evaporates. This is the same failure covered in engineering handoffs: what breaks and why, just at regional scale, where the cost of a dropped baton is measured in the terms of the timezone tax.

Why the handoff meeting has to go

The instinct is to fix a shaky handoff with a meeting: overlap the outgoing and incoming regions for fifteen minutes and talk it through. It feels safe. It is not.

A daily handoff meeting quietly imposes a cost on every future day. Someone always sits in a bad slot. The meeting becomes load-bearing, so if it is missed, the handoff fails. And it caps how many regions you can chain, because every added region is another meeting to schedule across widening gaps. You built follow-the-sun to escape the constraint of shared awake time, then a meeting hands that constraint right back. The alternative is the discipline in designing a handoff process nobody has to be awake for.

What replaces the meeting

A written handoff, structured and complete, does everything the meeting did and more, because the next region reads it exactly when they start, not whenever the meeting was scheduled. Build it from a few reliable parts:

• State of each active thread: what moved, what is blocked, what is unsafe to touch. The end-of-day handoff template is the unit here.
• The reasoning, not just the result: what was tried and ruled out, so the next region does not repeat it.
• A clear owner for each thread: named, or marked open, so nothing is dropped between regions.
• An escalation path: for the rare thing that truly cannot wait, kept separate from the routine flow.

Done well, this reads faster than a meeting and never forces anyone out of bed. It also scales: you can chain three or four regions without a scheduling nightmare, because there is no shared clock to satisfy.

Keeping the record answerable

A written handoff still has one weakness: the receiving region will ask a question the author did not anticipate, and the author is now asleep across the world. If that question has to wait, the baton stalls. Your StandIn is what keeps the baton moving. It answers for the outgoing engineer while they are off, on their behalf, from their brief and the team's record, including the handoff they just wrote. When the answer exists in the record, it gives it in the author's words. When it does not, it says so plainly, so the incoming region never builds on a guess during a critical overnight push. In a model whose entire value is continuity, an honest "not written down" is safer than a confident invention that has to be unwound the next day.

The same principle lets you bring a new engineer into a follow-the-sun rotation without a live handoff tour, which is the topic of onboarding a remote engineer when nobody is free to explain.

Common Questions

What is follow-the-sun engineering?

It is a way of organizing work so it passes between regions as each workday ends, letting a project or an incident advance continuously instead of pausing overnight in any single location.

Do we really need to drop the handoff meeting?

You need to drop it as a requirement. Keep an optional overlap for genuinely tricky handoffs, but the routine baton pass should work entirely from the written record, so no region is ever forced awake for it.

How many regions can this scale to?

As many as you can staff, once the handoff is fully written. A meeting-based handoff caps you at the regions you can fit in one call; a written one has no such ceiling.

What about incidents that cannot wait for the next region?

Keep a dedicated escalation path for true emergencies, separate from the routine handoff. Most work is not an emergency, so the written flow carries the bulk and live attention is saved for the rare urgent case.

Follow-the-sun only delivers continuous progress if the baton carries the full state and never forces a region awake to receive it. Write each day's work down and let your StandIn answer the follow-ups from what you wrote, and the sun really does keep the work moving. See how teams run this on StandIn for engineering.