Follow-the-Sun: A Global Relay Race for Work

WHY IT EXISTS A single team's productivity is bound by their 8-hour workday. To achieve 24/7 progress for critical support or rapid development, you either need disruptive night shifts or a way to pass the work across the globe. Follow-the-sun was designed for the latter, aiming to maximize productive hours in a day to reduce time-to-market.

THE MENTAL MODEL Think of it as a global relay race for a knowledge product, like code or an incident ticket. Each team runs their leg of the race during their business hours. At the end of their day, they pass the baton—the work and all its context—to the next team several timezones to the west. The goal is to keep the baton moving forward continuously.

HOW IT WORKS The workflow is designed to move west, following the sun. For example, a team in India works on a task and, at the end of their day, hands it off to a team in Europe. The European team advances the work and then hands it off to a team in the Americas. The Americas team continues and finally hands it back to the team in India to start the next 24-hour cycle. The success of this model hinges on a brief overlap between the handing-off and receiving teams to transfer context effectively.

WHEN TO USE IT This model is best for work that can be clearly documented and handed off. Two common applications are: first, 24/7 incident response for critical systems, ensuring an engineer is always available during their local business hours; and second, accelerating high-priority software development projects to meet aggressive deadlines.

WHEN NOT TO USE IT Follow-the-sun is a high-overhead model. It's a poor fit for tasks that require deep, uninterrupted focus that is difficult to transfer, like early-stage research or complex architectural design. If the handoff process is inefficient and the receiving team spends hours just getting up to speed, the coordination costs will outweigh the benefits of continuous work.

ONE CANONICAL EXAMPLE A critical production bug is found. The team in Bangalore, India investigates for their 8-hour shift and isolates the problem. They write a detailed ticket with logs and findings and hand it off to the London team. The London team develops a patch and pushes it to a staging environment. They hand off to the San Francisco team, who run final tests and deploy the fix. A bug is resolved in under 24 hours of continuous work, a task that would have taken a single team 2-3 business days.