Two questions sound almost identical when you say them quickly. Who caused this. And what allowed this to happen. In practice they lead to entirely different outcomes, because one of them ends the moment you attach a name to a bug, and the other keeps going until you've actually found the thing worth changing.
Why the first question feels satisfying
Attaching a name or a team to a bug gives triage a sense of resolution. The ticket feels closed. Something has been decided. The problem is that a name isn't a fix. It's a place to stop looking, and stopping there means the actual condition that produced the failure often keeps living exactly where it always was.
A symptom that pointed the wrong way
Once, a crash pointed cleanly at a single component. Every log agreed on it. Deeper inspection showed that component had actually done exactly what it was supposed to do given the input it received. The real problem started upstream, something fed it data it should never have gotten in the first place.
If the investigation had stopped at the first question, the fix would have landed on a team that had done nothing wrong, and the actual condition, the thing generating bad input upstream, would have kept generating it. Fixing the component that crashed would have addressed the symptom while leaving the cause fully intact.
Why recurrence is the real cost
A fix applied at the surface can absolutely come back. The same underlying condition resurfaces later wearing a different symptom, sometimes months afterward, disguised well enough that nobody connects it to the original incident. This is the actual argument for systems thinking over blame thinking. It isn't a matter of being kinder to people involved, although it usually is kinder. It's a matter of whether the fix actually holds.
This idea has real institutional weight behind it. The discipline of blameless postmortems, which originated from site reliability engineering practices and was popularized by organizations including Google and Netflix, rests on a similar premise. A human decision is rarely the true root cause of an incident, because complex systems have to be built to tolerate human mistakes. Naming the immediate trigger tells you what happened. It doesn't tell you why the system allowed it to happen in the first place. Etsy is often credited as an early adopter of this idea, with leadership deliberately shifting the internal conversation from who should be blamed to what could actually be learned.
How ownership actually gets decided
Deciding who's positioned to own a fix isn't about assigning fault. In practice, it comes down to a combination of things, documented patterns other teams have shared over time, a handful of clear-cut cases where a certain category of issue obviously belongs to a certain kind of team, and expertise built from having seen enough similar shapes of failure to recognize one quickly. None of that requires knowing who to blame. It only requires knowing what actually happened and where the real ability to fix it sits.
The question that actually prevents recurrence
The question that stops a bug from coming back isn't who caused it. It's what allowed it. That's the entire premise behind how I approach triage. The goal was never simply to close a ticket. It's to fix the system underneath the ticket, so the same failure doesn't have the opportunity to happen again in a different shape.
A necessary complication
It would be dishonest to present this as a clean either-or. Most root causes involve both a human element and a systemic one. A person made a decision, and a system made that decision easy or even likely to make. The point of systems thinking was never to erase the human piece of the story entirely. It's to stop treating that human piece as the end of the investigation rather than one input into a larger one.