Why incident recovery stalls between teams
Picture a constructed incident timeline. At 14:40 the checkout error rate crosses the alert threshold. The on-call engineer acknowledges the page in two minutes, opens the dashboard and starts reading logs. Fifteen minutes later they suspect the fault is not in checkout: the failing calls go to an identity service owned by another group, and the errors began shortly after a configuration change there. They post in the incident channel. That group runs its own rotation, and the person who made the change is in a workshop. Someone replies at 15:10 and says they will look. At 15:30 a delivery manager joins and asks whether this is really a Sev1, because the escalation policy and the runbook disagree. The engineer who can revert the config joins at 15:45. The fix itself is small.
In this illustration, most of the hour goes to waiting for a person to appear and waiting for someone with the authority to decide. The point is not that incidents generally follow this exact sequence. It is that a timeline review can separate technical work from coordination waits without blaming the second team.
An outage creates a temporary organization. For an hour or two, people who normally work on separate backlogs share a single goal. If roles and routes are unclear, they may have to assemble the response structure while they diagnose the fault. The studies below make that coordination path worth inspecting, but they do not quantify how much incident time it consumes.
Where the minutes actually go
Ghosh et al. (2022) examined hundreds of high-severity incidents and their postmortems in Microsoft Teams across detection, routing, root-causing and mitigation. Their record identifies gaps in that response process that delayed response. The abstract-level evidence does not support a more specific account of who waited for whom, nor does it isolate ownership as a cause. It comes from one service and one severity class. For a local review, it is a reason to inspect the transitions between detection, diagnosis and mitigation rather than assume that all delay sits in the technical fix.
Sillito and Pope (2024) worked from a different sample, analyzing 89 failures described in 70 public incident reports. Their study treats responders' contributions and challenges as part of recovery. Public reports are a selective sample, written after the fact by people with hindsight and an audience. The abstract-level record does not report a measured link between coordination and recovery duration.
Ownership, authority and capability belong together
Lwakatare et al. (2019) interviewed 26 practitioners across five small and medium companies selected as successful DevOps adopters, and observed how they worked. The study links development-team ownership of deployment and supporting toolchains with faster handling of changes, bug fixes and production incidents. It also reports external approval handoffs as a source of delay. This is qualitative, perception-based evidence, not a measured estimate of incident recovery time.
The same study is blunt about the cost. Practitioners reported pressure and a steep learning curve. Owning production may expand what a team is expected to know and handle. Production incidents were also a secondary theme there, not the measured outcome. Nobody ran a stopwatch.
The operating hypothesis is that ownership matters through the path to action, not through the label alone. A team may own a service yet still need external permission to change a shared configuration or declare a severity. A timeline review can reveal whether such a dependency creates a wait in that organization.
Emergency coordination is a different mode
Kotlarsky et al. (2020) compared two IT functions and watched what happened to coordination when things went wrong. Both ran on the same building blocks: prioritization, procedures, roles and responsibilities, and the informal networks people use to find each other. Under emergency conditions those blocks did not simply intensify; they changed in kind.
One function had prepared for that switch. When an emergency started it moved into formal, emergency-specific practices. The other improvised because its business-as-usual practices did not fit the pressure. The comparison suggests that prepared emergency roles and procedures can reduce the need to invent coordination during an incident. It does not show that this produces faster recovery.
Two cases, no recovery times measured. The useful question is narrower: which parts of your emergency mode are prepared, and which still have to be improvised?
What the evidence will not promise
The obvious move from here is to redraw the teams. Merge dev and ops, give every service one owner, delete the boundary that hurt this time.
Korkmaz and Aydin (2025) surveyed 105 DevOps practitioners and compared four team formations across several performance goals, including mean time to recovery. Team formation did not significantly influence whether MTTR goals were met, and the fully merged team was not the leader on that measure. The survey is cross-sectional, self-reported and self-selected. Its topology construct is coarse, and the per-group samples may have had limited power to detect differences. The null result does not prove equivalence or show that structure is irrelevant. It does not support prescribing one topology for lower MTTR from this evidence.
Ownership clarity may aid incident recovery when responders have authority to act and a route to relevant expertise. A qualitative two-case study suggests that prepared emergency roles and procedures can reduce improvisation, but it did not measure recovery time. The selected evidence does not support prescribing one team structure for lower MTTR.
That is narrower than most reorganization proposals assume, and it points at cheaper work: find a specific wait in the current incident path, change one condition around it, and observe what happens.
Run a 30-minute incident-path review
Take the last serious incident. Not the worst one ever, the most recent one that hurt. Get the people who were actually in the call, put the timeline in a shared doc, and mark four things.
The first actionable signal: the moment someone held information that pointed at something they could do. Record it separately from the first alert.
Every expertise handoff: each point where progress waited on a person who was not yet involved. Write the wait next to it.
Every decision wait: severity calls, permission to restart, permission to roll back, approval to touch a shared component.
Prepared against improvised: where responders followed a role or route that existed before the incident, and where they invented one on the spot. Both happen. The comparison identifies candidates for a local test; it is not a validated maturity score.
Thirty minutes buys a map, not an answer. Then pick one change and only one: a standing severity rule that removes a decision wait, an on-call route into the second team, a written emergency role, a permission granted in advance. Note which wait you expect it to remove.
Then test it against the next comparable incident. If the wait you targeted is still there, the change missed, and you can pick the next one off the same map.
References
Ghosh, S., Shetty, M., Bansal, C., & Nath, S. (2022, November 7). How to fight production incidents? In Proceedings of the 13th Symposium on Cloud Computing (pp. 126–141). ACM. https://doi.org/10.1145/3542929.3563482
Korkmaz, H. E., & Aydin, M. N. (2025, September 1). An empirical study on performance comparisons of different types of DevOps team formations. Frontiers in Computer Science, 7. https://doi.org/10.3389/fcomp.2025.1554299
Kotlarsky, J., van den Hooff, B., & Geerts, L. (2020). Under pressure: Understanding the dynamics of coordination in IT functions under business-as-usual and emergency conditions. Journal of Information Technology, 35(2), 94–122. https://doi.org/10.1177/0268396219881461
Lwakatare, L. E., Kilamo, T., Karvonen, T., Sauvola, T., Heikkilä, V., Itkonen, J., Kuvaja, P., Mikkonen, T., Oivo, M., & Lassenius, C. (2019). DevOps in practice: A multiple case study of five companies. Information and Software Technology, 114, 217–230. https://doi.org/10.1016/j.infsof.2019.06.010
Sillito, J., & Pope, M. (2024, October 28). Failing and Learning: A Study of What is Learned About Reliability From Software Incidents. In 2024 IEEE 35th International Symposium on Software Reliability Engineering Workshops (ISSREW) (pp. 295–302). IEEE. https://doi.org/10.1109/issrew63542.2024.00093