When Does Follow-the-Sun Engineering Actually Work?

In May 2023, GitLab was working on Code Suggestions in the Web IDE. As the team discussed adding people across time zones, it placed a limit on part of the authentication work: keep a reviewer who already understood the context, so newcomers would not spend too much time getting up to speed. The review arrangement discussion

Tomas handed over a draft. Paul reviewed it and proposed changes that included tests; Tomas integrated the changes, and another reviewer approved the merge. Tomas himself described the collaboration as follow-the-sun. The draft handoff, the changes and merge record

The record does not tell us how long the work would have taken without the handoff. It does show a division of responsibility: other people advanced the review and implementation, while someone familiar with the problem retained responsibility for integration.

The appeal of follow-the-sun is straightforward. One location finishes its day, another keeps working, and delivery appears to lose a night of waiting. When a team deliberately arranges for another time zone to continue unfinished work while the original shift rests, it makes a commitment beyond ordinary asynchronous replies: someone will accept the work, have time for it, and know how far to take it.

Whether a particular handoff is worthwhile and whether to maintain the capability over time are separate decisions. For a handoff intended to improve the current delivery or on-call shift, compare it with waiting for the original author and other feasible divisions of work. Can the result be used sooner? Is rest better protected? Are those gains worth the additional coordination and the cost of delaying other work? The workload must also remain sustainable on both sides.

The longer-term decision also depends on whether the need recurs and what it takes to develop, maintain, and reserve the capacity to take over. Teams that already have that capability can still vary the scope and frequency of handoffs with the phase and urgency of the work.

Define what the next shift can finish

“We need to accelerate this feature” is not enough to choose a handoff. Work whose requirements are still being clarified needs different context, permissions, and room for judgment from implementation that is complete and awaiting review. The next shift need not take over the whole feature, but it must be able to leave a result that someone can use.

Consider a hypothetical situation. A fix is awaiting validation, its author is about to finish work, and there is a fixed release window the next day. The team expects that, if a test fails, waiting until the author returns to start investigating could leave too little time to make changes and rerun the tests. Automated checks can keep running; another region may be needed when a failure requires interpretation.

An engineer in that region might be able to reproduce the failure, distinguish an environment problem from a regression, and leave findings for the next step. If changes to the core logic still require the original author’s judgment, agree on how far the receiving engineer should go and when to seek help. A reproducible failure can be valuable in its own right. A commitment to deliver a releasable fix, however, requires people who can make and review the necessary changes. If the commitment includes going live, check release authority as well.

The receiving engineer needs a usable starting point: which version is being checked, what the results are so far, and what judgment comes next. If every step requires the original author to explain another assumption, work will stall on clarification even while the next shift is online. Time spent clarifying the problem together during overlapping hours may help more than dividing the task into smaller pieces.

The value of early investigation depends on where the author can resume. If the findings let the author make changes and rerun tests, they may help the team reach the release window. If some investigation must be repeated, include that time before deciding whether the handoff still creates useful headroom. If a required review cannot happen until after the window, early investigation alone will not get this release out in time. That headroom need not be used on every occasion to be worth retaining, but it must be usable when needed. Learning about a problem earlier is not the same as fixing it earlier.

Similarly, a global support team can respond quickly to a new customer message without ensuring that the same case keeps moving toward resolution across shifts. Receiving new work and continuing existing work can both be valuable, but they reduce different kinds of waiting. A measurement of first response time should not be presented as engineering repair speed.

Before scheduling the handoff, identify what would otherwise wait, what usable result the next shift can leave, and how that result changes subsequent work or the original shift’s burden. The scope should be small enough to accept responsibly and substantial enough to justify a handoff. Slicing it too finely can add clarification and waiting of its own.

Acceptance and capability both matter

A handoff first needs someone to accept it. In a June 2024 change to GitLab’s Development Escalation rotation, the team recorded a situation in which the current shift was ending but the incoming engineer was not responding. Even finding a replacement caused confusion, so the change documented the fallback process. The missed handoff and process change

For work that is still in progress, the handoff should include the recipient’s acceptance of a defined scope and identify who will coordinate a replacement or escalation if nobody takes over. Posting an update to a channel does not complete the transfer of responsibility. Nor should coordinating a replacement default to keeping the outgoing shift at work indefinitely.

Once someone accepts, the next question is what they can handle. A separate GitLab change merged in late 2025 explained that the Development Escalation rotation, originally intended to support the Rails monolith, had acquired a much broader remit. The engineer scheduled for the rotation might not know the area needing attention. The organization discontinued the general process and directed teams to Tier 2 subject matter experts. The change in expertise allocation

Both changes concern the same Development Escalation process, addressing acceptance and expertise at different times. They do not establish that the earlier missed handoff caused the later redesign. The feature work in the opening is a different kind of work again.

Check whether the recipient can reproduce the problem, access the right environment, change the relevant parts, and reach someone authorized to approve the result. If they also have project commitments, do they actually have time to act? Handoff notes can convey known findings. They cannot provide missing access, expertise, or capacity.

Complete independence from the previous shift need not be a condition of every handoff.

In a GKE incident described by Google, the on-call engineer in London handed incident command to a colleague in Seattle and became the technical response lead, continuing to work on the incident. The receiving engineer’s greater incident-response experience also influenced the transfer. Google SRE Workbook, Case Study 2

Coordination moved first; the original shift still contributed to the technical response. If the goal is to let that shift leave, its remaining responsibilities need a transfer plan. If the goal is to advance only part of the work, every role need not change hands. In feature development, the original author can return to integration during the next working period, provided that the wait is included in the completion time and responsibility for finishing is clear.

Finishing sooner and saving effort are different outcomes

A handoff can bring completion forward while requiring more effort.

A 2021 study of automotive wiring harness design offers a view of both elapsed time and engineering hours. It compared work by one engineer in Poland, one in Mexico, and a handoff arrangement with one engineer in each country. The three groups worked on similar but different models; there was no comparison with two engineers working in the same location. The handoff group finished in 6 days, against 10 and 11 days for the individual engineers. Yet it used 12 more design hours than the average of the two individual arrangements. Macura and Timofiejczuk’s original study, Section 8

This was a small trial outside software, with differences in the engineers’ experience. It cannot separate the effects of extra staffing, time zones, and differences in the work. It cannot predict a software team’s speedup, and the additional hours cannot all be attributed to handoff overhead.

Before comparing elapsed time, align the starting point and the definition of “done.” The handoff and its alternatives should use the same definition of when work begins, including preparation and coordination added for the handoff. Starting the clock only when the next shift begins would leave those costs out. Follow completion through to the agreed result, such as passing validation, restoring service, or being safe to release. Include rework and integration waits after the first output appears.

Keep every piece of work selected for the trial in the comparison, including work nobody accepts, work sent back and unfinished work; looking only at completed handoffs would hide part of the cost. Compare the result’s usefulness alongside person-hours, rework, calls back after a shift, and the receiving engineer’s deferred work. If staffing increases, compare other ways of using the same number of people. Similar past work can provide a reference; where records are missing, label the expected time under the original arrangement as an estimate. Do not simply subtract the duration of a short incident resolved in one shift from that of a long incident spanning a handoff. Difficulty, urgency, and quality requirements differ, and one trial cannot establish a general benefit.

Extra person-hours may be reasonable if earlier completion restores a customer’s service or meets a valuable deadline. If the goal is lower development cost, the extra hours need corresponding savings. Reporting only the number of days hides that trade-off.

The cost comparison must also fit the decision. If both locations already know the system and have the environments and on-call arrangements, do not assign all the training and coverage costs that would occur anyway to this particular handoff. Existing staff still have other uses, however. No additional headcount does not mean no cost.

If the proposal requires building capability in a second location, include the cost of establishing it, keeping it current, and reserving available capacity in the longer-term comparison. The same capability may serve routine reviews and support, so assess those uses as well. A single urgent handoff and an ongoing staffing arrangement cannot be evaluated against the same cost total.

Separate capability from how often you use it

Javier Turegano, who helped lead Slack Cloud Engineering, described how an established team varied its use of handoffs. During seasons with less overlap between Australia and the United States, the team kept some work within groups in the same time zone. Major incidents and urgent investigations instead used daily regional handoffs. Unplanned work had its own rotation, with those engineers stepping away from their project work. Running dual-homed teams across the world

This Slack team retained collaboration across regions while varying the arrangement with the season and urgency. Complex investigations could be handed over too. When deciding how often to do that, consider which findings a recipient can build on, which hypothesis they can test, and what waiting would cost. A label such as bug, feature, or incident is not enough to choose the arrangement.

Routine handoffs can also be worth evaluating. If the same kind of delay recurs and both locations regularly review, change, and validate work in the same area, investments in training, environments, and collaboration can support repeated transfers. If a specialty is needed for only a few urgent cases a year but requires another region to maintain proficiency continuously, compare that investment with specialist support, a stable division of work, and other alternatives.

Being unable to take over today means the team cannot currently rely on that capability. If waiting continues to be costly, joint reviews, shadowing, or handoffs with a limited scope can help develop it. Assess practice by whether the recipient becomes better able to complete the agreed scope, and include the investment in the longer-term evaluation. If the main obstacle is needing the other region to make every decision, change decision authority and the division of work first. Adding shifts is not a suitable response to both problems.

Slack’s capacity allocation for unplanned work makes the trade-off concrete: which existing commitments will the receiving engineer defer? If they are still expected to meet every project goal, the added burden may be hidden in delays elsewhere. Bringing urgent work forward should come with an adjustment to the commitments being postponed.

Rest for one shift must not overload the next

To assess the benefit of rest, first ask whether the work needs to continue after the original shift finishes. If waiting until the next working period still meets service and delivery needs, pausing already allows people to rest. Overtime by the original shift should not be the only alternative considered; otherwise, unnecessary overtime gets counted as a benefit of the handoff.

Fastmail distinguishes phases of the response. During an incident, restoring service comes first. Once service is restored, the follow-up work becomes less urgent and is coordinated through internal email. Its engineering on-call arrangement across regions still includes calling specialists when needed, and responsibility windows extend into early mornings or evenings. Fastmail’s account of support and on-call coverage

If the work must continue, compare extra hours, calls back after a shift ends, and the burden on specialists on both sides. Even without a shorter repair time, the arrangement may be worthwhile if quality and service requirements are maintained, the original shift can rest as planned, and the receiving shift’s workload is reasonable. Moving overtime to another region or concentrating it on a few specialists cannot be assessed only by the improvement for the outgoing shift.

Change the division of work when progress stalls

When receiving engineers repeatedly struggle to make progress, reconsider how the work is divided.

A 2006 IBM report discussed three web projects spanning the United States and India. The teams attempted to have developers in different locations continue work on the same code, but repeated staff changes and environment-access problems disrupted continuity. All three eventually assigned separate components to the locations. Following the sun: Case studies in global software development, Case Study 2

Staffing and access constraints affected these projects together, so the outcome cannot be attributed entirely to time zones. The report also lacks a fair performance comparison after the change. Alongside the opening GitLab example, it illustrates two scopes of collaboration. GitLab let others advance changes while retaining the author for integration; the three IBM projects moved regional responsibility to components, reducing repeated transfers of the same implementation. Teams can compare these arrangements to identify work that needs continuous understanding and results another location can build on.

Component ownership has costs too. If only one location can integrate and accept the work, waiting may simply move to a later stage. After changing the division of work, keep tracking overall delivery, rather than only whether each location has its own backlog.

Another alternative is to reduce the work that people need to pass on. Cloudflare’s Phoenix automates parts of server diagnosis and recovery while retaining three SRE shifts and controlling the burden caused by recovered servers failing again. Cloudflare’s Phoenix implementation

For recurring work with clear verification criteria, compare additional shifts, automation, and a combination of the two. In the hypothetical fix awaiting validation, if interpreting failures is the actual constraint, reserve the receiving engineer’s time for judgment and action. Include the maintenance and failure-recovery costs of automation alongside the staffing needed for handoffs.

Repeated checks are not automatically a sign of a failed handoff. Some verification properly requires another person to check the result again. An investigation may also restart because the previous shift’s findings are unreliable or difficult to use. Identify why work is repeated before deciding whether to improve the handoff, retain the check, or change the way the work is done.

Choose an arrangement for the next piece of work

Return to the fix awaiting validation. If another region can leave findings the author can use the next day, and those findings still help the team reach the release window after necessary rechecks, a trial handoff limited to investigation may be worthwhile. The workload and the cost of deferred work must be reasonable; agree on which commitments can wait. If the existing arrangement already leaves enough time to handle failures, while the receiving engineer would have to delay a more urgent repair, earlier validation alone is not a reason to hand over.

If every step needs clarification from the author, arrange time to work through the problem together during overlapping hours. If waiting until the author’s next working period does not harm delivery, headroom for handling failures, or rest, the work can wait.

Assess the intended outcome: was the agreed delivery result earlier, was the headroom for handling failures usable, or did the original shift actually leave? A smooth release that did not use the headroom does not by itself make the arrangement ineffective. A handoff that runs smoothly but offers no improvement worth retaining after comparison can also be stopped. Repeated clarification, capability gaps, or calls back to the original shift are reasons to adjust the scope or division of work. Reassess the need for frequent handoffs when the work enters a new phase.

Get Alex Chang’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Before maintaining or expanding the arrangement, establish whether the improvement justifies continued investment. Consider which future work will use the capability, whether the results depend on particular experienced people or temporary capacity, and the ongoing cost of maintaining quality, readiness to take over, and a sustainable workload on both sides. First identify which waiting is worth reducing and who needs to rest as planned. Then choose the scope, capability, and frequency of handoffs.

Appendix: Cases and Further Reading

The eight cases below draw on public work records, company implementation accounts, a manager’s retrospective, and a small study. They illuminate continuation, capability, effort, and alternative arrangements. They cannot be added together as eight independent validations of success or failure.

Start with Case 1 to follow an actual sequence of work. Read Case 2 and Case 3 to examine capability and responsibility. Case 4 compares elapsed time and effort; Case 5 and Case 6 examine different ways of organizing work. Case 7 and Case 8 extend the discussion of workload and automation. A separate practice note explains how to record a bounded trial without omitting incomplete handoffs. A source guide follows.

1. GitLab continued a feature change through review and revision

The authentication work for GitLab’s 2023 Web IDE Code Suggestions feature needed to connect the editor to a new authentication mechanism. The discussion expressed reservations about broadening the handoff and favored retaining reviewers familiar with the context. The subsequent work also used collaboration across regions. The review arrangement discussion, the authentication work item

The public merge request records a traceable sequence. Dates below are in UTC:

1. On May 23, Tomas shared a draft and asked Paul for feedback. The draft handoff
2. On May 24, Paul reviewed it and proposed changes with tests, identifying concerns with the original approach. The proposed changes
3. Tomas updated the approach and requested review. Enrique approved it, and the changes were subsequently merged. The update and review request, the merge record

This sequence distinguishes a status update from continued work: it produced new changes and tests while retaining integration by the author.

The records do not reveal individual working hours from the gaps between comments, and there is no comparison without the handoff. Merging code and enabling the feature for users are also different outcomes. The latter requires the subsequent internal enablement update and rollout closure. This case is useful for examining actions and responsibilities in a handoff, not for estimating a general speedup.

2. GitLab exposed gaps in acceptance and expertise

A June 2024 GitLab process change described a missed handoff. The outgoing shift was ending, the incoming engineer was not responding, and the team was confused about how to find a replacement. The change added steps such as calling the engineer, looking for another available engineer, and getting help from the on-call manager. An existing rule also required the outgoing engineer, for ongoing problems escalated to development, to confirm that someone had accepted the work or that someone able to coordinate had committed to arranging a replacement. The problem description, the process diff

A separate change merged in late 2025 addressed expertise. The Development Escalation process had originally supported the Rails monolith, but its remit expanded. The change explained that engineers in a general rotation might not know the specific area needing support and redirected the work to Tier 2 subject matter experts. Update Dev on-call process, rationale

These are changes to the same Development Escalation process at different times, addressing missing acceptance and a mismatch in expertise. There is no evidence that the earlier event caused the later redesign, nor a before-and-after performance comparison. This support process is different from the feature work in Case 1. The public Tier 2 description still includes arrangements across regions while listing coverage gaps and areas of best-effort support. The Tier 2 on-call description

A name on the schedule therefore leaves two questions: has that person accepted, and what can they handle? A fallback route addresses the first; domain knowledge and specialist support address the second. Maintaining expertise across regions for every area has a cost. Replacing a general rotation with specialists does not establish that enough capacity exists.

3. Google GKE transferred command while retaining technical involvement

Google’s SRE Workbook describes an incident in which GKE clusters could not be created normally. Zara, the on-call engineer in London, initially served as incident commander. She then handed command to Il-Seong, a Seattle colleague with more incident-response experience, and became Ops Lead. The team continued working together. Eventually, the GCR on-call engineer purged corrupt cached images and the errors subsided. Incident Response, Case Study 2

The command role moved while the original shift’s technical involvement remained. It shows that a handoff can separate coordination, technical response, and communication responsibilities without replacing everyone at once.

The response also involved additional experts, changes in the diagnostic path, and the actual repair. A transfer across regions preceding recovery is not enough to attribute recovery to time zones. This case is more useful as a comparison of role arrangements: as a problem evolves, a team can retain necessary context while transferring some responsibility. Whether the original shift gained rest must be checked separately.

4. A wiring harness trial separated time from effort

In 2021, Macura and Timofiejczuk reported a trial involving changes to 3D wiring harness models in Poland and Mexico. Three similar but different models were assigned to an individual engineer in Poland, an individual in Mexico, and a handoff arrangement with one engineer in each country. Automotive Wiring Harness Development with the Use of “Follow the Sun,” Section 8

The engineer in Poland took 10 days and 80 hours; the engineer in Mexico took 11 days and 88 hours. The handoff group took 6 days and used 12 more design hours than the average of the two individual arrangements. That average was 84 hours, giving a calculated total of 96 hours for the handoff group, an increase of approximately 14.3%.

Each arrangement had only one model, with differences in the work and the engineers’ experience. There was also no comparison with the same number of engineers in one location. The figures describe this trial; they cannot isolate time zones, staffing, and difficulty, much less represent the time to market of an entire car.

The useful comparison is that reducing completion time and reducing effort can yield different answers. A team trying to meet a deadline should discuss the value of earlier completion together with the extra effort. A team seeking more output per person-hour cannot rely on the 6-day result alone. Management and quality costs also need to be accounted for.

5. Slack varied the arrangement with the situation

In a 2023 retrospective, Javier Turegano described helping lead Slack Cloud Engineering from 2019 onward. When Australia and the United States had fewer overlapping hours, some work moved to groups within the same time zone. With more overlap, the groups mixed across regions again to encourage knowledge sharing. Major incidents and urgent investigations used daily handoffs. The retrospective, Seasonal work-stream modes and Crunch time

The same account describes a rotation for unplanned work with one person in each region. While on that rotation, engineers were not expected to keep meeting their original project goals. Support capacity became an explicit allocation rather than extra work stacked onto everyone’s existing commitments.

The retrospective provides neither per-item acceptance times nor a comparison of outcomes. It cannot establish an optimal overlap or a uniform Slack-wide policy. Its contribution is to show that frequency can be adjusted: a team can keep developing the ability to collaborate while using intensive handoffs for particular work or circumstances. Evaluation should include both the work brought forward and the capacity given up for it.

6. IBM moved from continuing the same code to component ownership

In a 2006 IBM Systems Journal report, Treinen and Miller-Frost discussed three web projects across the United States and India. Developers attempted to continue the same code across regions, but scheduling caused frequent reassignment and made continuity difficult. All three projects eventually assigned discrete components to the locations. Following the sun: Case studies in global software development, Case Study 2

In two of the projects, the Indian team never obtained the necessary access to the customer’s development environment. Updates were sent by email, FTP, or intermediate storage, then loaded into the customer’s environment by the US team. The report also describes environments that were often out of sync. Clear handoff notes could not remove the need to route updates through the other location or ensure that the receiving engineer could work from the same state.

The report also describes specifications that seemed sufficient locally but contained assumptions the remote team could misunderstand. Some rework and development subsequently returned to local staff. Access to code was only part of the problem; the transferred work also needed enough information for the recipient to continue making decisions.

This was not an experiment that changed only time zones, and it did not supply a fair performance comparison after the three projects changed their approach. The concrete alternative was to move responsibility between locations to component boundaries, reducing repeated handoffs of the same implementation. Compared with Case 1, where others made changes and the author integrated them, the teams chose different scopes of collaboration. Neither is thereby shown to be universally better. Component ownership still requires clarity about integration, requirements, and acceptance, or waiting may move to a later stage.

7. Fastmail combined coverage with access to specialists

In 2024, Fastmail described support staff in Australia, the United States, and India, with engineering on-call coverage across Australia and the United States. Its stated engineering responsibility windows were 08:00–22:00 local time in Australia and 06:00–16:00 local time in the United States. These are responsibility windows, not continuous working hours for each person. Dec 12: Following the Sun

Support staff could use logs and administrative tools to resolve some issues that otherwise needed engineering help. Specialists or technical owners could still be called for particular situations. During incidents, service restoration came first; once service was restored, the remaining work became less urgent and was coordinated through internal email. The arrangement involves coverage hours, the ability to act, and the phase of the response. The source does not quantify a reduction in cases escalated to engineering.

This separates continuous service coverage from intensive continuation of every follow-up task. When evaluating rest, establish which phase needs continuous work, then examine how much still comes back to the original shift or a few specialists. The source does not provide enough data to calculate a reduction in nighttime calls, so the schedule alone cannot establish equal improvements in rest for everyone.

8. Cloudflare combined automation with shifts

Cloudflare introduced Phoenix in 2024 as a system that automates parts of faulty-server diagnosis, reprovisioning, and recovery, leaving physical component replacements to people. To control the burden of recovered servers failing again, it manages an error budget in periods aligned with three SRE shifts and stops automatic recoveries when the allowance is exceeded. Autonomous hardware diagnostics and recovery at scale

This is a company account of an implemented system, without a separate estimate of the benefit attributable to time zones. It does not show that automation eliminated on-call work. People still handle exceptions, and a machine recovered in one period may generate fresh failure work in the next.

When evaluating additional handoffs, examine which manual actions could be reduced and who would bear any new risk. Automation can change the amount of work passed to the next shift. Its maintenance and failure handling belong in the overall cost, alongside the manual steps it saves.

Practice note: Keep incomplete handoffs in the comparison

The following is the author’s guidance for a bounded trial, not a procedure demonstrated by the eight cases or evidence of a company outcome. It makes the article’s comparison criteria usable when recording actual work.

Before a trial, define the scope to be continued, the completion standard, the starting point for elapsed time, and a feasible arrangement without the handoff. Include every piece of work selected in advance for the trial, including work nobody accepts, work sent back, and cleanup left to the original shift. Record when the handoff was ready, when it was accepted, when the first verifiable result appeared, and when the agreed result was actually achieved. These milestones help locate delays. Leave milestones that have not occurred marked as incomplete, with the reason; compare total elapsed time separately from the common starting point.

Use these milestones to locate where work stopped or continued; they do not replace the common starting point and agreed completion standard used to compare overall elapsed time. Read the records alongside the work actually made usable, the quality required and the capacity consumed.

Source guide

• GitLab Web IDE authentication changes and merge record: public work records from 2023; see Case 1.
• GitLab’s missed-handoff process change and Development Escalation change: the 2024 fallback process and the expertise-allocation change merged in late 2025; see Case 2.
• Incident Response in the Google SRE Workbook: the incident account in Case Study 2; see Case 3.
• Macura and Timofiejczuk’s wiring harness study: the original 2021 paper, Section 8; see Case 4.
• Javier Turegano’s Slack team retrospective: a participant’s account published in 2023; see Case 5.
• Treinen and Miller-Frost’s IBM case study: the 2006 journal report, Case Study 2; see Case 6.
• Fastmail’s Following the Sun: the company’s 2024 description of support and engineering on-call coverage; see Case 7.
• Cloudflare’s Phoenix implementation: the company’s 2024 engineering account; see Case 8.