The "follow the sun" software development model
The "follow the sun" model promises 24-hour software development by handing off work between teams in different time zones. India works while America sleeps; Europe takes over when India winds down; America picks up when Europe winds down. Round-the-clock progress without any individual working overtime.
It's a beautiful idea and works well in some cases. In others — particularly complex engineering — the hand-off costs eat the benefit.
For tools that help coordinate across zones, the meeting planner and world clock are useful.
The basic model
Three teams, roughly 8 hours apart:
- Team A in India (UTC+5:30): works 9 AM-5 PM IST = 03:30-11:30 UTC
- Team B in Europe (UTC+0/+1): works 9 AM-5 PM = 09:00-17:00 UTC
- Team C in US East (UTC-5/-4): works 9 AM-5 PM = 14:00-22:00 UTC
The handoffs:
- ~10:30 UTC: India ends day, Europe is mid-morning. Hand off Indian work to Europe.
- ~16:00 UTC: Europe ends day, US is mid-morning. Hand off European work to US.
- ~22:00 UTC: US ends day, India is starting (next day). Hand off US work to India.
In theory, work continues round-the-clock. In practice, the hand-offs are where things break.
Where it works
Customer support. Tickets accumulate during one team's day; the next team picks up. Handoff is straightforward — just "here's what we did, here's what's pending."
Operations and monitoring. 24/7 systems require 24/7 attention. Each team takes a shift. Handoff is the on-call rotation.
Document review. Long documents that need legal/compliance review can move between regions, with each region adding comments.
Routine processing tasks. Data pipelines, report generation, batch operations — anything that runs on a schedule.
Where it struggles
Complex engineering work. The hand-off cost is high. To pick up where another engineer left off, you need to:
1. Read their commits
2. Understand their thinking
3. Test their changes
4. Continue the work without breaking it
For non-trivial code, this hand-off can take 1-3 hours. If the original engineer would have finished in 4 hours, you've doubled the cost.
Decision-heavy work. Decisions made at one timezone get re-examined and re-questioned at the next. Without good written rationale, you redo the analysis.
Trust-dependent work. Code review, security audits, design review — all benefit from the same person seeing the whole picture. Splitting across handoffs adds friction.
Cross-functional collaboration. Engineering + design + product can't realistically be split across follow-the-sun zones. The natural cadence requires sync time.
What good follow-the-sun requires
1. Excellent documentation discipline. Every handoff needs a written summary: what was done, what's next, what's blocked. No exceptions.
2. Explicit hand-off windows. A 30-60 minute overlap when the outgoing and incoming teams can briefly chat (sync) before the outgoing team logs off.
3. Consistent tooling. Both teams use the same code review tools, the same project management, the same chat. Zero context-switching cost.
4. Cultural alignment. Both teams need to trust each other's work. Constant rework or rebuilding kills the model.
5. Clear ownership. "This story is owned by India this week" prevents the team-switch from becoming "everyone touches it, no one finishes it."
6. Acceptance of slower decisions. Decisions made at one zone get reviewed by the next zone. Some decisions take 24-48 hours instead of immediate. This is the cost.
The classic failure mode
A common pattern: companies set up follow-the-sun expecting 24-hour productivity, then discover the cost.
- Hand-off documentation is sparse → next team has to rebuild context → 50% productivity loss
- The original team is asked clarification questions during their off-hours → they end up working overtime to answer
- Decisions made by one team get reversed by the next team → political conflict
- Net: instead of 24 hours of progress, you get 6-8 hours of effective work + lots of rework
This is why some "follow the sun" implementations end up being "two zones doing related work" rather than "true round-the-clock."
Where it works really well
Companies that succeed with follow-the-sun typically:
- Have process-oriented work (operations, support, batch processing) rather than complex engineering
- Have explicit hand-off rituals (daily 30-min sync, written summaries)
- Have stable team composition (people who've worked together for months/years)
- Have invested heavily in documentation tools and norms
- Use it for specific lifecycle phases (e.g., engineering happens in one zone, support across all)
A realistic example
A SaaS company with engineering in San Francisco, support in Manila (UTC+8), and account management in London:
- 9 AM Manila (01:00 UTC): support starts; takes overnight tickets, escalates as needed
- 9 AM London (08:00 UTC): account management starts; handles morning customer issues
- 9 AM San Francisco (16:00 UTC): engineering starts; takes feedback from support, builds fixes, ships
- 5 PM San Francisco (00:00 UTC): engineering ends; ticket backlog resets to overnight queue
Each team has a clear scope, written hand-offs happen at predictable times, and engineering doesn't work overtime to answer support questions. This works.
Hybrid models
Many "follow the sun" companies actually run hybrid:
- Core hours (when 80% of teams overlap, 1-2 hours per day): synchronous decisions
- Async work during local working hours
- Handoff periods at zone boundaries with explicit documentation
This is more sustainable than pure 24-hour handoff.
Mental health considerations
Pure follow-the-sun can mean someone is on-call at 3 AM with no notice. Companies should:
- Define on-call rotations and respect them
- Avoid expecting same-day responses outside business hours
- Pay for on-call work explicitly
- Rotate burdens across zones
Asking team members in one zone to consistently be the "evening shift" while another zone always works 9-5 is a recipe for resentment.
FAQ
Is follow-the-sun cheaper than concentrated teams?
Not always. Setup costs (documentation, tooling, hand-off discipline) are real. Many companies that adopt it find that the savings on round-the-clock work are offset by the management overhead.
What's the difference between "follow the sun" and async-first?
Follow-the-sun explicitly hands off work between zones. Async-first reduces synchronous meetings but doesn't necessarily hand off work. You can be async-first without follow-the-sun (most teams) or follow-the-sun without being fully async (some teams maintain heavy meeting culture within each zone).
How do you handle critical incidents in a follow-the-sun model?
Usually with explicit on-call rotations independent of the regular work pattern. The on-call engineer responds regardless of timezone; everyone else continues their normal schedule.
Will my team work?
If you're in operations, support, or content moderation, yes. If you're in complex engineering with high decision overhead, probably not — try a hybrid model first.
What about mental health and burnout?
Real concerns. Constant zone-switching, late-night responses, and unclear boundaries cause burnout. Build explicit time-off, on-call rotations, and respect for boundaries.
What's the best way to start?
Pick a single workflow (e.g., customer support tickets, operations alerts) and run a follow-the-sun pilot. Measure: was the hand-off effective? Did response times improve? Did the team report fatigue? Iterate before expanding.
Bottom line
Follow-the-sun works well for process-oriented work (support, operations, monitoring) and poorly for complex engineering work where hand-off cost dominates. Successful implementations require strong documentation discipline, explicit hand-off rituals, and acceptance of slower decisions. Hybrid models — async work during local hours plus core overlap hours — are usually more sustainable than pure 24-hour handoff.
For coordinating zones in your team, the world clock shows multiple zones at once, and the meeting planner handles meeting-time coordination.