How to Run a Follow-the-Sun Team

Business & Remote Work

Follow-the-sun is the model where work is handed from one region to the next as each working day ends, so a queue is staffed around the clock without anybody working nights. It is simple to describe and unusually easy to get wrong: most implementations either leave a multi-hour hole in the coverage they were built to provide, or lose more time to handoffs than they gain from the extra hours. Both failures come down to arithmetic that can be done on the back of an envelope before anyone is hired.

Key takeaways

Three hubs spaced 8 hours apart, each working a 9-hour day, give exactly 24-hour coverage with a 1-hour handoff at each seam.
The popular US–Europe–India triad does not close the circle: it leaves about six hours uncovered and duplicates six others.
Build the roster in UTC, not in local hours — daylight saving moves your seams up to six times a year.
Follow-the-sun suits queues: incidents, support, monitoring, moderation. It rarely suits a single body of creative or design work.
The handoff is the product. If it is not written down and time-boxed, the model degrades into three teams re-reading the same tickets.

The Arithmetic: Why Eight Hours Apart

Twenty-four hours divided by three teams is eight hours each. But a shift with no overlap has no handoff, so each team needs to work slightly longer than its slice. Nine-hour days give 27 hours of staffed time across three teams: 24 hours of coverage plus three one-hour overlaps, one at each seam. That is the whole design.

For that to work, the hubs must sit eight hours apart in UTC terms. One triad does this almost perfectly:

Hub	Local working day	In UTC (northern summer)	Hands over to
Tokyo (UTC+9)	08:00 – 17:00	23:00 – 08:00	London at 07:00 UTC
London (UTC+1 in summer)	08:00 – 17:00	07:00 – 16:00	Los Angeles at 15:00 UTC
Los Angeles (UTC−7 in summer)	08:00 – 17:00	15:00 – 00:00	Tokyo at 23:00 UTC

Every hour of the day is staffed, every seam has a full hour of live overlap, and nobody works outside 08:00 to 17:00 in their own city. This is what a working follow-the-sun roster looks like, and it is the benchmark against which any other arrangement should be measured.

Why the Usual Triad Does Not Work

Most companies do not choose hubs by longitude. They choose them by where they already have offices, which typically means the east coast of the United States, somewhere in Europe, and India. Run the same arithmetic on that arrangement:

Hub	Local working day	In UTC (northern summer)
Bengaluru (UTC+5:30)	09:30 – 18:30	04:00 – 13:00
Central Europe (UTC+2 in summer)	09:00 – 18:00	07:00 – 16:00
New York (UTC−4 in summer)	09:00 – 18:00	13:00 – 22:00

The circle does not close. India and Europe overlap for six hours, which is six hours of duplicated staffing rather than coverage. Europe and New York overlap for three. And between 22:00 and 04:00 UTC — the American night, before the Indian day begins — nobody is working at all. Six hours of the day are unstaffed by a structure that was funded to deliver twenty-four.

The fix is not more people in the existing hubs; adding headcount in Europe deepens the overlap that is already redundant. The fix is a fourth location east of India, a genuine night shift in one hub, or an honest decision that the service is 18/5 rather than 24/7. The India corridor is worth understanding on its own terms — see Best Time for Meetings Between the USA and India and Time Zones in India Explained — because the same 9½-hour offset that makes it a poor follow-the-sun partner for New York makes it an excellent one for Europe.

Practical alternatives that do close the circle: Manila or Sydney as the APAC hub instead of India, paired with Europe and the US west coast; or a two-hub model with one deliberate overnight shift, which is cheaper and more honest than a third office that only covers hours somebody else already covers.

Daylight Saving Breaks the Roster Every Year

A roster expressed as “08:00 to 17:00 local” in three cities is not a fixed schedule. It moves whenever any one of those cities changes its clocks, and the hubs almost never change on the same weekend. Take the Tokyo–London–Los Angeles triad above and run it through the northern winter:

Seam	Overlap in northern summer	Overlap in northern winter
Tokyo → London	1 hour	none — the shifts merely touch at 08:00 UTC
London → Los Angeles	1 hour	1 hour
Los Angeles → Tokyo	1 hour	2 hours

Japan does not observe daylight saving; Britain and California both do, and on different dates. The consequence is that the Asia-to-Europe handoff quietly disappears for five months of the year, and returns for the other seven, without anybody changing a rota. There are three weeks in March when the US has moved and Europe has not, and a further week in late October when the reverse is true — the dates are listed in When Do the Clocks Change? DST Dates Around the World.

The remedy is to define the roster in UTC and let each hub translate. “The APAC shift runs 23:00 to 08:00 UTC” is a stable statement; “the APAC shift runs 08:00 to 17:00 Tokyo time” only happens to coincide with it. Where a hub does observe daylight saving, decide in advance whether the local start time moves with the clock or the UTC boundary holds — and write the answer down before March.

The Handoff Is the Product

Everything that makes follow-the-sun work or fail happens in the overlap hour. A handoff that consists of “anything I should know?” on a video call will not survive the first busy week. A handoff that works is a written artefact, produced during the shift rather than at the end of it, covering:

Open items with owners and state — not a list of ticket numbers, but what was tried, what was ruled out, and what the next step is.
Anything time-sensitive with a deadline in UTC, including customer commitments made during the shift.
Changes that landed — deployments, config edits, feature flags — because the next region will be debugging their effects.
Explicit non-handoffs. Items the receiving team should not pick up, with the reason. This is the field most handoff templates omit and the one that prevents the same ticket being re-investigated three times a day.
The single unresolved question, if there is one, phrased so it can be answered asynchronously.

Keep the live portion short. Fifteen minutes of the overlap hour for questions on a document the receiving team has already read beats sixty minutes of narration. The remaining forty-five minutes are what makes the overlap valuable: real-time availability if something goes wrong mid-transfer.

What Follow-the-Sun Is Good For, and What It Is Not

The model transfers cleanly when work arrives as a stream of independent, well-specified units. It transfers badly when the work is one large problem held in somebody’s head.

Works well	Works badly
Incident response and on-call rotation	Feature development on one codebase area
Customer support and ticket queues	Design, research and writing
Infrastructure and network monitoring	Anything requiring sustained context
Content and trust-and-safety moderation	Work with a single decision-maker in one zone
Long-running test and build pipelines	Negotiations and stakeholder management

The failure mode on the right-hand column has a name: the hot potato. A task is handed on unfinished at the end of every shift, each receiving team spends the first hour reconstructing what the previous one was doing, and a piece of work that would have taken one engineer two days takes three teams four. Passing work three times a day is only cheaper than passing it once if the reconstruction cost is close to zero, which is exactly what a well-specified queue item guarantees and a half-finished refactor does not.

Measuring Whether It Is Actually Working

Four numbers tell you within a month whether the model is delivering:

Time to first response, split by hour of day in UTC. If any six-hour band is materially worse than the others, you have a coverage hole, not a staffing problem.
Proportion of items touched by more than two regions. Above roughly one in ten, work is being passed rather than completed.
Reopen and re-escalation rate at the seams. A spike in the hour after each handoff points at the handoff document, not at the people.
Overlap utilisation. If the overlap hour is routinely spent idle, shorten it and give the time back; if it routinely runs over, the handoff artefact is too thin.

Common Mistakes

Choosing hubs by real-estate cost rather than longitude. The gap in coverage will outlast every saving.
No overlap at all. Back-to-back shifts with a shared document look efficient and remove the one mechanism that catches a bad handoff.
A single decision-maker in one region. If every escalation has to wait for one person in Europe to wake up, the other two shifts are a queue, not coverage.
Ignoring public holidays. Coverage is a staffing calendar, not a time-zone diagram. Golden Week, Diwali, Thanksgiving and the southern-hemisphere summer break each remove a hub for days at a time.
Ambiguous zone letters in the roster. IST means both Indian and Irish Standard Time, and BST means British Summer Time and Bangladesh Standard Time. Write offsets — Time Zone Abbreviations Explained.
Rotating the unpleasant hours only in theory. If one region always absorbs the awkward call, attrition will fix your roster for you. The same fairness principle applies to ordinary meetings across Europe and Australia or London and Sydney.

For the wider practices that make any distributed team work — written defaults, protected overlap, fair rotation — see Working with Remote Teams Across Time Zones, How to Schedule Meetings Across Time Zones and How to Avoid Time Zone Scheduling Mistakes.

Frequently Asked Questions

What is a follow-the-sun model?

A staffing arrangement in which work is passed between teams in different time zones as each one finishes its working day, so a queue is covered around the clock without night shifts. It is most common in customer support, incident response and infrastructure monitoring.

How many time zones apart should follow-the-sun teams be?

Eight hours, for a three-hub model. With each team working a nine-hour day that produces exactly 24 hours of coverage and a one-hour overlap at each of the three seams. Tokyo, London and Los Angeles are close to the ideal spacing.

Why do follow-the-sun teams fail?

Two reasons dominate. The hubs are chosen for business reasons rather than longitude, so the coverage circle never closes and hours go unstaffed. And the handoff is treated as a conversation rather than an artefact, so each region spends its first hour rediscovering what the last one already knew.

Should the roster be written in local time or UTC?

UTC. Local start times drift whenever any hub changes its clocks, and hubs rarely change on the same weekend, so a roster expressed in local hours silently loses its handoff overlaps for part of the year.

Can a two-hub team follow the sun?

Not fully. Two hubs twelve hours apart cover at most eighteen hours with nine-hour days, leaving a six-hour gap. Two hubs work well for extended-hours coverage, but genuine 24-hour cover needs either a third region or one accepted night shift.