When the Owner Is Offline, Can the Work Continue?
In 2023, GitLab’s Web IDE team was changing authentication for code suggestions. Tomas handed over a draft for Paul’s feedback. Paul proposed changes with tests; Tomas returned to integrate them, and another reviewer approved the merge. The public record shows a concrete division of work: another engineer continued part of the change while the original author retained integration responsibility. GitLab Web IDE continuation
The record supports partial continuation. It provides no comparison with the time needed without a handoff, and does not establish that the original author was unreachable throughout. The appendix groups direct continuation records and comparisons of the conditions needed for a handoff by theme.
For an engineering manager, a handoff should answer a question that guides the assignment: What useful work can this person advance with their current understanding, permissions, environment, and capacity? That question determines what needs to be written down. The recipient still exercises engineering judgment; the handoff should reduce unnecessary reconstruction before that judgment can begin.
First decide which responsibility is moving
A PR may need changes, review, integration, and release. Another engineer accepting one part does not establish that every other part has moved. In the GitLab example, the author retained integration while the recipient could propose changes. Both need to know where the result returns and which responsibilities remain under the existing arrangement. If integration still waits for the author, this is partial progress during their absence. A deadline requiring earlier delivery also needs someone with the capability and authority to accept integration.
A Google GKE incident illustrates another division. Zara transferred incident command to the more experienced Il-Seong and became Ops Lead, continuing technical work. Command had moved, but the original on-call engineer had not left the response; recovery also required other specialists and operational work. Google GKE incident account
Ordinary development does not need an incident-command structure to ask a useful question: are we moving execution, interpretation, coordination, or end-to-end delivery responsibility? If the purpose is to let the original owner rest, identify the remaining obligations that could still call them back.
The scope also needs a purpose. If the missing answer concerns requirements, do not invent a testing assignment merely because a colleague can run tests. Establish who needs the result for which decision, then choose a recipient. Judge waiting against the intended commitment: who is affected by delay, when the result is still useful, and which work a substitute would displace. Keeping the original owner remains an option when that wait is acceptable.
A receiving contact still needs to accept the work
A GitLab support-process change records a missed handoff: the current shift was ending, the next engineer had not responded, and the team was unclear about finding a replacement. The change added contact, fallback, and on-call management steps. A name on the schedule had not automatically transferred the work in progress. GitLab handoff and fallback change
That operational-support example needs immediate coverage. An ordinary PR may not require telephone escalation or a receipt for every item, but the underlying distinction remains useful: has the person merely received a message, or accepted a piece of work with time to do it? If not, arrange a substitute, narrow the scope, or make the wait explicit according to urgency.
Work requiring continuous coverage needs the existing escalation and on-call arrangements to handle a receiving gap; nobody accepting the work does not itself authorize interrupting the service. Without overlapping working hours, agree in advance who will receive the work, when acceptance will be confirmed, and who coordinates if that fails. Discovering an unaccepted task after the author goes offline should not silently make them the permanent fallback.
The recipient can identify what they can accept and what needs adjustment. If the assignment displaces existing commitments, involve whoever can change priorities rather than treating acceptance as costless consent.
Someone who understands a component but lacks an integration environment can accept a useful local check, or accept coordination to obtain the environment. Accepting that coordination is a commitment to work, not evidence that the environment is already available. Required integration work that nobody has accepted remains a visible blocker. Coordinating its prerequisites does not silently assign all subsequent verification and fixes to that coordinator.
Supply enough context for the recipient to judge
Yahoo Search had release rotations and automation across countries while important knowledge remained concentrated in the US. When automated tests failed during other regions’ working hours, local engineers could still be left waiting. The teams arranged overviews, deeper explanation, time to absorb material, contacts, and question sessions, then transferred release responsibility in stages. Yahoo Search release and knowledge transfer
The account includes staffing, organizational, and automation changes; their effects cannot be attributed to documentation or one explanation session alone. For a particular handoff, ask whether the recipient can interpret a failure or can only send the question back to the author. That distinction matters especially when the author cannot reply until their next working period.
Someone familiar with the component may need only recent changes and unresolved questions. A newcomer may also need the use case, expected waiting behavior, and failure signals. Ask the recipient how they intend to proceed and interpret the result, then supply the material that changes their next step. Reference usable existing records and keep the remaining history retrievable. A newcomer can accept a supported piece of work whose results they can interpret without first learning the entire system. If shared exploration or specialist help is needed, arrange that participation.
Preserve the existing reasoning so the recipient can also challenge it: if new observations change the problem, bring the concern back to the relevant discussion. Renegotiate the accepted scope when necessary, rather than continuing work that is no longer useful just to finish the old steps.
The ability to take over may need to develop gradually. Backup can be part of the arrangement, provided it is clear who can supply which help and when; recipients do not need to be fully independent from the outset. Recurring handoffs require continued development of that capability. A handoff message can draw on conditions already established or identify what still needs to be supplied.
Make evidence and permissions support the same assignment
LLVM D40988 reached an approved state while its author lacked commit access. The discussion established whether someone needed to commit it on the author’s behalf, and another participant eventually did so while preserving attribution. Earlier discussion also involved technical questions, so the entire history cannot be attributed to commit permissions. LLVM D40988, recorded commit
Approval still needs to connect to someone able to execute the next step. Check the capabilities and permissions needed for this assignment: reading material, starting verification, modifying code, approving, and committing may belong to different people. Do not broaden permissions merely to make one person do everything, or mistake missing permissions for insufficient documentation.
Evidence has a scope too. The cloud-provider-aws continuation preserves a review about users who may lack AWS permissions, a fixed implementation, and mock-test expectations. The analysis here is limited to reading the implementation, review, and tests; it includes no test execution or live AWS verification. Test files describe expectations, while execution records supply observations under specific conditions. Even matching observations do not establish that the expectations fit the complete requirements. The recipient needs to know which reasoning can be reused, what behavior still needs observation, and which decision will use it. Original review, tests at the fixed revision
Return a usable result and the questions still open
VS Code #162163 explicitly passed a failing-test investigation to that week’s build champion. The recipient left a symbolized stack, possible leads, and a judgment that information was insufficient. The issue was later closed automatically for insufficient information and inactivity; that does not establish a fix. Investigation transfer, subsequent analysis
A useful result can be a fix, a reproducible difference, an eliminated hypothesis, or a supported account of what is missing. When arranging work, explain how that result will be used instead of requiring every investigation to produce a definite answer.
Consider a hypothetical assignment based on that AWS change: a reviewer needs observations for two error scenarios covered by existing mock-test expectations. The recipient could confirm: “I have capacity for these two scenarios. I will reuse applicable results or obtain needed observations, returning the revision, actual commands, and output to this discussion. If conditions are missing, I will record the stopping point and help needed. Integration verification still needs an arrangement.” This illustrates partial acceptance; it is not the original PR’s handoff. Requirements judgment can proceed in parallel.
When the result returns, the reviewer uses it to arrange the next work. A difference needs someone to accept its investigation; an answered local question may leave requirements or integration work. Report a static reading as analysis and a test that could not run as an execution blocker. Those results should not all be called “verified.”
Check relevance before starting and when returning the result. The code may be unchanged while someone else has completed the task or a new arrangement has replaced it. Changed code does not erase what an old result says about its revision; inspect the change’s effect before deciding what to check again. A result being valid and a task still needing work are separate judgments.
Work continuing does not make constant handoffs worthwhile
An IBM Watson account of US–Tokyo collaboration records required features finishing early alongside the burden of daily handovers, reviewing each other’s work, and contact outside normal hours. The author describes the intensive arrangement as difficult to sustain; after establishing the foundation, the teams focused on different features. This is participant experience, not evidence that handoffs alone caused early completion. IBM Watson collaboration account
Count preparation, the recipient’s understanding and execution, specialist support, and displaced work. Local progress may reduce uncertainty without removing the most important environment or approval blocker. If continuation repeatedly relies on the author answering after work, revisit capability, support, or the boundary of the assignment.
A separate IBM US–India account describes frequent personnel changes, environment access, and requirements understanding limiting serial work on the same code. The projects moved to component ownership by location. Integration and acceptance still needed responsibility, but repartitioning became an option. Tyger #123 records a different arrangement: the author paused work until after vacation, to revisit it if still relevant. Neither case establishes waiting or repartitioning as universally better. IBM US–India projects, Tyger pause
Start with the next piece of work that actually needs to change hands: who has accepted which scope, what conditions are missing, and who will use the result? Afterwards, examine who actually used the result for which decision or next step, which questions still required follow-up, and whether the effort was worthwhile. Supply context or adjust capacity where needed; when the conditions do not hold, explicitly choose to wait or change the division of work.
When the original owner is offline, a dependable arrangement lets the next person know how far they can proceed, while keeping missing conditions, unaccepted work, and necessary new judgments visible.
Appendix: Cases and Further Reading
These 33 cases are grouped around six questions about handing work over. The first two paragraphs of each case describe the recorded situation, actions, and known results. The third explains their relevance and the limits of applying them when an owner is offline. Public work records, company retrospectives, and studies support different kinds of claims; companion sources about the same event are grouped together.
- Scope: which part of the work changes hands
- Usable context: how the recipient begins judging
- Receiving capability: acceptance needs support
- Authority and responsibility: who can take the next step
- Capacity and burden: whose time continuation uses
- Waiting and repartitioning: when to change the arrangement
Scope: which part of the work changes hands
1. cloud-provider-aws: a reviewer with prior context continues the work
Material date: October 2024.
Context and approach. The change adding AWS network-topology labels to nodes was unfinished when its original author went on vacation. mmerkes opened #1038 to continue #1025. He had already reviewed the earlier PR and raised the use case of non-EKS users without the required AWS permissions, so he was not encountering an unfamiliar problem from scratch.
Work and result. The recipient retained the earlier contribution, refactored the change, identified tests still to add, and continued responding to review. The new PR merged and the old one pointed to it. The fixed revision handles UnauthorizedOperation specially; tests include that scenario and one other unhandled error sample. The analysis here is static: no tests were executed and no live AWS verification was performed. The hypothetical assignment in the main narrative uses historical revision 3359aa4 and checks getNodeTopology against the existing mock expectations for UnauthorizedOperation and one other unhandled error sample; it is not a documented handoff from the PR.
Interpretation. The arrangement needs to account for what a particular recipient already understands and what evidence or support they still require. Document completeness alone cannot answer that question. The public record does not include a complete handoff document, a time-zone arrangement, or comparative costs of waiting and transferring; merging cannot establish the effectiveness of a handoff format.
Original sources: cloud-provider-aws continuation PR #1038; Earlier review: the access-denial use case; Continuation notes, changes, and tests still planned; topology.go at the retained fixed revision; topology_test.go at the retained fixed revision; Closure of the original PR and the continuation pointer.
2. GitLab Web IDE: another engineer revises, the author integrates
Material date: May 23–24, 2023 (UTC), followed by a subsequent merge.
Context and approach. In 2023, GitLab’s Web IDE Code Suggestions work needed to connect the editor to a new authentication mechanism. The surrounding discussion favored reviewers who already understood the context, while the implementation still used work across regions. The public merge request provides a traceable sequence of a draft being offered, revised by someone else, and integrated by its author.
Work and result. On May 23, Tomas shared a draft and asked Paul for feedback. On May 24, Paul proposed changes that included tests and identified concerns with the initial approach. Tomas then revised the approach and requested review; Enrique approved it, and it merged. The continuation produced substantive changes while the original author retained responsibility for integrating them.
Interpretation. This is a useful example of transferring a bounded part of the work. The recipient could propose code and tests without becoming responsible for every remaining decision. A team can specify that boundary and the expected return artifact before the owner leaves. The record demonstrates continuation, but comment timestamps cannot establish working hours saved, and merging does not by itself establish user availability. The public record also does not establish that the author was unreachable throughout, and merge is not rollout.
Original sources: GitLab Web IDE MR 183; Draft handoff; Receiving engineer’s changes.
3. Google GKE: command transfers while technical involvement continues
Material date: The retained source does not establish the event date.
Context and approach. Google’s SRE Workbook describes an incident in which GKE clusters could not be created normally. Zara, the on-call engineer in London, initially acted as incident commander. Il-Seong, a colleague in Seattle, had more incident-response experience. The team needed to change how responsibilities were distributed while preserving technical work already under way.
Work and result. Zara handed incident command to Il-Seong and became Ops Lead, continuing to work with the team. Eventually, a GCR on-call engineer purged corrupt cached images, after which errors subsided. The response therefore combined a transfer of coordination responsibility with continuing technical participation, additional expertise, a changing diagnostic path, and the repair itself.
Interpretation. A handoff can move one responsibility while others stay with the original engineer. This case helps distinguish transferring command from completing an entire shift handover, and makes the remaining involvement visible. A team should state which responsibilities have moved and which still depend on the original person. The account does not show that Zara became unavailable or could immediately rest.
Original sources: Google SRE Workbook: Incident Response, Case Study 2.
4. BrazilSoft: accepting a direction still left drafting, conditions, and approvals
Material date: Negotiation June 22–July 14, 2017; study published in 2019.
Context and approach. BrazilSoft and its customer originally fixed, validated, and deployed E-Account work ticket by ticket. Missed validation, notification, or deployment delayed releases and generated disputes about fines. Peter proposed batch validation; John feared that the customer would hold a whole batch for additional features. Operations explained that integrated code could not be separated again for ticket-by-ticket validation in that workflow.
Work and result. After the June 2017 discussions, John undertook to draft the process and expressed acceptance of the direction in the customer-facing group while preserving the requirement for both parties’ approval. In July, the draft was revised and approved by the supplier and then the customer. The study traces those actions without publishing the complete process or delivery measurements.
Interpretation. The offline-owner analogy is that accepting responsibility for a draft does not grant every approval required to proceed. This is an editorial application of the negotiation record. Conditions need to remain attached as work moves between people, but the published study does not establish how the original batch-wait concern was resolved or whether approval reduced waiting and fines.
Original sources: How a geographically distributed software team managed to negotiate successfully using chat technology; Original CC BY 4.0 study.
5. Austrian development and testing: rejection rights did not change commitments by themselves
Material date: 2014 publication; precise event dates not retained.
Context and approach. Vallon and colleagues studied development and testing at two sites in the same Austrian city. Initially, finishing development counted as acceptance, with testing following later. The intended preparation of test cases before sprint selection rarely happened. After deployment failures, testing became more involved and gradually acquired explicit rights to reject work that was not acceptable.
Work and result. Rejections continued because performance and stability were still not adequately reflected in commitments. Later, shipping to the customer each sprint accompanied author-reported improvements in planning, impediments, and defect stability. Other changes occurred too, including visits between sites, and a researcher served as the testing team’s Scrum master, preventing attribution of the result to a single intervention.
Interpretation. For an offline handover, the editorial comparison is to ask whether the last rejection changed the next completion criteria and allocated work. The source is not a cross-time-zone handover experiment and does not prescribe one delivery frequency. Giving receivers the right to reject work does not by itself ensure that subsequent deliveries incorporate what they need.
Original sources: Adapting to Changes in a Project’s DNA; Author-shared full paper.
6. Salesforce: willing contributors still needed a workable boundary
Material date: Collaboration began in late 2018; publication year unconfirmed in retained metadata.
Context and approach. In late 2018, another team wanted to add functionality to Salesforce’s main mobile app. Asking the app team to implement it created a prioritization problem. Sending contributing engineers brought different questions: learning the host code, preserving quality, and maintaining the contribution after those engineers returned to their own team. Available people did not automatically constitute work the host could accept.
Work and result. The teams jointly defined a plug-in architecture and interfaces, and the first adopting team integrated its contribution months later. Feature teams owned their modules while the host team supplied shared capabilities and support. Mobile modules still built and deployed with the main app, so the arrangement separated maintenance responsibilities without creating a fully independent release path.
Interpretation. Applied by analogy to an owner being offline, this case asks whether a receiver has a bounded contribution they can continue and which judgments still require the original team. The source does not document an offline handover experiment. It supports examining acceptance and maintenance boundaries, but supplies neither total labor costs nor evidence that modularity removes every wait.
Original sources: Scaling cross-team contributions to a native mobile app.
Usable context: how the recipient begins judging
7. Slack: Implementation work can still need a shared data-flow explanation
Material date: 2022–09–20 (retrospective publication).
Context and approach. A Slack intern working on the Mentions tab needed to integrate activity data arriving through APIs and WebSockets. His manager suggested first understanding how the data flowed. Implementation and review followed, but the data-provider approach still needed clarification. Having code available did not mean that everyone already possessed the technical understanding required to continue the work confidently.
Work and result. The author asked to enter a Huddle with two Staff engineers, where they revisited the data-provider approach together. The retrospective records preparation, implementation, review and expert exploration, but supplies neither a complete call record nor a timing comparison. It supports saying that expert assistance contributed to clarifying direction, not that a single call completed the entire feature.
Interpretation. A handoff may transfer code while leaving a gap in the understanding needed for the next judgment. This case helps identify where access to particular expertise might still be necessary. It did not test work during the original owner’s absence, and the author’s estimate of potentially saved time cannot be presented as a measured benefit of synchronous assistance.
Original sources: Stephen Dolan, Blocked: How to Ask For Help as an Intern.
8. Spotify: Stockholm reuses a decision recorded in New York
Material date: 2019 work; 2020 account.
Context and approach. In 2019, Spotify’s Creator team experimented with React Hooks, discussed the approach, and decided to develop new components as function components. Josef Blake’s later account describes architecture decision records left by the New York team being read, referenced, and adopted by colleagues in Stockholm. A local decision thus became material for work in another office.
Work and result. The participant account reports actual cross-office use of recorded decisions, rather than merely their creation or storage. It does not publish the original records, their maintenance effort, or comparative results. A shared technology stack and other communication could also have supported adoption, so the account cannot establish that the receiving team needed no additional explanation.
Interpretation. Useful context is material another person can apply to a current decision while its author is elsewhere. Start by checking whether the existing record supplies the relevant reasoning and conditions, then identify what remains missing. This supports reuse as a practical aim; it does not establish that an ADR format, by itself, eliminates questions or guarantees independent work. The source establishes neither a specific author-offline interval nor the absence of further communication.
Original sources: Spotify: When Should I Write an Architecture Decision Record?.
9. GitLab database incident: steps did not explain what waiting meant
Material date: 2017–01–31 incident.
Context and approach. On January 31, 2017, GitLab engineers working on database replication encountered a long period without clear output from pg_basebackup. An engineer who was not present knew that this could mean waiting for the primary to send data. Neither the runbook nor the official documentation at the time clearly explained that behavior to the people responding.
Work and result. Primary database data was accidentally deleted during the response, while failed backups and other problems complicated recovery. Follow-up work included documentation and recovery tests. The account does not show that a documentation change prevented recurrence, and the incident involved operational judgment, tool safeguards, and backup capability. It cannot fairly be attributed to one missing explanation.
Interpretation. When the person with local knowledge is unavailable, a procedure needs to support interpretation as well as execution. Readers may need to distinguish normal waiting, failure signals, and conditions for stopping or escalating. Use this incident to identify such gaps, while retaining responsibility for safeguards and recovery capability; more complete instructions alone are not a sufficient guarantee of safe operation.
Original sources: GitLab database outage postmortem.
10. IBM WIRE: a recorded load limit was absent from later decisions
Material date: 2018 experience report.
Context and approach. IBM Watson Discovery’s WIRE team knew that a certain level of usage would create performance problems and recorded the load limitation in an architecture decision record. Its 2018 experience report describes the training system struggling with increased load nine months after launch. The team had forgotten a limitation that was already documented.
Work and result. The same account also describes reconsidering a previously rejected technology after requirements changed and finding design flaws through paired diagramming when consequences were hard to explain. These are distinct experiences of forgetting, reusing, and developing context. They do not form a demonstrated sequence in which the load problem led to reminders that then produced a measured improvement.
Interpretation. A handoff must help later work recognize which recorded constraints matter and whether their conditions still hold. Merely preserving a decision cannot ensure that a recipient knows when to consult it, especially without the original author’s help. This case supports checking actual reuse, but provides no test of a particular reminder mechanism or evidence that record counts predict reliability.
Original sources: Michael Keeling and Joe Runde: Distribute Design Authority with Architecture Decision Records.
11. Ansible: an individual answer still needs a reusable entry point
Material date: 2018 issue; documentation change merged 2020–08.
Context and approach. In 2018, an Ansible user wanted subelements to skip items without a specified subfield but passed skip_missing as a string. Discussion established that the optional third argument needed a dictionary of flags. It also exposed another requirement: loop expects a list, while lookup does not always return one. The example depended on more than one unstated condition.
Work and result. After learning that query guarantees a list, the original reporter said in May that migration had succeeded. Another user still reached the discussion in November because related guidance was difficult to connect. A documentation change merged in August 2020 explicitly stated the dictionary requirement and used q in the loop example; the dictionary form had already appeared in an earlier example.
Interpretation. Solving one person’s question does not ensure that later readers can proceed without the original helper. Shared conditions and type requirements can be returned to the documentation entry point so subsequent users can adapt an example. Keep the observed individual success separate from the later edit: the record does not establish that the revised page improved understanding for everyone.
Original sources: Ansible subelements discussion 38182; Ansible documentation correction 71177.
12. VS Code: an investigation can move forward without a fix
Material date: September–October 2022.
Context and approach. After VS Code integration tests failed, the discussion identified a possible crash during testing and pointed to a dump attached to the pipeline. The investigator explicitly passed the work to that week’s build champion. Those pointers locate subsequent work, but the article did not obtain the original dump or complete execution logs.
Work and result. The recipient left a symbolized stack, possible leads, and an explicit judgment that information was insufficient. Another run was linked later. A bot eventually closed the issue for insufficient information and inactivity. That administrative ending does not establish a repair, and present retrieval limitations do not establish what participants could access at the time.
Interpretation. A useful investigation handoff can deliver analysis and a specific evidence gap. It need not manufacture a root cause to look complete. Whoever arranges the next work must distinguish completed investigation from missing conditions. This record establishes an investigation transfer, but does not establish an offline owner, different time zones, or an end-to-end transfer of responsibility.
Original sources: VS Code #162163: remote integration test failures; Comment transferring the investigation; Analysis and remaining uncertainty; Another CI run; Automatic closure comment.
13. Oxide/Hubris: shareable diagnostic material and the boundary of reenabling
Material date: March 2024.
Context and approach. Cliff L. Biffle’s engineering retrospective describes a network-switch investigation and shareable failure snapshots that permit analysis without every participant having physical hardware. Hubris #1672 separately records a problem involving earlier design assumptions and a packing change, together with the decision to disable that behavior temporarily.
Work and result. A later comment distinguishes the author’s report that the issue was fixed from packing still being disabled, and mentions unit tests in a new crate. The article did not obtain the original snapshots or chat, independently inspect related #1671, run the tests, or establish when the behavior was reenabled.
Interpretation. Usable diagnostic material can let others participate, while restoring use remains a separate piece of work to confirm. This is a comparison about material usability and status boundaries, not established evidence of an offline-owner handover. Keeping that distinction permits borrowing a practice without turning the engineering retrospective into an effectiveness claim it cannot support.
Get Alex Chang’s stories in your inbox
Join Medium for free to get updates from this writer.
Original sources: Who killed the network switch?; Hubris #1672: leases spanning MPU regions; Discussion separating repair from reenabling.
Receiving capability: acceptance needs support
14. GitLab development escalation: a scheduled name is not acceptance
Material date: Process changes in June 2024 and in 2025.
Context and approach. A June 2024 GitLab process change described an outgoing shift reaching its end while the incoming engineer did not respond. The team became confused about finding a replacement. A person had been assigned on the schedule, but that assignment had not turned into an accepted transfer of the ongoing development escalation.
Work and result. The change added calling the engineer, seeking another available engineer, and involving the on-call manager. Existing rules also required confirmed acceptance or a commitment to coordinate replacement. A separate redesign in late 2025 redirected expanded development support toward Tier 2 subject matter experts because general rotation engineers might not know the affected area. These were distinct changes to the same workflow.
Interpretation. The combined workflow illustrates two checks that should remain separate: whether anyone has accepted responsibility, and whether that person can perform the needed work. A fallback route answers the first question; suitable expertise and available capacity answer the second. The records do not establish that the missed handoff caused the later redesign, or that either change produced a measured improvement.
Original sources: Missed handoff and fallback process; Process diff; Later specialist support redesign; Tier 2 coverage description.
15. A new Google SRE team: taking the lead with explicit backup
Material date: The retained source does not establish the event date.
Context and approach. Google describes a new Mountain View team preparing to take responsibility for services through project work, debugging, disaster scenarios, and exchanges between sites. The transfer involved developing the ability to handle real operational problems, rather than simply changing a named owner in documentation. The original Kirkland team remained part of the support arrangement during the transition.
Work and result. In the third month, Sara, Mike, and a transfer engineer began primary on-call duty with backup from the Kirkland team. Other newcomers later joined rotations alongside more experienced local colleagues. Taking primary responsibility and retaining support occurred together, creating a staged transfer in which the new team could lead without every exception becoming an unsupported individual decision.
Interpretation. Primary ownership and complete independence should be distinguished when planning an owner’s eventual absence. Specify the work the receiving team will lead, the exceptions that retain backup, and how actual handling will be observed. The third-month milestone belongs to this account; it is not a universal deadline, and smaller teams must account for the experienced people and support capacity required. This was a supported team takeover, not evidence that the former team was unreachable or that every member was independently ready.
Original sources: Google SRE Workbook: Being On-Call, Forming a New Team.
16. NNG: Taking support responsibility did not mean immediate repair
Material date: 2015–10–16 (retained arXiv entry); intervention 2015–03–02–2015–05–03.
Context and approach. NNG’s core team initially shared responsibility for watching a support chatroom, exposing several developers to continuing interruptions. A weekly support rotation gave incoming requests a more explicit first destination. Nevertheless, resolving requests could still require specialist knowledge, and the rotation member’s attendance at a meeting did not automatically provide someone else to cover incoming support work.
Work and result. The team combined the rotation with policies, an FAQ and muting guidance. At a nine-week retrospective, participants reported less continuous monitoring and a smaller support burden even though average daily messages increased. The account still records difficulties finding experts, classifying urgency, providing substitution during meetings, and managing requesters’ expectations that the support person would immediately fix bugs.
Interpretation. A rotation can identify the first person to contact without establishing that work will finish while its usual owner is absent. Scope, access to specialists and substitution remain practical conditions to inspect. That interpretation is not an individual productivity result. The retained paper also contains a table inconsistency, so a reconstructed percentage should not be used to strengthen its reported benefits. The journal and conference versions of the same study are not independent samples.
Original sources: Refactoring Technical Support to Reduce Interrupts of Developers.
17. Fastmail: regional coverage still needs specialists and follow-up work
Material date: 2024 company account.
Context and approach. In 2024, Fastmail described support staff in Australia, the United States, and India, alongside engineering on-call coverage across Australia and the United States. Its stated engineering responsibility windows were 08:00–22:00 and 06:00–16:00 in the respective local times. These windows describe coverage responsibilities, rather than continuous working hours for each individual engineer.
Work and result. Support staff could use logs and administrative tools to resolve some issues, while others required engineering help. Specialists and technical owners could still be called in particular circumstances. During incidents, restoration came first; after service returned, remaining work became less urgent and was coordinated through internal email. Continuous coverage did not require equally intensive continuation of every follow-up task.
Interpretation. To judge whether an owner can be unavailable, distinguish the tools recipients can use, the exceptions requiring specialists, and the phase when continuous work can stop. Coverage schedules alone do not demonstrate that every expert receives more rest. A team needs to examine where escalations and follow-up work actually land, including work that returns to the original location. The source does not measure a reduction in engineering escalation or nighttime calls.
Original sources: Fastmail: Dec 12, Following the Sun.
18. Dropbox: technical conversion still needed receivers with product knowledge
Material date: Migration began in 2015; two related retrospectives in 2018.
Context and approach. Dropbox’s desktop migration from Python 2 to Python 3 established compatibility and checks against regression before expanding testing and rollout. Central engineers could provide the loading and conversion mechanisms, but judging whether particular desktop features still behaved as expected required participation from people with knowledge of those features and their product context.
Work and result. Two accounts of the same migration describe implementation and rollout, including inviting feature-owning teams to concentrated testing sessions. Migration problems needed attention before wider rollout, while dual-version support, testing, and maintenance remained transition costs. The technical arrangement reduced the need for everyone to switch simultaneously without eliminating the contribution required from feature specialists.
Interpretation. The editorial analogy for an offline handover is to distinguish being able to execute a procedure from being able to judge its result. This source concerns a product migration rather than substitute on-call work. Its two articles describe one event, and neither establishes complete cross-team allocation decisions or proves that gradual rollout always costs less.
Original sources: How we rolled out one of the largest Python 3 migrations ever; Incrementally migrating over one million lines of code from Python 2 to Python 3.
Authority and responsibility: who can take the next step
19. LLVM D40988: Approval still needed someone who could commit
Material date: Review opened 2017–12–07; relevant approval and commit exchange 2019–03–15–23.
Context and approach. LLVM review D40988 proposed more detailed clang-format options and included substantive technical concerns and interrupted exchanges early in its history. A later obstacle became explicit during the March 2019 approval and submission exchange: the patch author lacked commit access. That concrete gap should not be used to reinterpret every earlier delay as the same permissions problem.
Work and result. The review was marked accepted on March 15. On March 21, jkorous explicitly said the patch had been approved and asked whether someone needed to commit it; the author confirmed having no commit access. The archive records closure by commit on March 23, and the fixed commit shows another participant submitting the change while retaining the original author’s attribution.
Interpretation. A handoff that says only “approved” may still omit who can perform the next action. This record directly distinguishes approval from the ability to execute it. It does not establish a time-zone effect, deployment, long-term correctness or passing tests. The historical policy also cannot reconstruct every participant’s permissions on every day of the discussion.
Original sources: LLVM D40988, Clang-format finer-grained options; Recorded LLVM commit c6deae452197631a4530a50df266cdf5063b601e; LLVM 8.0.0 Developer Policy.
20. Equal Experts: Move some approval authority into the working time zone
Material date: 2020–04–20 (retrospective publication).
Context and approach. Equal Experts described cooperation between a New York client and an engineering team in Portugal. When a pull request required approval across that boundary, engineers working locally could still depend on judgment elsewhere. The concrete concern was the location of approval responsibility and access to review; the client-contractor relationship should not simply be treated as a company reporting hierarchy.
Work and result. Some pull-request approvals were gradually delegated to the Portuguese team, starting with lower-risk work while complex exceptions remained with the client. The teams also reserved a review window in the New York morning and Portuguese afternoon. The retrospective records those changes, but does not supply individual PR identifiers, delegation dates or comparable before-and-after records of review effort and completion.
Interpretation. The case distinguishes decisions the currently working region can make from decisions that still require a cross-region review opportunity. It offers a concrete example of bounded delegation, without isolating its benefit from scheduling, familiarity or other changes. The source’s comments about fewer mistakes and less rework concern technical alignment and cannot be reassigned as an independent effect of local approval.
Original sources: Chris Rooney, 3 Simple Tips for Remote Engineering Teams.
21. Google data pipeline: Join operational responsibility with decision authority
Material date: 2018 (book context; full case dates unavailable).
Context and approach. In Google’s data-analysis-pipeline case, operating an existing system and developing its replacement created persistent priority conflicts. The difficulty went beyond a poorly explained individual handoff. Operational obligations and the ability to decide trade-offs between keeping the system running and advancing replacement work were not adequately joined in the arrangement described by the practitioners.
Work and result. The account describes bringing corresponding operational and decision responsibilities into the same team and reports improved trade-offs and troubleshooting. It also explicitly describes the operational burden and knowledge-transfer costs of that transition. The retained material supplies no original service records for recalculation and does not establish that the same organizational change would produce the same outcome elsewhere.
Interpretation. When a receiver inherits obligations without the authority to decide necessary priorities, a more complete status update cannot close the entire gap. This case offers a way to inspect decision responsibility within a handoff, not a general recommendation to reorganize. It did not directly test owner absence, and receiving capacity and knowledge transfer remain real costs of the arrangement.
Original sources: Site Reliability Workbook, SRE Engagement Model, Case Study 2: Data Analysis Pipeline.
22. Uber: distributing the architecture still required actual receivers
Material date: Approximately 2018–2020; migration was ongoing when reported; exact publication date unrecorded.
Context and approach. Uber’s central gateway had become a bottleneck, and sharded deployment and distributed review had not resolved the problem. Edge Gateway moved business logic toward the teams responsible for it. Migration began with important endpoints before broader adoption, so the architectural change also created a concrete ownership-transfer problem rather than merely a different deployment diagram.
Work and result. Endpoints with clear ownership could be assigned automatically, while more complicated cases required individual negotiation. Engineering, technical program management, and leadership participated, including obtaining contacts in the relevant organizations. The central team continued providing the platform, training, support, and tracking. Receiving teams took responsibility for their logic, and migration remained in progress when the account was published.
Interpretation. For an offline-owner handover, the useful analogy is connecting an assignment to a real receiver and an available support path. This is an editorial transfer, not an observed shift handover. Assignment alone does not establish spare capacity, acceptance of every consequence, or completed migration, and the source does not demonstrate that all bottlenecks or long-term costs disappeared.
Original sources: Designing Edge Gateway, Uber’s API Lifecycle Management Platform.
23. Netflix: reducing development–operations handoffs moved work onto developers
Material date: Edge Engineering history, retrospectively discussed in 2018.
Context and approach. Netflix’s Edge Engineering retrospective describes problems in separating development from operations and a gradual expansion of responsibility across the service lifecycle. Developers were expected to do more than deliver code to another group: operations and on-call work became part of their responsibilities. The account also discusses spare capacity, training, tools, and centralized support.
Work and result. Operational improvements had to compete for attention alongside product work as developers assumed more service responsibilities. Central tooling teams remained relevant; adopting full-cycle ownership did not move every specialty into each product team. The article combines organizational history with recommendations and does not provide a complete account of additional capacity or individual features postponed to support the arrangement.
Interpretation. For a substitute taking over while an owner is offline, the editorial comparison is to assess obligations, available time, and operational support together. The source does not test that specific handover situation. Broader ownership can remove some transfers while adding work to the receiver, so the model does not establish that every team should absorb every responsibility.
Original sources: Full Cycle Developers at Netflix.
24. Energy scheduling: more intermediaries still led back to one decision-maker
Material date: Project began in 2008; participant report published in 2016.
Context and approach. Rajpal described an energy-sector project begun in 2008 across Canada, the United States, and Europe. Participants raised problems in retrospectives without seeing follow-up, and those meetings eventually stopped. An overloaded product owner remained central to answering domain questions, leaving the team dependent on that person’s judgment while development work continued to generate new questions.
Work and result. Adding domain experts did not remove the bottleneck because they lacked decision authority and referred questions back to the same product owner. The author reported that a planned one-year project took more than three years and substantially exceeded its budget. This is a participant’s account of an anonymous project, without public contracts or audited cost records.
Interpretation. For an offline-owner arrangement, the editorial comparison is whether a substitute merely forwards questions or can make the judgments that permit progress. The source identifies concentrated authority and capacity, not the cause of every delay. Practices the author later used elsewhere must also remain separate; they are not evidence of a successful recovery within this project.
Original sources: Lessons Learned from a Failed Attempt at Distributed Agile; Participant report full-text route.
Capacity and burden: whose time continuation uses
25. Google cross-site SRE: Reporting did not resolve work that outlasted a shift
Material date: 2018 (book context; full event dates unavailable).
Context and approach. Google’s Zürich and Sydney SRE account describes changes in staffing, service knowledge and responsibilities. Support tickets in Zürich extended work beyond the end of on-call shifts, planned work went unfinished, and trust in the other team’s reliability declined. Team members had raised workload concerns, but the existing management arrangement had not produced the adjustments they needed.
Work and result. The response included dedicated management, cross-site support, responsibility changes, training and capacity, and repairing collaboration. The authors describe improvement after several months and most original overload problems subsiding after roughly a year. These changes occurred together. The retained account does not provide original rosters, ticket histories or individual performance records from which their separate effects could be recalculated.
Interpretation. An owner ending a shift does not establish that remaining work has reached someone with sufficient knowledge and capacity to take it on. This case motivates inspecting residual tickets, service knowledge and receiving capacity instead of merely requesting more updates. It does not identify one metric as the cause of recovery or justify conclusions about an individual engineer’s effort.
Original sources: Site Reliability Workbook, Identifying and Recovering from Overload.
26. Ericsson: visible demand did not constitute an accepted commitment
Material date: 2021 interviews and 2022 follow-up; study published in 2024.
Context and approach. Interviews at Ericsson described overloaded central microservice providers and consuming teams with separate customer and release commitments. Encouraging consumers to contribute code did not by itself resolve those competing priorities. Follow-up research recorded more visible demand status and management arrangements, including explicitly labeling requests not scheduled for implementation as candidates for the future.
Work and result. Contributing to a central service used a consuming team’s existing resources. Making a team’s own service reusable by other products could instead qualify for maintenance funding. These arrangements addressed different obligations: contribution work and the support burden of becoming a provider. They cannot be combined into a claim that the receiving team simply acquired additional capacity.
Interpretation. Applied to an offline handover, the editorial distinction is between information delivered, demand registered, work accepted, and a capability ready for use. The study did not test that handover scenario. It supports asking who pays for learning, review, and maintenance, while the limited follow-up supplies neither complete reprioritization records nor a usable date for every visible request.
Original sources: Ericsson microservice reuse and InnerSource study.
27. IBM Watson: early delivery did not establish sustainable daily handovers
Material date: US–Tokyo collaboration in 2019; participant report published at XP 2022.
Context and approach. Reflecting on US–Tokyo collaboration in 2019, Stoyanovsky described agreement to adopt development practices and adapt them as needed. Adoption still displaced feature work and affected morale. Daily cross-team calls initially occurred at 9 p.m. US Eastern time and became weekly after two weeks of fatigue, while daily handovers and reviews remained part of the collaboration.
Work and result. Necessary functionality was completed early, yet the author reported burdens from daily handovers, reviewing the other side’s output, and early-morning or late-night contact. At least his team and senior leadership considered the intensive arrangement unsustainable. Once the foundations were established, teams specialized in different features; completing the work had not settled whether the coordination pattern should continue.
Interpretation. This account includes actual cross-time-zone handover work, although it does not trace each individual owner’s absence. For the article, it supports asking whether reading, review, and overlap time are counted alongside continued progress. The participant retrospective cannot establish that everyone endorsed the arrangement, and early delivery cannot be attributed to one practice or treated as proof of sustainability.
Original sources: Architecting a Globally Distributed Software Development Organization for Continual Development; XP 2022 full experience report.
28. Tekelec–Radiante: timely answers still left scope and coordinator dependence to examine
Material date: Study published in 2006; precise event dates not retained.
Context and approach. Layman and colleagues studied US company Tekelec and Czech company Radiante as they developed a simulator. Its purpose was initially unclear and later established as training. Developers used a team-visible email list to ask questions and receive answers across time zones, creating a shared place for clarification while still depending on people to take those questions up.
Work and result. The project delivered on time with deliberately reduced functionality. The customer was highly satisfied with communication but neutral about functional completeness. Researchers also identified reliance on key coordinators as a risk, and interviews did not include ordinary developers. Timeliness and communication satisfaction therefore do not establish that every contributor could independently continue every part of the work.
Interpretation. The offline-owner comparison is to separate the delay before an answer, whether it reaches work in time, and the scope eventually committed to. This is an editorial application, not a repeated handover test. Shared written answers may help context travel while preserving reliance on particular coordinators, and the account cannot establish that email generally outperforms meetings.
Original sources: Essential communication practices for Extreme Programming in a global software development team; Author-shared full study.
Waiting and repartitioning: when to change the arrangement
29. Tyger: make a pause and its later reassessment explicit
Material date: PR discussion in 2024; the precise date of the vacation comment was not separately rechecked.
Context and approach. Review of Tyger #123 contains a concrete counterexample concerning stream blocking and flushing: input that has not yet reached EOF can expose behavior still needing attention. In a separate comment, the author explains closing the PR and returning to it after a two-week vacation if the work remains relevant.
Work and result. The public material records both a technical lead about unfinished work and a pause. It does not establish another person taking over or compare the effectiveness of waiting and transferring. The earlier research did not execute the review command, and the article neither claims an independent reproduction nor supplies an unsupported permanent outcome.
Interpretation. When an owner is unavailable, retaining the unresolved work and a condition for revisiting it can itself be an explicit arrangement. Whether waiting is acceptable still depends on present needs; the case does not establish waiting as universally preferable. Returning to the task should include checking whether it remains useful rather than automatically executing an old request. This is a record of an explicit pause, without a transfer of responsibility or a comparison of waiting with reassignment.
Original sources: Tyger #123: the explicit pause comment; Tyger #123: the blocking/flush counterexample.
30. IBM US–India projects: replace repeated code handoffs with component ownership
Material date: 2006 report.
Context and approach. A 2006 IBM Systems Journal report described three web projects distributed between the United States and India. Developers attempted to continue the same code across regions, but scheduling caused frequent reassignment and made continuity difficult. In two projects, the Indian team never obtained the necessary access to the customer’s development environment, adding a practical barrier to continuation.
Work and result. The Indian team sent updates through email, FTP, or intermediate storage, and the US team loaded them into the customer environment. Environments were often out of sync, while assumptions in specifications also led to misunderstanding and rework. All three projects eventually assigned discrete components to locations, reducing the need to repeatedly transfer the same implementation between them.
Interpretation. A recipient needs usable access and enough context to make decisions; clearer handoff notes cannot remove every dependency on another location. Repeated failures may justify changing the boundary of ownership so a location completes a more coherent unit. That alternative still requires explicit integration, clarification, and acceptance responsibilities, or waiting may simply move to a later stage. The source supplies neither a controlled time-zone experiment nor a fair performance comparison before and after the change.
Original sources: Treinen and Miller-Frost: Following the sun, Case Study 2.
31. Slack’s dual-homed team: handoff frequency follows overlap and urgency
Material date: 2023 retrospective describing work from 2019 onward.
Context and approach. In a 2023 retrospective, Javier Turegano described helping lead Slack Cloud Engineering from 2019 onward. Australia and the United States had changing amounts of overlap, while the team handled planned development, major incidents, and urgent investigations. Those conditions did not lead the team to use one fixed cross-region arrangement for every kind of work.
Work and result. With fewer overlapping hours, some work moved into groups within the same time zone. With more overlap, groups mixed across regions again to encourage knowledge sharing. Major incidents and urgent investigations used daily handoffs, and unplanned work received explicit capacity rather than being added to everyone’s existing commitments. The retrospective did not provide comparative outcomes or per-item acceptance times.
Interpretation. Maintaining the ability to continue across locations and deciding how frequently to use it are separate choices. A team can change the arrangement as overlap, urgency, and capacity change. This case is useful for discussing when to activate or reduce intensive handoffs, but it does not establish a universal Slack policy, optimal overlap, or a measured speed benefit.
Original sources: Javier Turegano: Running dual-homed teams across the world.
32. Cloudflare Phoenix: automatic recovery has a limit on the next shift’s burden
Material date: 2024 company account.
Context and approach. Cloudflare introduced Phoenix in 2024 to automate parts of faulty-server diagnosis, reprovisioning, and recovery. A recovered server could fail again and generate work for a later shift. The system therefore had to consider the operational burden of repeated recovery attempts, alongside whether it could bring a particular machine back into service.
Work and result. Phoenix managed its error budget in periods aligned with three SRE shifts and stopped automatic recoveries when the allowance was exceeded. Physical component replacement remained a human responsibility. The company described an implemented mechanism, but did not separately estimate the benefit attributable to time zones or claim that automation had removed all on-call work.
Interpretation. Continuation during an owner’s absence can involve automation as well as another engineer. It still needs stopping conditions and an owner for exceptions, especially when apparently successful actions create later work. Evaluate the manual effort avoided alongside maintenance and subsequent failures. Counting recoveries alone could conceal the burden passed to another shift or returned to a specialist. The account neither isolates a time-zone effect nor establishes that human responsibility disappeared.
Original sources: Cloudflare: Autonomous hardware diagnostics and recovery at scale.
33. Yahoo Search: Transfer release knowledge along with release responsibility
Material date: Agile 2016 experience report; changes from 2013 onward.
Context and approach. Yahoo Search’s international collaboration involved the United States, Taiwan, India and Jordan, with the arrangement changing as the organization evolved. Release rotations and automation already existed, but knowledge remained concentrated in the United States. When automated tests written by the US team failed during another region’s working hours, local engineers could still have to stop and wait.
Work and result. The team combined knowledge overviews, deeper explanations, time to absorb material, named contacts and question sessions with a phased transfer of release responsibility. Local standups worked alongside shared records instead of requiring everyone worldwide to attend simultaneously. The experience report describes continuing support for receivers, while also recording concurrent changes in staffing, organization and automation.
Interpretation. This case directly addresses work stopping across time zones: a rota allocated responsibility before the receiving engineers necessarily possessed the knowledge to handle failures. It supports treating takeover as a learning process. It cannot attribute changes in release coverage solely to meetings or documentation, and the engineering coverage hours in the report’s title are not individual working hours.
Original sources: Yukari Hasebe and Mai Le, 6 days/week with 20hr of engineering/day and multiple releases in one day — Yahoo Search.
Source scope. Thirty-three cases do not mean thirty-three proven successful offline transfers: some directly record continuation, while others offer comparisons from support, acceptance, responsibility, or operations. Companion accounts of the same event count as one case. Dates distinguish events, retrospectives, and publication where known and do not establish current practice. The accounts rely on historical materials that have not all been rechecked; they do not include new interviews, executed code tests, or a measured effect of a handover intervention.
