When I read a company’s incident history for the first time, I am not looking for the big outage. The big outage has usually been discussed at length, written up, and remembered by everyone. What I look for instead are the smaller incidents that sound familiar to one another, because in my experience the real story of an engineering organisation is told by recurring incidents, and the absence of root cause ownership is almost always the reason they keep returning.
A payment sync fails in March. An order export stalls in May. A customer report goes out with the wrong figures in August. On paper these are three separate tickets, handled by three different engineers on call, each closed with a reasonable fix and a short note. Underneath, when you trace them carefully, they are frequently the same weak point surfacing in a new place, whether that is a fragile integration, an unvalidated data field, or a scheduled job nobody fully understands anymore.
What makes this pattern so persistent is that everyone did their job. Every team closed its ticket, every alert was cleared, and every on call rotation ended with the system working again. What nobody owned was the pattern connecting the three events. That gap does not appear in any individual performance review, which is exactly why it survives quarter after quarter.
Most leaders who have run this calculation are surprised by where the real cost sits.
Why Recurring Incidents Hide in Plain Sight
Most incident processes are designed to restore service, and they do that well. The metrics that leadership teams watch, such as time to acknowledge and time to resolve, reward speed of recovery. Those are useful measures, but they carry a quiet side effect. They make each incident look like a separate event with its own clock, which means the connection between incidents is never measured at all.
In our engineering reviews across SuperBotics’ 500+ successful projects and more than 150 enterprise launches, I have seen this across every kind of stack. It shows up in React Native mobile platforms, in Odoo implementations with custom modules, in data pipelines feeding analytics, and in integrations between ERP and ecommerce systems. The technology changes, but the organisational pattern does not. The team gets very good at fixing symptoms and never gets the time or the mandate to remove causes.
There is also a human reason these incidents stay hidden. Engineers who fix the same class of problem repeatedly often stop reporting it as a pattern because it feels like complaining. They absorb it as part of the job. Over time, the recurring issue becomes background noise, and the organisation quietly budgets a portion of every week for problems it has already solved once.
The hidden risk: a stable time to resolve metric can mask a rising volume of repeat work. A team can look healthier every quarter on paper while spending more of its week on problems it has already fixed.
What Root Cause Ownership Changes Inside a Team
The engineers are rarely the issue. In almost every organisation I have worked with, the people on call are capable, committed, and understand the system better than anyone in leadership. What is missing is one person whose explicit job is to ask why a particular problem keeps coming back, and who has the authority and the time to do something about the answer.
That is what root cause ownership means in practice. It is not a new team, a new tool, or a heavier postmortem template. It is a clear assignment: every recurring issue gets a single named owner, and that owner is responsible for removing the cause rather than clearing the next alert. The owner is not necessarily the person who fixes each incident. They are the person who follows the thread across incidents until it is closed for good.
When I introduce this early in a Fractional CTO engagement, the first reaction is often mild scepticism, because it sounds too simple to matter. Then the first few owners start reporting what they find, and the leadership team begins to see how many different tickets trace back to the same handful of weak points. The conversation shifts from “why do we keep having incidents” to “which three causes, if removed, would eliminate most of our repeat work.”
The Pattern Owner Protocol: How I Structure It
Over years of refining this approach, I have settled on a structure I call the Pattern Owner Protocol. It is intentionally light, because a protocol that adds significant overhead to an already stretched engineering team will be abandoned within a month. It runs alongside the existing incident process rather than replacing it.
- Tag on close: every resolved incident gets a short cause tag, describing the underlying weakness rather than the visible symptom.
- Cluster monthly: once a month, incidents sharing a cause tag are grouped, and any cluster with two or more events becomes a recurring issue.
- Assign one owner: each recurring issue receives a single named owner with protected time to investigate and remove the cause.
- Define done: the owner agrees what “removed” means, such as a validation rule, a redesigned integration, or a retired job.
- Review quarterly: leadership reviews the recurring issue list each quarter, focusing on what has been closed rather than what is open.
The step that matters most is defining done. Without it, recurring issues drift into permanent investigation, which is simply a slower version of the original problem. When an owner has to state in plain language what removal looks like, the work becomes finite, and finite work actually gets finished. I have seen teams close issues in weeks that had lingered for more than a year once “done” was written down.
Measuring Repeat Work Instead of Resolution Speed
Changing what gets measured is the other half of making root cause ownership stick. If leadership continues to review only resolution speed, the organisation will continue to optimise for it. Adding one or two measures focused on repetition gives the team permission to spend time on causes, because leadership is visibly paying attention to them.
| Measure | Symptom Focused Team | Cause Focused Team |
|---|---|---|
| Primary metric | Time to resolve each incident | Share of incidents that are repeats |
| Ownership | Whoever is on call | Named owner per recurring cause |
| Postmortem output | A fix for this event | A link to an existing pattern or a new one |
| Leadership review | Open incident count | Recurring causes closed this quarter |
| Team experience | Constant firefighting | Shrinking list, quieter evenings |
The share of repeat incidents is the single most revealing number I ask for. It is rarely tracked at first, so the initial figure is usually an estimate built from the cause tags over one or two months. Even a rough estimate changes the leadership conversation, because it turns an invisible cost into a visible one. I explored a related idea about how unrecorded choices accumulate in how undocumented architecture decisions become technical debt.
The Human Cost of Solving the Same Problem Twice
It is easy to discuss recurring incidents purely in terms of system reliability, but the cost I care about most is human. Engineers who spend their evenings fixing a problem they already fixed in spring lose something beyond time. They lose the sense that their work compounds. Over months, that erodes motivation, and it is one of the quieter reasons strong engineers leave organisations that otherwise treat them well.
Root cause ownership reverses that experience. When an engineer removes a cause and watches a whole category of alerts disappear, the work suddenly feels meaningful again. Within a quarter of introducing the Pattern Owner Protocol, the recurring issue list typically gets shorter, on call rotations become calmer, and the team finally gets its evenings back. That change in morale is often what leadership notices first, even before the reliability numbers move.
This is also why I see root cause ownership as a leadership responsibility rather than an engineering one. Engineers can only remove causes if someone protects the time to do it and treats that work as seriously as feature delivery. If you are unsure whether your organisation is set up this way, it is worth reading how a Fractional CTO spots the real problem in week one, because recurring incidents are one of the first signals I look for.
Making the Next Occurrence the Last One
Every company has recurring incidents, and there is nothing embarrassing about that. What separates organisations that grow calmly from those that grow chaotically is whether someone owns the pattern. When recurring incidents are treated as a single problem with a single owner, they become finite. When they are treated as separate tickets, they become permanent.
The good news is that this change is achievable within a quarter, requires no new tooling, and pays back in reliability, in engineering morale, and in the time your team gets to spend building instead of repairing. Across 15 years and clients in more than 14 countries, I have yet to see a team that did not benefit from naming the owner of its most familiar problem.
So the next time the same problem shows up, ask one question before anyone opens a ticket: who in this company owns making sure this is the last time? If the room goes quiet, you have found your most valuable piece of work for the quarter, and the answer to that silence is worth more than any single fix your team will ship this year.
The gap between a full-time CTO and a Fractional one is rarely what organisations expect before they see the numbers.
