Decision Latency: Handle This Wait, Change the Next One
A public Miri review left a record of an easily overlooked kind of wait. At the reviewer’s request, the author wrote a test that read from a zero-length memory allocation after it had been freed, but she did not see the expected error. She brought the code and her observations back to the discussion. The reviewer later confirmed that accessing zero-sized types would not trigger the error originally expected, withdrew that request, and switched to checking for memory leaks and double frees. The change was later merged. Review record
What needed to change at that point was the validation requirement. Adding the same test again or asking for a reply again would not necessarily move the work forward. This record does not measure a speed improvement or show that time zones caused the problem. It offers a starting point for examining what a wait involves. For a distributed team, the next question is whether the necessary judgment can be obtained during everyone’s normal working hours.
An engineering manager has two jobs to handle together: help the current work reach a decision sufficient to plan its next step, and examine whether the next batch of similar work still needs to go through the same wait. Getting an answer this time and making it easier to reach a reliable answer next time are different outcomes.
First, establish what needs to be decided this time
When work is marked blocked, return to the question that remains unanswered: what evidence is missing, which requirement is disputed, or which consequence has no one yet decided whether to accept?
Try stating the need this way: “For [person] to take [next step], what needs to be confirmed now?” Then check whether people, authority, or conditions for execution would still be missing even with an answer. Resolving one question does not necessarily mean the whole piece of work can proceed.
The Miri author’s failure to obtain the expected result does not, by itself, establish a lack of capability. Bringing the requirement and the actual observations back to the discussion lets the reviewer reexamine whether the requirement holds. Conversely, one withdrawn requirement does not establish that the other tests are unnecessary. The task is to address the specific contradiction.
In everyday team work, first establish with the requester what result is needed by when, what burden waiting creates, and whether any arrangement other than the original proposal would be acceptable. Those conditions affect which additional evidence is worth gathering next, or whether the delivery commitment should change. An urgent deadline does not supply a technical answer or automatically grant authority to accept risks on someone else’s behalf.
If the available information already establishes the impact and the remaining question is how two services should divide shared capacity, more of the same tests may not help. Someone with the relevant authority needs to address the trade-off. If there is not even agreement on who can decide, first ask someone who can adjust the relevant responsibilities to resolve that boundary. “Escalated” still does not mean a decision has been obtained. Information, the ability to make the judgment, time, and authority may all be missing at once. Start with the gap that would change the next step; there is no need to assign one sole cause to the entire PR.
Give the necessary people an opportunity to make the decision
An Equal Experts retrospective describes two arrangements between a New York client and an engineering team in Portugal: gradually moving approval of low-risk PRs to the Portuguese team while retaining client approval for complex matters, and setting a joint review window in the New York morning and Portuguese afternoon.
Delegation changes which decisions must cross regions; scheduling creates an opportunity to review the work that still must. They serve different purposes. This is a project account, without comparisons of individual cases that isolate the effect of each change. A regular review window does not add reviewers, either.
An OpenTelemetry Collector discussion shows another situation. One participant recalled that a session intended to accommodate another time zone gradually became a repetition of decisions from the original session and was later canceled. Another session still depended on maintainers to relay questions back to the usual session. The main weekly meeting subsequently began rotating among three time slots, and the rotation was retained after a trial. This establishes that the arrangement was adopted, but is not enough to show that people in every time zone gained more influence over decisions.
After scheduling a meeting or appointing a representative, therefore, check whether the necessary expertise can participate, whether affected people can raise constraints before a decision is final, and which decisions can actually be made in that session. If someone else with authority still needs to act, make clear who will decide next, when, and on what basis. The number of handoffs cannot stand in for progress.
Prepare known inputs early so that the next round of work can address the real question. Review may still uncover new concerns. Record the new validation needed and the follow-up arrangements; do not require authors to anticipate every defect. If the necessary person has no time available at all, prioritize this need alongside their existing work rather than assuming someone in another time zone will make up the difference after hours.
Narrow this decision enough to act
Some work does not need every long-term question settled at once.
When Python proposed changing the default behavior of type annotations, the downstream project Pydantic raised concrete difficulties with resolving them at runtime. The 2021 decision kept the existing default for Python 3.10 while continuing to allow developers to opt in to PEP 563; discussion of the long-term design continued. That decision addressed what the current release would take on. It did not declare every type-annotation problem solved. The decision at the time | PEP 563
Leaving a hard problem for the future is not, by itself, a success. After narrowing the scope, make clear what is being chosen now, which limitations remain, and who will carry the remaining questions forward. A decision to defer also needs a record of who will return with what information, or when and under what conditions the question will be reconsidered. Merely changing a date may not amount to a new decision. If the options would shift costs onto other teams, someone with the relevant authority still needs to address the trade-off.
The engineering approach itself can also change. GitLab’s database decomposition retrospective records that the original approach, which aimed for near-zero downtime, was difficult to roll back reliably and difficult to assess for success. There was also no hard business requirement to avoid downtime. The team switched to a cutover and rollback approach that could be rehearsed repeatedly, then submitted the validation for approval by those with authority. Changing the feasible approach and its supporting evidence gave the trade-off concrete substance.
The original plan may also need to stop. Slack’s LibSlack retrospective records technical progress on a shared C++ client library, but changes in the desktop strategy, the cost of replacing the mobile implementation, and the expected adopters ultimately led to the project being stopped. What needed reconsideration was the basis for continued investment, not only how to get the next step approved sooner.
Until a decision has been obtained, the work remains unresolved. The delivery commitment can change, the next necessary check can be arranged, or someone with authority can be asked to decide whether to stop. A lack of response cannot create approval, and every postponed meeting cannot be recorded as a resolution.
Carry the original judgment function into the next arrangement
When a class of work repeatedly needs approval across regions, examine which parts might be handled locally. Start with existing records: what did remote involvement actually add, and can the local team obtain the same necessary information, make the judgment, and take responsibility for the consequences within its authority?
Spotify’s changes across repositories offer a concrete comparison. Some merge decisions moved from repository owners to change authors, accompanied by tests, staged rollouts, limits on rates and working hours, notifications, and an opt-out mechanism. This arrangement includes a redistribution of authority; it cannot be understood only as using a tool to press merge. It shows which conditions for execution accompanied the transfer of merge decisions. Whether it reduces waiting across time zones still needs separate observation.
The people taking on the work still need actual time to do it. They also need to be able to recognize the scope in which the arrangement applies: changes to shared resources or several changes happening at once may invalidate an earlier judgment. If every check of whether local approval is allowed first requires a remote answer, the original dependency remains.
If delegation is being considered and existing records still leave a capability gap unclear, a short comparison of local and remote judgments can help identify what support the local team needs. Agree on the question, effort, and stopping point first. Examine differences against the evidence rather than treating the remote answer as the answer key.
This comparison should neither block work allowed by the existing process nor become permanent double sign-off. Completing it does not grant authority.
An existing step may provide an independent check. Removing it requires explaining who or what arrangement will carry that function forward. If the control or acceptance standard changes, acknowledge that the comparison conditions have changed too. When similar work is rare or consistently requires trade-offs across services, retaining necessary review and making it more accessible may also be a reasonable choice.
Return to the original wait and examine what changed
Before a trial, specify which wait it is meant to change: making necessary review happen during normal working hours, allowing a class of work to proceed without approval across regions every time, or providing a way to address a concrete disagreement. Different goals cannot all be evaluated through average merge time alone.
Begin observing when the need for judgment or authorization is first raised. Retain the time spent gathering information, validating, and going back and forth rather than using a retrospectively chosen point of “information complete” as the only start of the clock. Then examine when a decision forms and whether the conditions needed to act on it are in place. Record approval, merge, and deployment separately.
Retain the comparable work selected in advance, including work that proceeds, changes direction, is deferred, is rejected, or remains unfinished. An automatic closure cannot be treated as a resolved problem, and work with disappointing results cannot be excluded after the fact. Once simpler cases are handled locally, the work remaining remotely may be more complex. The two averages cannot directly establish a net benefit.
Check with the people taking on the work about displaced commitments and maintenance burden. Missing a constraint that should already have been understood differs from reopening a decision because new evidence appears later. A short period without incidents does not establish equivalent control. Any improvement that depends on people in another time zone staying up late must also account for that cost.
If the target wait remains while repeated communication increases, there is reason to narrow or reverse the trial. If decisions form earlier but deployment still depends on another window, a partial benefit can be reported. Stopping an ineffective arrangement is the next choice; it cannot rewrite the original goal as achieved.
Returning to Miri, bringing a concrete contradiction back to review led to a change in the original requirement. For a team, handling the current wait may mean gathering evidence, correcting a requirement, making a limited decision, or adjusting the approach. Changing the next arrangement requires the necessary information, expertise, and authority to come together at the right time.
What needs to improve is the set of conditions for reaching reliable decisions. Giving the current work a next step and removing an unnecessary wait from the next batch of work are both worth tracking. Neither can substitute for the other.
Appendix: Cases and Further Reading
This appendix groups 32 cases by the question they help examine. Company retrospectives, public review records, and field studies have different evidentiary limits. Multiple sources about the same event count as one case. Policy templates and aggregate research findings appear separately and do not count toward the case total.
These historical materials have not all been rechecked. Their event, publication, and access dates remain distinct. The cases compare choices and limitations; they cannot be combined into a validated method for speeding decisions.
Question to explore Cases Is the wait caused by missing evidence, or does the requirement itself need correction? Judgment and acceptance criteria: what needs an answer next? (01–06) Does having a reviewer or a meeting mean the work can get the judgment it needs? Review availability and participation: when can the necessary people take part? (07–11) Does the work need expert input, or someone authorized to accept a trade-off? Authority and trade-offs: who can turn disagreement into an actionable decision? (12–17) What else is needed after approval, support, or command responsibility changes hands? Delegation and execution: can the work continue once responsibility is accepted? (18–24) Is less waiting necessarily the best outcome for this work? Continue, change course, or stop: what is worth doing after a decision? (25–32) Policy and research excluded from the case count Supplementary material Scope and limits of the original sources Source catalogue
Judgment and acceptance criteria: what needs an answer next?
1. Slack: implementation and review still left the data-provider approach to be worked out together
Material dates: September 20, 2022 (source publication); material type: A first-person implementation retrospective by an engineer.
Situation and approach. Stephen Dolan was reworking the Mentions tab to combine activity data from an API with WebSocket updates. Following his manager’s advice, he first mapped the data flow from network requests to the screen and completed part of the implementation. Review still found problems with the approach; simply continuing to wait for approval could not address the immediate obstacle.
Work and outcome. The author brought two senior engineers into a live discussion to work out again how the data-provider component should combine the two sources. What can be observed is a revised understanding of the implementation approach. The retrospective does not describe the entire feature as having been completed during the call.
How to read this case. What is missing during a decision wait may be a shared understanding sufficient to choose the next step, rather than a faster reply. Experts examining the assumptions together can first determine what needs to be validated; that is separate from obtaining formal approval.
Evidence limits. Preparation, expert involvement, and live discussion were all present, so their effects cannot be isolated. There is no complete call record, code inspection, or comparison of elapsed time, and this is not a study of effectiveness across time zones.
Original material: Source 1.
2. Neovim: a beginner task stalled on unreasonable acceptance criteria
Material dates: 2014–2017; material type: Public issue and pull request records.
Situation and approach. Neovim issue #1474 concerned removing duplicate implementations of string functions. In 2014, GlenDC, taking on a beginner issue for the first time, asked what the actual goal was. Although the discussion provided testing, performance measurement, and ways to seek help, the acceptance criteria still needed clarification.
Work and outcome. In 2017, maintainers revisited which parts of the work could be separated, and aktau acknowledged that the earlier performance expectations had been inappropriate. The earlier change, #1489, was closed without being merged; a later change, #6460, submitted by a different contributor, was merged.
How to read this case. This example locates the obstacle in the review threshold: more answers or more diligent implementation may not remedy requirements that have not been reasonably defined. Someone with decision authority needs to revise the acceptance criteria.
Evidence limits. The records involve different contributors and cannot be combined into one person’s development story. They also do not establish that performance requirements caused all of the delay. There is no comparison of waiting time before and after the adjustment.
Original material: Source 1; Source 2; Source 3.
3. Miri: a reviewer withdrew a test requirement based on a mistaken premise
Material dates: May 7–8, 2024; material type: Public review discussions and a merge record.
Situation and approach. While working on zero-length memory allocations in Miri, Tiffany wrote a read-after-free test at a reviewer’s request but did not see the expected error. She brought the code and her actual observations back to the discussion, without treating the failure to reproduce the error as completed validation.
Work and outcome. The discussion first clarified syntax and types. Ralf Jung then pointed out that accesses to zero-sized types would not trigger the expected error, withdrew that requirement, and redirected the checks toward memory leaks and double frees. The archived record confirms that the change was merged on May 8.
How to read this case. Work waiting for review can also be blocked by a reviewer’s mistaken premise. Bringing contradictory evidence back to the person making the judgment and correcting the validation target can allow review to proceed; simply asking the author to add tests faster is not enough.
Evidence limits. The original research did not rerun the tests, and access to the file endpoint was also restricted at one point. The withdrawal of the requirement and the merge can be confirmed, but the exchange does not establish a measured speedup or demonstrate subsequent technical independence.
Original material: Source 1; Source 2; Source 3.
4. QtBase #12807: a review without agreement needed a decision on scope
Material dates: Not specified in the retained material; material type: A specific change cited in a code review study.
Situation and approach. The study’s account of QtBase change #12807 describes one reviewer agreeing to integration while another requested a broader scope. The two views implied different work requirements; this was more than a reply that had not yet arrived.
Work and outcome. The change was abandoned after agreement was not reached. The available material supports only the disagreement over scope and the abandonment of this change. It provides no independent evidence of which reviewer was right or of the author’s motives.
How to read this case. This makes the goal of speeding up review more specific. If the obstacle is a decision on scope, urging the author to revise again or tracking response time alone may not address the actual dispute. It is necessary to identify who has the authority to bring the requirements into agreement.
Evidence limits. The complete original Gerrit discussion was not obtained, so defects may have coexisted with the disagreement over scope. One person’s approval does not establish that a change can be integrated, and abandoning a change does not mean leaving a job or a community.
Original material: Source 1; Source 2.
5. AWS cloud provider: continuing a change during the original author’s leave, with understanding, validation, and approval completed in stages
Material dates: October 21–24, 2024; material type: A public pull request and comment events.
Situation and approach. The original change aimed to add AWS network topology to node labels. The person who continued the work had already noted on the earlier request that some users outside EKS might lack API permissions. When the original author went on leave, this contributor opened a new request to continue the work. This was therefore not a handoff to an unfamiliar person relying on a document alone.
Work and outcome. The new request still needed answers about error logging, missing topology results, and how the labels would be used. The contributor revised the change and preserved some reasoning from outside the discussion thread. A reviewer first indicated that the change looked good while waiting for continuous integration, then issued a separate approval. The platform records a merge on October 24.
How to read this case. Someone familiar with the context can continue the work without all the prerequisites for proceeding and all approvals having transferred with it. The case distinguishes waits for information to be clarified, implementation, validation, required approval, and merge.
Evidence limits. The complete integration test logs and communications outside the thread were not obtained. A same-day merge does not mean the entire feature took one day, cannot be converted into time saved by the handoff, and does not establish that the change was deployed.
Original material: Source 1; Source 2; Source 3.
6. VS Code: an investigation handoff produced more evidence, but not enough to stop tracking the problem
Material dates: September 28–October 6, 2022; material type: A public issue-tracking event.
Situation and approach. After an integration test failed, the person initially handling it was unsure whether the build process was involved and asked a colleague to assess it. The colleague suggested that a crash during the test might be involved and pointed out where to find the dump data. That afternoon, the investigation was explicitly handed to the person responsible for the build that week.
Work and outcome. The next day, the person who took over left a symbolicated stack trace, upstream leads, and a possible explanation, but noted that the evidence was insufficient and kept the issue open for tracking. A link to another run was added later. On October 6, a bot automatically closed the issue for insufficient information and lack of recent activity.
How to read this case. This is a counterexample in which someone continued the work but still could not decide how to fix the problem. Recording what remains unresolved can itself tell later investigators what is missing. Evaluating only closure speed would mistake an automatic closure for resolution of the technical problem.
Evidence limits. The dump and the contents of the later run were not obtained, and the root cause was not reproduced. The record does not establish that the original author was offline, that this was a handoff across time zones, that responsibility was fully transferred, or that a fix existed.
Original material: Source 1; Source 2; Source 3; Source 4.
Review availability and participation: when can the necessary people take part?
7. Equal Experts: delegating low-risk reviews while retaining time for joint judgment
Material dates: Published in 2020; the start and end dates of the events are unknown; material type: A retrospective on the practices of an international team.
Situation and approach. A New York client worked with an engineering team in Portugal, and some code changes had to wait for the client’s approval. Knowledge and approval authority were distributed across time zones, so the necessary judgment could not always be obtained during the author’s working hours.
Work and outcome. The arrangements gradually shifted so that the Portugal team could approve low-risk changes while complex matters still required client approval. A joint review window was also set up in the New York morning and Portugal afternoon. The retrospective assessed these arrangements positively.
How to read this case. This directly distinguishes two kinds of waiting: approval across time zones that can be removed through delegation, and joint judgment that still requires expertise from both sides. Delegation works alongside available review time; the change is more than an increase in reply frequency.
Evidence limits. There are no individual PR records, precise event dates, or isolated effects for each measure. The material cannot quantify labor hours saved, establish an optimal frequency, or show that review and learning costs disappeared.
Original material: Source 1.
8. Google Zürich/Sydney SRE: reported problems still required changes to responsibilities, authority, and capacity
Material dates: Not specified in the retained material; material type: A retrospective on recovery from SRE overload within a company.
Situation and approach. After a team spanning two sites lost staff and service knowledge, members still had to follow up on their existing cases after their on-call duty ended, continually displacing project work. Members had raised the problem with a manager who was responsible for multiple teams and did not take part in the on-call rotation. The arrangements did not change, and the backlog and collaboration problems worsened.
Work and outcome. The team later began looking at the elapsed time from the end of an on-call rotation until cases were resolved, and changed arrangements for dedicated management, support between sites, alerting, and service responsibility. The author’s retrospective reports that the original overload had substantially subsided after about a year.
How to read this case. Writing down or escalating a problem does not mean that a usable decision has been obtained. If continuing responsibilities still consume capacity, staffing and tradeoffs need to change, rather than requiring the people doing the work to keep updating its status.
Evidence limits. Several arrangements changed together, so the effect of any one measure cannot be isolated. The elapsed time from the end of an on-call rotation until a case is resolved is not an individual’s labor time and does not establish whether work took place after hours. This is a case about a team spanning multiple sites, not an experiment in improving individual capability or working from home.
Original material: Source 1.
9. Geosoft: an intermediary protecting local developers can also obstruct remote requests for help
Material dates: Published in 2020; the episode’s start and end dates were not provided; material type: A specific collaboration episode from a study of six teams working across sites.
Situation and approach. In a Norway–China collaboration under the pseudonym Geosoft, some remote testers could reach developers only through a coordinator. The arrangement was intended to protect local developers from interruptions, but those seeking help reported that it made their work more difficult.
Work and outcome. The study also recorded how busy managers and limited overlap in working hours made necessary conversations difficult to arrange. This episode provides an observation of restricted access to support; it does not report a later outcome in which the same testers had those restrictions lifted.
How to read this case. A single point of contact can consolidate messages, but it can also add another queue before someone can obtain a judgment. When examining whether interruptions have decreased, it is also necessary to examine whether requesters can reach the expertise they need at a workable time.
Evidence limits. Accounts in the same study of UX members getting answers on Slack, or of increased participation later on, concern other episodes and cannot be combined into a timeline of improvement for this event. Nor can the effects of time differences and organizational factors be attributed separately.
Original material: Source 1.
10. OpenTelemetry: a more accessible meeting time still deferred decisions to the original session
Material dates: 2023–2025; the rotation was formally retained on January 15, 2025; material type: Public proposals, a participant’s retrospective, and merge records.
Situation and approach. After OpenTelemetry Collector added sessions at times more accessible to Asia-Pacific participants, one participant reflected in 2024 that one session had gradually become a repetition of decisions made in the original session and was later canceled. This was the participant’s explanation of the reason. Another session that remained in operation had few participants and often needed maintainers to relay messages, deferring decisions to the usual session.
Work and outcome. A change merged in July introduced a rotation among three UTC time slots for the main weekly meeting, initially as a trial of about six months. Live interactions also had to be publicly announced with an invitation to participate, and decisions had to be recorded back on GitHub. On January 15, 2025, the trial end date was removed and the rotation was formally retained.
How to read this case. Being able to attend, being able to raise constraints, and being able to address an issue are different conditions. If a new session only adds message relaying, it may preserve the existing wait for decisions. A trial can be used to examine whether discussions involving the necessary roles actually take place.
Evidence limits. The merges establish that the arrangement was adopted; they do not yet establish that participants in disadvantaged time zones gained greater influence over decisions. Nor did the arrangement automatically provide a window for absent participants to reopen discussion. The experiences of the two monthly meetings must not be treated as those of a single meeting.
Original material: Source 1; Source 2; Source 3; Source 4; Source 5.
11. Ericsson: an architecture meeting occupied experts whom other people needed
Material dates: Data from 2023–2024; published in 2025; material type: An interview study at an actual company; an event in the first unit studied.
Situation and approach. In a study of Ericsson’s Finnish sites, developers in the first unit complained that although the architects came to the office, they spent two consecutive hours in an architecture community meeting. Other people who had also come to the office hoping to talk directly with them could not get help.
Work and outcome. The meeting later alternated weekly between in-person and remote formats, responding to the problem of experts being unavailable when people were together in the office. This is a different event from the conflict involving an Asian daily meeting in the study’s second unit; this entry includes only the change concerning architects’ availability.
How to read this case. A wait for judgment can also be caused by other useful work. A meeting serves its participants while occupying experts needed by people outside the invitation list. The scheduling of scarce expertise needs examination, beyond simply counting participants’ meeting hours.
Evidence limits. The study interviewed only members in Finland and did not measure delivery or waiting time after the change. The complaint and the response can be confirmed, but the material does not establish that alternating formats improved access for everyone.
Original material: Source 1.
Authority and trade-offs: who can turn disagreement into an actionable decision?
12. Squarespace: separating in-depth approval from broader discussion
Material dates: Published on September 11, 2019; material type: A firsthand retrospective on company practices.
Situation and approach. Squarespace had used a one-hour Infrastructure Council meeting every two weeks to discuss three RFCs, but it was difficult to examine them in depth, and the weight of objections was unclear. The large public forum encouraged authors to wait until their designs were well developed before presenting them, by which point major changes were harder to accept.
Work and outcome. The team added Architecture Review sessions twice a week, giving each major design an hour of detailed attention, while the Council became a forum for sharing. Because the smaller reviews felt closed and lacked sufficient expertise, relevant users and domain experts were subsequently invited, and approval records were linked back to the public RFCs.
How to read this case. Reducing the wait for judgment requires more than narrowing the circle of participants. It is necessary to distinguish who approves, who contributes essential constraints, and who might be left out. Broad exposure and in-depth review can serve different purposes.
Evidence limits. Documentation, review, and approval procedures changed together, without their effects being separated. Faster decisions across time zones were not validated. The Council continued to serve purposes related to knowledge and relationships and cannot simply be treated as a redundant approval layer.
Original material: Source 1.
13. An international energy project: adding representatives still left decision authority missing
Material dates: Project began in 2008; published on May 15, 2016; material type: A project participant’s firsthand retrospective on a failure.
Situation and approach. An energy project involved suppliers in Canada, the United States, and Europe. When the product owner went to one location to collaborate, other locations still waited. Even bringing people together for planning did not remove the excess demand. The problem therefore went beyond time zones and an inability to meet in person.
Work and outcome. Domain experts were added after about a year but were not given enough decision authority, creating an additional layer of relaying and waiting. Retrospectives discussed the problems but lacked follow-through and were canceled after the schedule slipped. Management also canceled reviews after problems arose during demonstrations.
How to read this case. This directly challenges the idea that adding representatives or meetings will shorten a wait. The necessary knowledge, authority, and capacity must all be present, along with a mechanism that turns recognized obstacles into action.
Evidence limits. Multiple factors contributed to the original project’s failure. Cost overruns or delays cannot all be attributed to meetings or representative roles. Improvements that the author later adopted on other projects are not evidence that the original project recovered successfully.
Original material: Source 1.
14. Python/Pydantic: deferring a default change for the current release while keeping the long-term design question open
Material dates: April 2021; subsequent clarification of interpretations in 2022; material type: Public discussions of downstream compatibility, a decision letter, and a merge event.
Situation and approach. Python was planning to change the default behavior of type annotations, while the downstream project Pydantic needed to resolve annotations at runtime. Maintainers narrowed general concerns to a concrete example: after enabling string annotations and moving the type import and model inside a function, resolving the type required additional access to names.
Work and outcome. The April 2021 decision retained the existing default in Python 3.10, while still allowing users to opt into PEP 563, and the revert was merged. Later discussions continued to correct some technical interpretations. PEP 563 ultimately did not become the default and was later superseded by other designs.
How to read this case. A decision can first be made not to take on a particular compatibility risk in the current release, with the long-term approach completed separately. This challenges the idea that failing to settle everything at once means stagnation: narrowing the decision can change the current release without pretending that every question has been answered.
Evidence limits. The concrete example does not represent all downstream costs. Correcting one interpretation later does not mean other costs disappeared, and the deferral itself does not establish the merits of the long-term designs.
Original material: Source 1; Source 2; Source 3; Source 4.
15. Rust await: choosing within a deadline and explicit tradeoffs, without requiring everyone to change their first choice
Material dates: May 23, 2019; released on November 7, 2019; material type: A public syntax decision and an official release event.
Situation and approach. The Rust team compared prefix, postfix, and dot forms of await, facing different costs involving the ease of chaining operations, visual grouping, semicolon error messages, and confusion with field access. The May explanation first made the tradeoffs and the intended decision date public, without portraying everyone’s preferences as the same.
Work and outcome. The postfix dot form was selected on May 23, while the explanation retained members’ differing first choices. It became stable with Rust 1.39.0 in November. Requirements such as type-system soundness remained prerequisites, and extending the approach to other keywords would require a separate proposal process.
How to read this case. Discussion can end with a decision based on explicit tradeoffs and authority, without waiting for everyone to change their first choice. At the same time, the current approval, non-negotiable prerequisites, and possible future extensions should remain distinct, so that closing the discussion does not become unlimited authorization.
Evidence limits. The readability benefits were design judgments at the time, not measured universal improvements. Version 1.37 was an early target and must not be treated as the actual release. One author’s later adjustment to the syntax also cannot answer for everyone.
Original material: Source 1; Source 2; Source 3; Source 4.
16. GitLab telemetry: a published plan still lacked participation in the strategy
Material dates: October 2019; follow-up records extend at least through May 2020; material type: An official withdrawal explanation and subsequent work records.
Situation and approach. GitLab received feedback after announcing plans to track usage behavior. The CEO later noted that users, contributors, and customers had not been sufficiently involved in the strategic discussion. Having seen the plan did not mean that its purpose, tracking scope, or use of data remained open to their influence.
Work and outcome. The company withdrew the plan before it took effect, subsequently arranged a retrospective and interviews, and narrowed the scope to GitLab.com. The support team organized the questions around purpose, target groups, where the data would go, and customer participation. As of a May 2020 update, the related policy and proposals were still being developed.
How to read this case. If necessary stakeholders join only at the implementation stage, pressing for faster responses cannot make up for a strategy that was not discussed earlier. The case may call for reopening the scope of the decision, rather than merely setting a shorter approval deadline for the existing plan.
Evidence limits. This is an event concerning participation in an external-facing policy and cannot serve as evidence of pressure on internal employees. Withdrawal and redrafting do not mean that the subsequent plan was released, nor do they establish that every item of feedback was adopted.
Original material: Source 1; Source 2; Source 3.
17. Google data analysis pipeline: Bringing decisions and operational responsibility for competing work together
Material dates: Not specified in the retained material; material type: Company retrospective on an SRE collaboration arrangement.
Situation and approach. Operating the old data analysis pipeline and developing its replacement had long competed for priority. Both sides had necessary work. Tracking progress on the new development alone could not remove the need for someone to handle operational incidents.
Work and outcome. The relevant decisions and operational responsibilities were later brought into the same team. The source describes improvements in making tradeoffs and troubleshooting, while also recording the burden of taking over operations, transferring knowledge, and supporting the new arrangement.
How to read this case. The blockage may be a lack of corresponding responsibility and authority among those who need to make tradeoffs, rather than insufficient evidence for a decision. Moving where decisions are made may allow old and new work to be compared as part of the same set of actionable options.
Evidence limits. Reorganizing responsibility has costs. The source does not establish an isolated causal effect or an improvement in individual performance. It does not justify reorganizing whenever a delay occurs, or treating knowledge transfer and capacity as cost-free prerequisites.
Original material: Source 1.
Delegation and execution: can the work continue once responsibility is accepted?
18. Salesforce: Beyond assigning people, give the receiving team a workable way to take on the work
Material dates: Beginning in late 2018; material type: Company engineering retrospective.
Situation and approach. Other teams wanted to add features to the main mobile app. Assigning the work to the main app team created a prioritization bottleneck. Sending engineers from the other teams left questions about learning the main codebase, reviewing quality, and maintaining the changes after those engineers returned to their own teams.
Work and outcome. The teams jointly defined plugin modules and interfaces, and the first adopter completed integration several months later. Feature teams maintained their own modules, while the main app team retained shared capabilities and support. The mobile modules still had to be built and deployed together.
How to read this case. This case distinguishes a shortage of people from the absence of a workable way to collaborate. Even after implementation responsibility moves, the decisions required for review, integration, and maintenance may remain with the original team.
Evidence limits. The material does not provide a complete record of failed temporary assignments, the hours spent by both sides, or total long-term costs. It cannot support claims of independent releases, the removal of all bottlenecks, or faster delivery.
Get Alex Chang’s stories in your inbox
Join Medium for free to get updates from this writer.
Original material: Source 1.
19. Ericsson: Shared priorities need capacity and maintenance funding
Material dates: Interviews in 2021; follow-up in 2022; material type: Interviews at one company with limited follow-up.
Situation and approach. A central team supplying microservices was heavily loaded, and encouraging consuming teams to contribute had not resolved the bottleneck. Those teams had their own customers and release targets. Work that benefited shared company capabilities did not automatically come with capacity they could reassign.
Work and outcome. The follow-up records that senior leaders set contribution targets for central services, using existing resources. Teams that made their own services available for reuse could, subject to eligibility conditions, receive funding for subsequent maintenance. Unscheduled requests were explicitly identified as candidates for the future.
How to read this case. Resolving the wait may require a resource decision from someone who can change existing commitments. Making a one-time change, supporting incoming contributions, and providing an ongoing service require different commitments. Calling work important or putting a request on a list does not establish when it will be available.
Evidence limits. The material does not identify the work deferred by each team or establish causal effects. The limited follow-up cannot prove that the bottleneck disappeared. Contribution targets and maintenance funding do not represent the same allocation of additional capacity.
Original material: Source 1.
20. Spotify: Automatic merging also changes who can approve
Material dates: Retrospective published in 2023; material type: Company retrospective on an engineering mechanism.
Situation and approach. Some automated changes across repositories initially required each team to opt in. Later, these changes could be merged once specified conditions were met. The source explicitly states that some merge decisions moved from repository owners to change authors.
Work and outcome. The arrangement included tests, staged rollouts, limits on rate and on merging outside the owning teams’ working hours, monitoring and notifications after merging, and an opt-out mechanism. Important systems remained subject to additional conditions.
How to read this case. This case helps examine whether process automation is also redistributing decision authority. Removing the wait for individual approvals requires clear conditions of use, responsibility for the consequences, and a way to stop the process, as well as automated execution.
Evidence limits. Not every pull request was merged automatically, and owners did not lose all responsibility. A notification does not mean someone has acted on it. The scale of adoption cannot establish improvements in waiting time, incidents, or total cost.
Original material: Source 1.
21. GitLab: Assigning responsibility for finding a replacement when the next shift cannot be reached
Material dates: June 2024; material type: Incident account and an adopted process change.
Situation and approach. During an on-call handoff at GitLab, the outgoing shift was about to end, but the incoming engineer did not respond. The team was unsure how to find a replacement. The missing element was a commitment to receive the work, rather than a field in the handoff document.
Work and outcome. The corresponding process change added steps such as making a phone call, looking for other available engineers, and asking the on-call manager for help. Existing rules also required confirmation that someone had accepted ongoing Development Escalation work, or that someone able to coordinate had committed to arranging a replacement.
How to read this case. The case separates sending a handoff from having a next person responsible, and makes clear whom to contact after the response deadline. A replacement path can handle the immediate wait, while clearer process responsibilities address repeated waits of the same kind.
Evidence limits. The archived research distinguishes the initial merge into an intermediate branch from later integration into the main branch. It provides no comparison of incident performance before and after the change. This event is separate from the 2025 change to domain expert coverage and cannot be combined with it into a single causal sequence.
Original material: Source 1; Source 2.
22. GitLab: Routing general development escalations to domain experts
Material dates: Proposed December 10, 2025; merged December 31, 2025; material type: Rationale for a process change and on-call documentation.
Situation and approach. GitLab’s Development Escalation originally served the Rails monolith, but its support scope later expanded. The process change noted that a general on-call engineer might not know the particular domain involved. Someone could be online without being able to continue the diagnosis.
Work and outcome. The change merged at the end of 2025 routed these escalations to Tier 2 domain experts. It changed how the required expertise was obtained. This and the previous year’s addition of steps for an unreachable incoming engineer addressed two different problems within the same support system.
How to read this case. A wait may persist even after a reply because the person replying lacks the necessary expertise. The case distinguishes finding someone available from finding someone able to make the required judgment, without equating on-call coverage with the ability to handle the problem.
Evidence limits. There is no performance comparison before and after the change. The documents give inconsistent effective years, and those inconsistencies cannot be corrected by assumption. The archived Tier 2 documentation still contains gaps and best-effort support limits, so it cannot serve as a complete current on-call roster.
Original material: Source 1; Source 2.
23. Google GKE: Handing over command while retaining technical context
Material dates: Not specified in the retained material; material type: Company incident case study, the second case in the source.
Situation and approach. A Google incident case study describes a failure to create GKE clusters normally. Zara, the on-call engineer in London, initially served as incident commander. As the incident developed, Il-Seong, a Seattle colleague with more incident response experience, joined the response.
Work and outcome. Zara handed command to Il-Seong, became operations lead, and continued the technical work with others. The GCR on-call engineer eventually removed corrupted cached images, and the errors subsided. Handing over command, expert diagnosis, and the actual repair were separate actions.
How to read this case. This example allows a more precise handoff choice: coordination and decision responsibility can move while the outgoing shift retains its understanding of the problem. All the work need not change hands at once. The relevant question is whether the wait reflects a need for incident command or for technical intervention.
Evidence limits. A handoff across regions preceding recovery does not show that the time difference caused recovery. Transferring command also does not establish that the outgoing shift got to rest. The source provides no comparable decision-latency data.
Original material: Source 1.
24. LLVM D40988: The patch was approved, but its author still could not commit it
Material dates: 2017–2019; the approval and commit exchange took place in March 2019; material type: Public review and a record tied to a specific commit, with versioned policy as context.
Situation and approach. This clang-format option change went through technical discussion. After it was marked accepted on March 15, 2019, the March 21 exchange explicitly described the patch as approved and asked whether the author needed someone else to commit it.
Work and outcome. The author confirmed that they did not have commit access. Another participant subsequently committed the patch, and the archive records closure on March 23. LLVM 8 policy also supports distinguishing code owner status, the ability to offer review comments, and eligibility to approve. A role label alone is not enough to dismiss the approval.
How to read this case. Approval and the conditions needed to carry out a decision can be missing independently. Following work that still cannot finish after someone has said yes can reveal a need to find an authorized person to execute it, rather than send another review reminder.
Evidence limits. The policy is not a day-by-day permissions roster. A commit does not prove deployment, passing tests, or long-term correctness. The earlier technical discussion cannot all be recast as a wait for permission, and this case does not establish a time-zone effect.
Original material: Source 1; Source 2; Source 3.
Continue, change course, or stop: what is worth doing after a decision?
25. Monzo: Pausing feature development to reassess an unclear direction
Material dates: Pause in 2025; retrospective in 2026; material type: Retrospective by a cross-functional product team.
Situation and approach. The mortgage product kept releasing features without resolving questions about its direction. The team paused feature development so that product, research, design, engineering, and analytics could jointly rebuild their understanding of customers, rather than keep adding features.
Work and outcome. Before the pause, the team confirmed that leadership still supported the original opportunity. Engineers briefly supported other work with deadlines, and their return arrangements were communicated in advance. The retrospective describes the research and the emergence of a new direction.
How to read this case. This wait was used to improve the judgment behind the investment. The pause itself required decisions about how other teams would receive the engineers, how research would be resourced, and when the engineers would return. It was neither idle waiting nor an automatic release of cost-free capacity.
Evidence limits. The material lacks a business comparison that isolates the effect of the pause and a full account of the return. It cannot guarantee that a two-month pause leads to success sooner, or make pausing a general solution to all waits between teams.
Original material: Source 1.
26. Scalar: Improving prerequisites while waiting for an adopting team to integrate
Material dates: Development over several years; retrospective covering events through 2022; material type: Retrospective on technical evolution and adoption.
Situation and approach. External platform constraints prompted a change in technical direction, and the characteristics of Office’s build made sparse checkout a viable option. The adopting team still needed to change its build system. Completing the provider’s own code could not, by itself, complete adoption.
Work and outcome. While waiting for integration, Scalar continued to improve installation and the user experience. Once both sides understood the actual workflow, they also found that the switching delays they had feared were not the main constraint at the time.
How to read this case. This case challenges the idea that all waiting is waste. First ask what the dependency actually blocks, and whether work during the wait will reduce the necessary cost of integration or improve the choices available later.
Evidence limits. The material contains no record of scheduling negotiations between managers, complete integration commitments, or acceptance. Performance figures are not delivery lead times. Useful parallel preparation also does not prove that continued expansion is always worthwhile.
Original material: Source 1.
27. GitLab: Making cutover and rollback verifiable before seeking risk approval
Material dates: 2021–2022; material type: Company engineering retrospective and an accessible proof-of-concept change.
Situation and approach. The database decomposition work began by asking teams to identify complex queries and required feature changes. The team ultimately abandoned near-zero downtime because the original approach was hard to roll back reliably, success was difficult to determine, and there was no firm business requirement to avoid downtime.
Work and outcome. The team implemented the work in stages, repeatedly rehearsed cutover and rollback, and fixed the problems those rehearsals revealed. The launch review gave senior leaders evidence that connections, operation, and rollback had been verified, to inform final approval.
How to read this case. Obtaining a decision involves more than passing a problem to senior leaders. Engineering first needs to produce usable evidence about risk and feasibility, after which those with authority can accept the shared consequences. Some synchronous work across time zones remains necessary.
Evidence limits. Only page shells were retrieved for two subsequent work items, so they cannot supply the missing approval discussions or a complete account of resource negotiations. Rehearsals have costs. There is also no evidence that every party had to approve individually or that the schedule necessarily became shorter.
Original material: Source 1; Source 2; Source 3.
28. Slack: Even with technical progress, a shared project may need to stop
Material dates: Retrospective in 2020; project start and end dates not provided; material type: A distinct project within a company retrospective on major technical changes.
Situation and approach. LibSlack aimed to build a shared C++ client library and had made progress on both the concept and implementation. But desktop technology and strategy were incompatible with it, replacing the mobile implementation was costly, and the retirement of the Windows Phone client reduced the number of clients that would share it.
Work and outcome. The retrospective records that the shared project stopped and its lessons were applied to other work. The ability to continue the technical work did not mean that the expected adopters and shared benefits still justified the same investment.
How to read this case. This challenges the idea that work should continue as long as the wait can be removed. New information may support ending the original objective rather than accelerating the next step. Technical maturity cannot replace checking the assumptions about adoption.
Evidence limits. The full staffing reassignments and approval discussions were not made public. The same article’s account of retaining memcached during the gRPC project is an exception within another project. It cannot be folded into LibSlack’s causal sequence or counted again as an outcome of the same case.
Original material: Source 1.
29. Go try: A supporter’s constraint changed part of the design, while the overall proposal was still rejected
Material dates: June–July 2019; material type: Public design proposal, document revision, and closure event.
Situation and approach. During the Go community’s discussion of using try to simplify error handling, magical said they broadly supported the proposal and had therefore not commented earlier. They nevertheless pointed out that accepting multiple separate arguments would create ambiguity if error handlers were added later. Silence meant neither opposition nor an absence of important input.
Work and outcome. On June 12, the document was changed to accept a single expression that could produce multiple values. It preserved the existing function-call form and removed the form with multiple separate arguments. The commit message explicitly attributed the revision to this feedback. In July, the overall proposal was still rejected on broader error-handling and debugging grounds.
How to read this case. A decision process can absorb a local constraint without first securing support for the whole proposal. Acceptance of one revision also does not mean the proposal has been approved. Whether to continue depends on the scope of the decision currently made.
Evidence limits. The revision did not add the future handler feature, and rejection cannot be attributed to one comment. There is no evidence for treating this discussion as a measurable delay that should have been eliminated.
Original material: Source 1; Source 2; Source 3; Source 4.
30. Wikimedia Etherpad: An inventory exposed preservation gaps, and cleanup was postponed
Material dates: 2026, as recorded in the local case material; material type: Public mailing-list discussion and work records.
Situation and approach. When Wikimedia discussed cleaning up Etherpad, some participants argued that the content should already have been moved to the wiki. Others pointed out that important events and decisions were still recorded there. The temporary-storage label did not reflect actual use, changing the scope of preservation that needed to be confirmed before cleanup.
Work and outcome. The subsequent inventory found that searches missed old HTTP URLs, requiring further searches through references in individual notes. Questions also arose about access to backups and newly added data, and cleanup was then postponed. The observable outcome was a delayed action, not completed migration or preservation.
How to read this case. This is a counterexample in which waiting can protect something important. When the available evidence cannot yet establish that important references will remain accessible, postponement is more reasonable than accelerating approval of the original plan. Operational and privacy costs still need attention; indefinite retention is not a cost-free answer.
Evidence limits. The later public record was only partially retrieved, and the eventual cleanup and complete preservation outcomes remain unconfirmed. The number of backups cannot prove that all important references are covered, and the benefits of postponement were not quantified.
Original material: Source 1; Source 2.
31. LLVM D9766: The design discussion ended in abandonment, without successful delivery
Material dates: May 13–December 14, 2015; material type: Public review record ending in abandonment.
Situation and approach. In this InstCombine change, a reviewer raised concerns about operations on large integers, while the author believed the earlier guidance had been different. The discussion concerned design requirements and cannot be described simply as waiting for replies.
Work and outcome. After further design discussion, the author eventually abandoned the review. The surviving record does not establish the ultimate reason for abandonment, and no material shows that earlier managerial intervention would have secured acceptance of the patch.
How to read this case. An examination of review arrangements should retain unsuccessful work. Closure can mean abandonment. A participant’s dissatisfaction also does not mean the original proposal should have been approved; design issues and procedural arrangements still need to be distinguished.
Evidence limits. No implementation or test validation was performed for this analysis. Abandonment cannot be attributed entirely to the review process, or treated as departure from the community, a successful decision to cut losses, or delivered value.
Original material: Source 1.
32. Google Storage SRE: Clearing a backlog can involve cancellation and reprioritization
Material dates: Not specified in the retained material; material type: Company retrospective on an SRE team’s recovery from overload.
Situation and approach. A different storage SRE team faced months of accumulated interrupt-driven work after losing staff. Treating every old request as equally necessary would have kept its limited capacity tied to a historical list.
Work and outcome. The team canceled obsolete or duplicate cases, deferred lower-priority work, and added self-service documentation and small automations. The author reports that months of backlog were dealt with in two days, including deletion and reprioritization.
How to read this case. A decision about waiting work can establish that a request is no longer valid, remove duplication, or defer it, instead of pressing for a completion date on every item. A shorter list must be distinguished from completing the same volume of implementation work.
Evidence limits. This cannot be described as a few engineers completing an equivalent volume of new features in two days, nor does it establish higher individual efficiency. It involved a different team from the Zürich/Sydney case. Although both appear in the same chapter, they cannot share a recovery timeline or be treated as a replication of the method.
Original material: Source 1.
Supplementary material: policy and research
The following policies and studies offer counterexamples and limits for interpreting the cases. They are not counted as additional cases.
Shopify: conditional deadlines, not a universal rule of consent by silence
Shopify’s program account and RFC template, SRC-005–006. These preserve a specific deadline-and-discretion arrangement, not a universal silence-as-consent rule. The account allows the author to choose how to proceed after a deadline when agreement is absent and no explicit veto exists. The template proposes a working-day deadline with a time zone. Neither a readable template nor a policy description establishes one team’s actual execution or the best duration. SRC-005 SRC-006
Nudge: reminders can change closure times without establishing delivery or quality
Nudge, SRC-007. The retained research reports a randomized PR-level comparison of reminders and creation-to-closure time. It prevents treating reminders as inherently useless; it does not validate the article’s delegation proposal. Closure includes outcomes other than merged delivery. The authors’ reprioritization explanation, assumption of unchanged effort, and unverified quality effects remain distinct. The source entry below retains the available aggregate comparison and its limits. SRC-007
Acceptance-to-merging research: potential speed is not an achieved benefit
Acceptance-to-merging research, SRC-008. Its distinction between response, acceptance, and merging helped frame the investigation and led to examining D40988 and D9766. It assumes sufficient authority for an accepting reviewer. Its potential-speed estimate is not an achieved improvement, and overlapping activity categories cannot be treated as mutually exclusive cause shares. The distinction between code ownership and approval authority does not invalidate the entire study or justify removing every acceptance-to-commit interval. SRC-008
Limits on interpretation across cases
No complete comparable before-and-after record of one cross-time-zone team’s work was obtained. The article does not identify approval count as the principal cause of delay, guarantee a speedup, establish equal safety, or calculate net organizational benefit. The cases support practices to examine; the proposed decision process remains management analysis, not the author’s documented success story.
Calendar time is not effort. Overlapping waits cannot simply be added, and a convenient retrospective “decision-ready” timestamp can conceal earlier clarification. Decisions, closure, merging, release, and useful delivery are different endpoints. Rejected and unfinished work must remain visible. Earlier decisions can have local benefits without moving release; stopping an ineffective trial does not meet its original goal.
Clear roles do not create review time, compel a decision, or supply missing expertise. A deadline during someone’s non-working period does not establish a reasonable opportunity to participate. An authorized default differs from inventing consent from silence. Information-gathering trials need appropriate authority, and reverting code need not reverse data changes, external commitments, or effects on others.
Actual effort, displaced work, quality consequences, changing shared constraints, and whether the target wait was removed still need examination in a real trial. The material does not prescribe a universal delegation threshold, trial length, risk allowance, review cadence, or capacity-allocation mechanism.
Source catalogue
The catalogue provides source titles, authors, dates, relevant passages, findings, and limits. Access dates describe historical checks; these sources have not been freshly reverified. Numbered references connect related entries below.
SRC-001–3 Simple Tips for Remote Engineering Teams
Author / organization: Chris Rooney / Equal Experts. Source type: company engineering-practice retrospective. Published / updated: 2020–04–20. Accessed: 2026–10–04 initially; 2026–10–05 in subsequent research checks. URL: SRC-001
Location: Pull Requests, Think Ahead, and Technical Alignment.
Retained finding: The account describes a New York client and an engineering team in Portugal gradually delegating some PR approvals, starting with lower-risk work and retaining complex exceptions. They also scheduled a regular review window in the New York morning and Portuguese afternoon. This supports distinguishing approval location from the opportunity to perform review.
Limits: Individual PR identifiers, delegation dates, named decision-makers, required checks, commit permissions, actual review effort, and comparable before-and-after records were not supplied. Positive results are the author’s assessment. Statements about fewer errors, rework, and technical debt occur in Technical Alignment; they must not be attributed to delegation alone. The article does not adopt the source’s stronger position on eliminating PRs because equivalent alternative controls were not established.
SRC-002 — Clang-format: add finer-grained options for putting all arguments on one line
Author / organization: russellmcc and participants / LLVM D40988. Source type: archived public code review. Published / updated: 2017–12–07. Accessed: 2026–10–04 initially; 2026–10–05 in a subsequent research check. URL: SRC-002
Location: summary, reviewer fields, discussion, and commit reference; especially March 15–23, 2019. No full diff or algorithm correctness audit was performed.
Retained finding: The record includes option-interaction concerns on 2018–02–05 and interruptions in the exchange during July–October 2018. On 2019–03–15, MyDeveloperDay marked the patch accepted, mentioning not being the code owner; maintainability and the cost of understanding the code were still discussed. On March 21, jkorous explicitly described the patch as approved and asked whether the author needed someone to commit it. The author confirmed lacking commit access. On March 22, the author asked about other concerns; the archive records closure by commit on March 23.
Limits: The explicit approval exchange carries more weight than speculation based on the code-owner label. SRC-010 does not require every approver to be a code owner. This supports separating approval from execution capability, not treating all preceding time as a permissions problem. Daily access rosters, working hours, private communication, and effort are unavailable. The case establishes neither time-zone effects, typical delay, individual fault, nor patch correctness.
SRC-003 — LLVM commit c6deae452197631a4530a50df266cdf5063b601e
Author / organization: LLVM Project; committer: mydeveloperday; patch author: russellmcc. Source type: fixed commit in the official repository. Published / updated: An independent commit timestamp was not retained; see SRC-002 for the review closure date. Accessed: 2026–10–04. URL: SRC-003
Revision / version: c6deae452197631a4530a50df266cdf5063b601e; llvm-svn: 356834. An independent commit timestamp was not retained.
Location: commit identity, message, D40988 reference, and changed-file list.
Retained finding: The commit distinguishes Reviewed By from Patch By and supports another participant performing the commit; the committer must not be described as the original patch author. Recorded files include clang/lib/Format/ContinuationIndenter.cpp, clang/include/clang/Format/Format.h, clang/lib/Format/Format.cpp, documentation, and clang/unittests/Format/FormatTest.cpp.
Limits: No build or tests were executed in this work. A changed test file is not evidence of passing tests. The observed endpoint is a commit, not deployment, long-term quality, or user value. Exact line numbers and function-level behavior were not retained or audited.
SRC-004 — The Power of “Yes, if”: Iterating on our RFC Process
Author / organization: Tanya Reilly / Squarespace Engineering. Source type: organizational engineering-process retrospective. Published / updated: September 11 is shown on the page; the URL indicates 2019. A full independent publication timestamp was not retained. Accessed: 2026–10–04 initially; 2026–10–05 in subsequent research checks. URL: SRC-004
Location: body through the conclusion, particularly Opinionated RFC template, Infrastructure Council, Architecture Review, and Conclusion.
Retained finding: Naming approvers did not ensure participation by all affected teams. The larger Infrastructure Council had problems with review depth and unclear blocking authority. A smaller Architecture Review later brought in relevant users and domain experts; the Infrastructure Council shifted toward discussion, sharing, and community.
Limits: The account distinguishes approval, review, and discussion functions. It is not an ordinary-PR speed comparison or a time-zone experiment. The author’s favorable assessment lacks individual time-and-quality comparisons. The example RFC about the blog post is hypothetical, not a completed engineering project. Actual project-specific authority and full decision traces are unavailable. The source limits delegation claims; it does not prove centralized review is always preferable.
SRC-005 — A Guide to Running an Engineering Program
Author / organization: Carla Wright / Shopify Engineering. Source type: company engineering-program practice account. Published / updated: 2021–07–21. Accessed: 2026–10–04. URL: SRC-005
Location: program context and roles, the Engineering Request for Comments (RFC) section, and related conclusion. Not every linked program document was inspected.
Retained finding: The RFC section describes a particular discretionary arrangement: after the discussion deadline, with no agreement and no explicit veto, the author chooses how to proceed. This is not automatic approval and does not establish that all necessary participants reviewed the proposal.
Limits: The supplied record contains no complete implementation trace for an individual RFC. The source tests claims about deadlines and authority, not measured shorter delay. It cannot be generalized into silence always meaning consent.
SRC-006 — Shopify Engineering Request for Comments (RFC) template
Author / organization: ShopifyEng. Source type: public template linked from SRC-005. Published / updated: the preserved record reports Last active 2022–08–31; this is not a creation date or policy effective date. Accessed: 2026–10–04. URL: SRC-006
Location: all fields in RFC.txt; no gist revision was pinned.
Retained finding: The template proposes three working days and a time zone for the deadline, along with context, the proposal, arguments for and against, and people who should be informed.
Limits: A public template does not prove adoption by a specific team or effectiveness of that deadline. Three working days is not a universal service-level target. Without a pinned revision, the URL is a retrieval route rather than immutable version evidence.
SRC-007 — Nudge: Accelerating Overdue Pull Requests Towards Completion
Author / organization: Chandra Maddila et al. Source type: original research, 31-page preprint. Published / updated: arXiv:2011.12468v5, 2022–06–17. Accessed: 2026–10–04 initially; 2026–10–05 in a subsequent text recheck. URL: SRC-007
Revision / version: arXiv:2011.12468v5, 2022–06–17.
Location: sections 8–9; Table 4 on PDF page 23; §§9.2–9.3 on pages 26–27. Page numbers are one-based.
Retained finding: The historical research record reports randomized PR-level comparisons across 147 Microsoft repositories and reduced mean creation-to-closure time with nudges. The study also tracks abandonment, so closure cannot be equated with merging, deployment, or delivered value. The evidence is retained against the claim that reminders are inherently useless.
The retained Table 4 comparison reports mean hours from PR creation to closure: no nudge, 197.2 hours across 3,856 PRs; LT, 112.6 hours across 4,117 PRs; FULL, 77.7 hours across 4,383 PRs. LT uses lifetime prediction; FULL additionally includes activity and target identification. These historical aggregate figures have not been independently reproduced.
Limits: The authors explain the result through reprioritization. Unchanged total effort is an assumption, not a measured finding; quality effects remain unverified. The notes retain negative feedback about dependencies and leave in §8.4.3, and the lack of the same randomized comparison in the later expanded deployment. FULL combines multiple functions, so no separate effect is assigned to each addition.
Figures and tables on pages 23–25 were inspected; for pages 26–27, readable text was available but screenshots could not be obtained. This limits visual verification and supplies no independent statistical validation. No raw samples or rerun were obtained. One paragraph on PDF page 24 uses denominator 4018 while Table 5 uses 4081; no ratio is calculated from that inconsistency.
Hardware, runtime, study dates, detailed sample selection, random seed, exclusion and outlier procedures, per-repository balancing, and reproduction commands were not fully retained in the supplied notes. No p95, effort saving, or delegation benefit is derived from the means.
SRC-008 — Mining Code Review Data to Understand Waiting Times Between Acceptance and Merging: An Empirical Analysis
Author / organization: Gunnar Kudrjavets, Aditya Kumar, Nachiappan Nagappan, Ayushi Rastogi. Source type: original observational research, 12-page preprint. Published / updated: arXiv:2203.05048v1, 2022–03–09. Accessed: 2026–10–04. URL: SRC-008
Revision / version: arXiv:2203.05048v1, 2022–03–09.
Location: first page, event/time-boundary definitions, post-acceptance activity, Discussion, Threats to Validity; page 2 provided the D40988 and D9766 investigation leads. The analysis was not rerun.
Retained finding: The study distinguishes first response, acceptance, and merging and explicitly assumes sufficient authority for the accepting reviewer. It is an entry point for investigating post-acceptance time, not proof that every period without public activity is valueless or removable.
Limits: Its 29–63% potential speed estimate is not treated as an achieved improvement. Post-acceptance activity categories overlap and must not be added as mutually exclusive cause percentages. The LLVM policy distinction between code ownership and approval authority does not invalidate the entire study, justify automatic merging, or make every acceptance-to-commit interval removable.
SRC-009 — Add support for complex aggregate store in InstCombine
Author / organization: deadalnix and participants / LLVM D9766. Source type: archived public review ending in abandonment. Published / updated: Created 2015–05–13. Abandoned 2015–12–14. Accessed: 2026–10–04. URL: SRC-009
Location: summary, role fields, main discussion, and status; no implementation or test verification.
Retained finding: majnemer raised concerns about large-integer operations; the author believed earlier guidance had differed. Design discussion continued, and the author ultimately abandoned the review. The record does not establish the final reason.
Limits: This is retained against success-only selection. Frustration does not establish process as the sole cause. Abandonment is neither approval nor demonstrated value delivery. There is no basis for claiming that earlier managerial intervention would necessarily have rescued the proposal, or that the patch should have been accepted.
SRC-010 — LLVM Developer Policy — LLVM 8.0.0
Author / organization: LLVM Project. Source type: official versioned developer policy. Published / updated: LLVM 8.0.0; an independent document publication timestamp was not obtained. Accessed: 2026–10–05 in policy checks. URL: SRC-010
Revision / version: LLVM 8.0.0; an independent document publication timestamp was not obtained.
Location: Code Reviews, Code Owners; the recorded check also includes Obtaining Commit Access.
Retained finding: The recorded policy distinguishes anyone providing review comments from approval by a person with Subversion write access. Code ownership, the reviewer role, and responsibility for ensuring review are not identical.
Limits: Not being a code owner does not establish ineligibility to approve D40988. Versioned policy does not reconstruct every participant’s permissions on every day, and a later commit does not prove all earlier authority. The policy supplies historical context for the LLVM case, not a current-policy assertion or a rule for commercial teams.
