What Is Follow the Sun Development?
Follow the sun development is a distributed engineering model where work passes between teams in different time zones so that development continues around the clock without requiring any individual to work outside normal hours. As one team ends their day, they hand off to the next team — who picks up where they left off and continues until they hand off to a third.
The model is named after the literal path of the sun across the earth. A team in London finishes at 17:30. New York picks up at 09:00. Singapore or Tokyo takes over from there. In theory: 24-hour continuous development with zero overtime and zero burnout.
In practice, most follow the sun implementations fail within six months. This piece covers what the model requires to work, the three most common failure modes, and how to build the infrastructure that makes 24-hour development actually viable.
Which Companies Use Follow the Sun Development?
Most large technology companies with distributed engineering use some version of this model, whether they call it by that name or not. IBM, Accenture, Wipro, and other global IT services firms have used follow the sun formally for decades. More recently, product companies like GitLab, Automattic, and GitHub have adopted asynchronous-first cultures that enable the same continuous output without rigidly structuring it as a relay.
Smaller engineering teams increasingly operate this way by necessity. A 12-person startup with engineers in London, New York, and Bangalore is running follow the sun whether they have formalized it or not. The question is whether they have built the infrastructure to make it work.
Infrastructure Requirements for Follow the Sun Development
The model sounds simple: team A ends, team B starts. But this transition — the handoff — is where most implementations collapse. Three infrastructure layers are non-negotiable:
1. A standardized handoff system
Every engineer at the end of their shift needs to leave a structured record of where things stand. Not a Slack message. Not a bullet list in a Google Doc that gets overwritten. A structured record that includes: what is in progress, what is blocked, who owns each open action, what decisions were made, and what the next shift needs to know first.
Without this, the incoming team spends the first hour hunting for context. That hour is your follow the sun model failing in slow motion. See how async governance creates continuity across time zones for a deeper treatment of this.
2. Documented state in your systems of record
The handoff can only be as good as your systems of record. If ticket status in Jira is stale, if PRs in GitHub have no context, if Notion docs haven't been updated in a week, the handoff will be incomplete no matter how well it is written. Follow the sun requires every team member to treat their systems of record as primary communication — not Slack, not ad-hoc conversations, not tribal knowledge.
3. Async-first culture
If your team defaults to synchronous communication — standing up a Zoom call when anything is unclear, expecting immediate Slack responses, resolving ambiguity through a quick chat — follow the sun will not work. By definition, the teams passing work to each other are not simultaneously online. Every "quick sync" required between shifts adds latency equal to the timezone gap.
An async-first culture means: defaulting to written communication, making decisions without requiring real-time consensus, and trusting that information left in structured records will be read and acted upon. For teams moving in this direction, cross-timezone collaboration frameworks provide a starting point.
The 3 Most Common Follow the Sun Failure Modes
Failure Mode 1: The Handoff Is Treated as Optional
This is the most common failure mode and it usually presents as a gradual degradation rather than a sudden collapse. One engineer skips the handoff once because they had a busy afternoon. Nothing catastrophic happens. They skip it again. Others notice and start treating it as optional too. Within a month, the incoming team is back to spending an hour on Slack archaeology every morning.
The fix: make the handoff non-optional by making the absence of a handoff visible. Track which team members submitted handoffs. Review missed handoffs in retrospectives. Don't treat this as a performance issue — treat it as an infrastructure gap. If someone isn't submitting handoffs, find out why. The most common reason is that the submission process is too cumbersome.
Failure Mode 2: The Overlap Window Becomes a Meeting Culture
Most follow the sun teams schedule a brief overlap window between shifts — typically 30 to 60 minutes where both teams are online simultaneously. This overlap is meant to handle edge cases: questions the handoff couldn't answer, critical blockers that need live collaboration.
In teams without strong async culture, this overlap window expands. It starts with a daily standup during overlap. Then a brief check-in. Then a requirements review because it's easier when everyone is live. Before long, both shifts are expected to be partially available during the other's hours, and the model's premise — working normal hours only — is broken.
The fix: protect the overlap window strictly. It should be 30 minutes maximum and should be used only for time-critical escalations that the handoff system couldn't handle. Anything that can be async should be async.
Failure Mode 3: Knowledge Accumulates in One Timezone
In many follow the sun implementations, one team ends up holding most of the system knowledge — particularly the team that was there first. New teams inherit the codebase but not the architectural decisions, the trade-offs, the failed experiments. Over time, the team that holds the tribal knowledge becomes a bottleneck. Questions flow to them even outside their hours. They stop being able to disconnect.
The fix: build a decision log practice as part of your handoff culture. Every decision of consequence — architectural choices, scope changes, escalation outcomes — goes into a queryable, shared record. Not in someone's head. Not in a Slack thread that scrolls off. In a place the team in Singapore can read at 08:00 local time before the London team comes online.
A Sample 3-Timezone Team Structure
London / New York / Singapore
| Team | Local Hours | UTC | Overlap |
|---|---|---|---|
| London | 09:00 – 17:30 | 09:00 – 17:30 UTC | London–NYC: 14:00–17:30 UTC |
| New York | 09:00 – 17:30 EST | 14:00 – 22:30 UTC | NYC–Singapore: 00:00–01:30 UTC (minimal) |
| Singapore | 09:00 – 18:00 SGT | 01:00 – 10:00 UTC | Singapore–London: 09:00–10:00 UTC |
In this structure, London–New York has a healthy 3.5-hour overlap. New York–Singapore has almost none, which means the handoff between NYC and Singapore must be exceptionally complete. The Singapore–London overlap is a single hour — again, the handoff is the primary mechanism of continuity.
The practical implication: the NYC→Singapore handoff requires the most rigor. This is the transition most likely to fail. Building extra structure here — a brief recorded loom or a particularly detailed handoff form — is worth the investment.
How Async Handoff Tooling Makes Follow the Sun Viable
The fastest path to a working follow the sun model is not more meetings or more Slack channels. It is a structured handoff record that the incoming team can query before sending a single message.
Modern async handoff tools like StandIn turn each end-of-day update into a queryable record. When the Singapore team comes online, they can ask: "What is blocked?" "What PRs need review?" "What decisions were made in the last 24 hours?" — and get answers from the handoffs left by London and New York without waiting for anyone to come online.
This transforms the follow the sun model from a coordination relay — where each handoff requires a live transfer of information — into a continuous state machine, where information is always available to whoever needs it next.
If your team is building toward follow the sun and wants to see how structured async handoffs work in practice, get early access to StandIn and run the model with the infrastructure it requires.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.