Follow-the-Sun Delivery — 3 synced hubs ship 24/7 without burning out.

Follow-the-Sun Delivery isn't a buzzword we slapped on a slide to look modern. It's an operating model we've been running for 9 years, on products in production, for clients paying real SLAs. 3 synced hubs - Paris, Montreal, Tokyo. 24 hours of useful delivery per business day. Zero engineers coding at 3am to catch up with a timezone. That's Adaptive Follow-the-Sun. The rest is marketing.

The problem: why 24/7 died inside 9-to-5

Most consultancies sell 24/7 by stacking on-call rotations. You end up with a Paris team that closes at 7pm, a firefighter on-call who takes over reactively, and a backlog that restarts the next morning with 10 tickets to triage. You pay for 24h, you ship 8h.

The other classic option - low-cost near-shoring in India or North Africa. You gain 4-6h of overlap, you lose quality, IP control, and you end up with 2 teams ping-ponging tickets on Slack with 'not my issue'. The ticket sleeps 16 hours.

The real hidden costs of mono-geo delivery on a critical product:

• Degraded time-to-market - every incident handled outside business hours costs 3 to 5x more in MTTR.
• Structural burnout - repeated on-call rotations push senior engineers out within 18 months.
• Invisible tech debt - code written at 2am by an exhausted on-call ships as a paying bug 6 months later.
• Lost momentum - a feature delivered Friday evening waits until Monday morning for validation. 60h of delay per release.

Our Adaptive Follow-the-Sun method

Adaptive, because we don't run 3 parallel teams that step on each other. We orchestrate 3 synced cells around a single product, with one backlog, one quality bar, one Definition of Done. Engineers in Paris, Montreal and Tokyo work on the same Git, the same runbooks, the same ADRs.

The secret isn't in the timezones. The secret is in the handover. We spent 4 years industrializing the handoff between hubs - 12-point checklist, async Loom video capped at 5 minutes, shared status dashboard, ownership tracked in every PR. When Tokyo wraps its day, Paris picks up exactly where Tokyo stopped. No retread, no re-onboarding, no 'remind me the context'.

The 3 technical pillars that make Adaptive Follow-the-Sun viable:

• Documentation as code - every architecture decision is versioned, every runbook is executable, every incident auto-generates an indexed postmortem.
• Shared observability - Grafana or Datadog dashboards accessible to all 3 hubs, alerting routed to the active hub, no cumulative on-call.
• Trunk-based development + feature flags - no long-lived branches diverging across timezones, continuous releases, 30-second rollback.

How it actually works (handover every 8h)

A typical day on a Follow-the-Sun product looks like this. Times are in CET, but the mechanics hold whichever hub starts.

1. 08:00 CET - Paris opens. Reads Tokyo's handover (Loom + dashboard). Picks up the backlog where Tokyo left it.
2. 12:00 CET - 15-min sync Paris-Montreal (Montreal just opened at 7am local).
3. 16:00 CET - Paris hands over to Montreal via structured handover. Loom + checklist. Paris closes.
4. 20:00 CET - Montreal continues, Tokyo prepares to open (5am Tokyo local).
5. 00:00 CET - Montreal hands over to Tokyo. Tokyo takes the wheel on incidents and priority features.
6. 08:00 CET - Tokyo hands back to Paris. Loop closed.

The proof: 6 years of Follow-the-Sun at Le Monde

Le Monde has trusted us for 6 years on its data and insights stack. The mission started in Paris, embedded in the newspaper's Insights team. In 2023, the lead engineer - Alexandre L. - relocated to Tokyo. The mission didn't move. It actually gained coverage.

Today, Le Monde gets active coverage on the 5am-10pm CET window. When an editorial incident hits Paris at 6am during a live political broadcast, Tokyo is mid-afternoon and triggers the fix before Paris has finished coffee. It's the only Follow-the-Sun in production I know of on a French media outlet of that size. And it's been holding for 6 years.

Why 3 hubs, not 2 or 4

Fair question, we get it on every RFP. The answer is mathematical before it's strategic.

• 2 hubs (Paris-Tokyo or Paris-Montreal) - 16h coverage per day, 8h gap. Not Follow-the-Sun, just extended-day.
• 3 hubs (Paris-Montreal-Tokyo) - 24h coverage, each hub works 8h, each handover is synchronous (1-2h overlap between adjacent hubs). Sweet spot.
• 4+ hubs - each handover adds noise, rework, context dilution. Past 3, coordination cost outpaces coverage gain.

Paris, Montreal, Tokyo - this isn't a romantic geographic pick. It's the triangle that maximizes time coverage with minimum cultural friction. 3 working languages (FR, EN, JP), 3 code review cultures, 1 shared standard.

What we avoid (anti-patterns)

• Cumulative on-call - never. If you do Follow-the-Sun to spare on-call rotations and your engineers still page at night, you've gained nothing.
• Undocumented voice handover - the 'quick sync over Zoom' doesn't survive turnover. Everything goes through Loom + dashboard.
• 3 parallel backlogs - one backlog, one Definition of Done, one product owner. Otherwise, you get 3 mini-teams in silos.
• Mechanical sun-following - we don't ship a ticket to Tokyo just because it's 6pm in Paris. We ship to Tokyo when Tokyo is the right hub for the ticket (skills, context, priority).
• 3-voice reporting - one PM, one reporting line, one client interlocutor. The client must never 'manage' 3 teams.