Writing · · 5 min read
The expensive incidents are the ones nobody owns
Your longest outages are rarely your hardest technical problems. Most of that time is spent finding out whose problem it is.
Pull up your five longest incidents from last quarter. Not the most severe — the longest. Then ask a question your post-incident reviews almost certainly do not answer:
What time did the person who actually fixed it join the call?
In my experience the answer is uncomfortable. The repair, once the right engineer is engaged and understands the problem, is frequently fast. Twenty minutes. Sometimes five. The hours that preceded it were not spent fixing anything. They were spent finding out whose problem it was.
The specific failure is familiar to anyone who has run a major incident bridge. The call is open, the severity is agreed, executives are asking for updates — and the technical resources who could actually diagnose the problem are not on it. Not unwilling. Unidentified, or off-shift, or attached to a vendor whose on-call rotation nobody present can produce. The incident is fully staffed with people who cannot fix it.
MTTR hides its own biggest component
Mean time to resolution is treated as a single number, but an incident has distinct phases and they behave nothing alike:
- Detection — something is wrong and we now know it
- Triage — what is the impact and how bad is this
- Ownership discovery — who can fix this
- Repair — fixing it
- Verification — confirming it is actually fixed
Most organizations measure the first, the last, and the total. Ownership discovery is invisible because it does not correspond to a status change, a queue transition, or a timestamp anyone thought to capture. It is what happens in the gap — the bridge call where eleven people are present and none of them own the failing component.
It is also, in complex environments, routinely the longest phase.
Post-incident reviews systematically miss this. The review asks for root cause, and root cause is a technical question, so the answer is technical: an expired certificate, a bad deploy, a full disk. All true, and all silent about the ninety minutes spent working out that the certificate belonged to a service managed by a vendor whose escalation contact had left the company.
You end up with a remediation plan that addresses a fifteen-minute problem and completely ignores the ninety-minute one.
Why it happens to good organizations
This is not a competence failure. It is the natural consequence of scale and time.
Systems get built by teams that reorganize. Vendors get contracted by managers who move on. Services get inherited by whoever was nearby. The runbook lists a distribution list that now has four people in it, three of whom changed roles. The escalation matrix was accurate the quarter it was written.
Nobody decided this. It accumulated. And it is invisible during normal operations — ownership ambiguity costs nothing at all until the moment it costs everything, which is precisely why it never wins a prioritization argument.
The problems that live between teams have no natural owner, which means they have no natural advocate. Everyone can see them during an incident. Nobody owns fixing them afterward. The structural problem and the incident have the same shape.
What actually moves the number
Measure time-to-owner as its own metric. One timestamp: when did the person who ultimately resolved this join? You can reconstruct it from bridge logs and chat history for past incidents. Do that for your last twenty. The distribution will tell you more about your operation than your MTTR trendline has in a year.
Maintain a service ownership record, and treat it as production data. Every service: who owns it, which vendor supports it, what it depends on, what depends on it, who gets called at 2am, and when that was last verified. The last field is the one that matters — an ownership record nobody re-confirms becomes actively harmful, because people trust it and it is wrong.
Re-verify on a schedule, not on an incident. Quarterly, ask each owner to confirm they still own it. This takes minutes and it is the difference between a directory and a fiction.
Add one question to every post-incident review. How long did it take to find the right person, and what would have made that faster? One question, asked consistently, surfaces a category of problem your current template cannot see.
The part that makes this hard
None of this demos well.
Ownership records, dependency maps, and verified escalation paths produce no screenshot, no launch, and no visible win. The work is boring, the benefit is counterfactual — outages that were shorter than they would have been — and the counterfactual is unprovable to the person approving the budget.
So it loses, quarter after quarter, to work that photographs better. Then a major incident runs seven hours, the review names a technical root cause, and the actual failure goes unrecorded and unfixed and happens again.
The organizations that get this right are not smarter. They simply decided that knowing who owns what is infrastructure, not documentation — and funded it that way.
Run the time-to-owner reconstruction on your last twenty incidents. If the gap is smaller than a third of total duration, your ownership model is in better shape than most.