The Stance and Moves of Incident Response — Don't Blame, but the Owner Leads

If you operate systems, incidents are unavoidable. No matter how carefully you write tests, no matter how many reviews you stack up, production breaks eventually. The more complex a distributed system gets, the closer it becomes to impossible to anticipate every failure mode in advance. So the question isn’t “will you cause an incident?” but “how will you move when one happens?”

This post is an essay collecting what I usually tell my team about the stance and the moves of incident response. It comes down to three things. Don’t blame the fact that an incident happened. But do ask the person closest to the cause to take responsibility and lead the response. And regardless of whether they carry a leader’s title, everyone in the room should show leadership and move. I’ll work through these three points using established ideas as a lens: blameless postmortems, Just Culture, and incident command.

Don’t Blame the Fact That It Happened: The Blameless Premise

As a starting point, we don’t blame an individual for the mere fact that an incident happened. This isn’t leniency. It’s a rational operational choice for learning from failure and not repeating it.

The idea was systematized by what Google SRE calls the blameless postmortem. In Postmortem Culture: Learning from Failure, a blamelessly written postmortem “assumes that everyone involved in an incident had good intentions and did the right thing with the information they had.” Instead of hauling up the person who ran the wrong command or wrote the risky code, you ask why, at that moment, that decision looked reasonable. You go looking for the cause in the system and the process, not in the person.

The safety engineering field has pushed this even further. Sidney Dekker argues repeatedly that human error is not the cause of a failure but a symptom of a deeper problem in the system surfacing to view. If you swap the person out and the next person, placed in the same situation, makes the same mistake, then what needs fixing is the system, not the person.

Why is not blaming the rational move? The reason is simple: a blaming culture hides information. In an environment where the person who slipped up gets hauled up, everyone starts minimizing their own involvement next time. The first report of an incident comes late, what actually happened gets harder to see, recovery slows as a result, and prevention grows shallow. Conversely, an environment where you can honestly say “I set this wrong here” is one where the psychological safety that Amy Edmondson describes is working, and there the facts arrive quickly and both the response and the learning move faster. Not blaming is, before it is kindness, an investment in speed and in preventing recurrence.

”Don’t Blame” Is Not “No Responsibility”: The Owner Leads the Response

Here comes an important line to draw. “Don’t blame the fact that it happened” does not, in the slightest, mean “the person who caused it can do nothing.” Not blaming and taking responsibility for the response coexist. In fact, they have to.

The distinction is drawn vividly by the contrast between two kinds of accountability in Dekker’s Just Culture. One is retributive accountability, which asks which rules were broken and what punishment should follow, and for whom. The other is restorative accountability, which asks who is hurting, what they need, and how to restore trust and learning. What blameless lets go of is the first kind, responsibility as punishment; it is not the second kind, the responsibility to face forward and set things right.

And the person who can most effectively discharge that restorative responsibility is, more often than not, the one closest to the cause. The person who made that change knows most deeply why they made it, what they overlooked, and what else is wired to it nearby. That’s exactly why I want the owner to step forward rather than duck out, and lead the response: direct the triage, put the facts out, write the postmortem in their own hand, and take ownership of the prevention items. This isn’t punishment. It’s the most natural division of labor there is, the person with the most context putting that context to work for the team.

An owner stepping forward instead of hiding is the best possible lesson for a team. Each time one real example accumulates, that “if you own up honestly and set things right, you’re trusted rather than blamed,” a blameless culture takes root as experience rather than as words. Conversely, if the pattern of the owner hiding while others clean up the mess continues, blameless degenerates into mere “whoever speaks up loses.” The promise not to blame only works when it is paired with the behavior of the owner taking responsibility and moving.

Not Title, but Whoever Steps Up Leads: Distributed Leadership

The third stance is about leadership. Leadership in incident response isn’t tied to rank or title. Whoever is present, notices first, and steps up first is the leader for that moment.

This idea has a clear, battle-tested shape forged on the front lines of disaster response: the framework called the incident command system (ICS), which both Google SRE and PagerDuty’s incident response guide have carried into software operations. The central role here, the incident commander (IC), is not the most senior person nor the most technically skilled. It’s the person who coordinates the overall response and drives decisions forward, and anyone can take it simply by declaring it. In practice, many teams operate on the rule that “whoever picks up the pager becomes the IC for that incident.”

So even as an individual contributor, you don’t need to wait for a senior person to arrive. Once you notice an incident, you can open a channel yourself, declare the situation, summon the people you need, and assign roles. Leadership isn’t something you exercise after asking permission; it begins the moment you step up. Of course there are situations where a more suitable person should take over as IC, but even that handover only happens because someone moved first. Nobody moving during those few blank minutes is far more dangerous than crossing a line of authority.

What I expect of team members is this “don’t wait” way of moving. Rather than stepping back because you’re not the leader or because you weren’t the cause, find what you can do to make the situation better, and do it. An incident is where leadership gets tested regardless of title, and at the same time, the best opportunity there is to show it.

The Moves: Mitigate, Declare, Record, Hand Off

When you translate the stance into concrete action, a response has a few set moves. The more flustered you are, the more it helps to be able to move along a template.

Mitigate first: as Managing Incidents teaches, the first thing to do is not to uncover the root cause but to stop the damage. Roll back, disable with a flag, isolate the component, play the moves that restore service first. Investigating the cause is something you do calmly once you’ve stopped the bleeding.
Declare the roles: don’t carry it all alone; carve out roles early, such as IC (overall coordination), comms (internal and external communication), and scribe (recorder). At small scale one person can wear several hats, but just saying out loud “I’m the IC right now” makes the chain of command clear.
Share information in the open: open a dedicated channel and keep streaming what you know, what you don’t, and the next move, without hiding any of it. Separating speculation from fact matters too. Hoard information and the people around you start filling in the gaps with guesses, which only adds to the chaos.
Keep a timeline: record what happened when, and what you did when, in chronological order as you go. This record becomes the primary source for the later postmortem and enables a far more accurate retrospective than a reconstruction from memory.
Hand off if it runs long: if the response stretches over hours, handing off is safer than continuing to make calls with a tired head. Stay aware of who has become a single point of failure, and keep authority and context in a state you can explicitly pass on.

None of these are things the owner should execute flawlessly alone. The owner leads the response while everyone in the room shows leadership to fill in the template. The three stances above come together as one within this way of moving.

Turn the Retrospective into Learning: The Blameless Postmortem

Once the incident subsides, what remains at the end is the retrospective. Here too, not blaming and the owner taking responsibility coexist.

The purpose of a postmortem is not a hunt for a culprit but making the system and the process stronger. So that the same incident never happens again, or so that even if it does the damage stays small, you leave permanent countermeasures as action items. The question to ask here isn’t “who made the mistake?” but “why was the state such that this mistake was easy to make?” and “how do we eliminate that state itself?” Was a guardrail missing, was the alert late, was the procedure too dependent on one person? The more you go looking for the cause on the system’s side, the more concrete prevention becomes.

And the one who writes that postmortem may well be, more often than not, the person who caused it. Put the sequence of events into words in your own hand, organize it as a systemic issue, and take ownership of the countermeasures. This isn’t self-punishment; it’s the highest-quality production of learning, by the person with the deepest context. Share the finished postmortem widely with the team, and one incident turns into learning for the whole organization, including people who were never involved. It’s precisely because the owner steps forward under a blameless culture that the retrospective becomes honest, deep, and useful.

Conclusion

I’ve organized the stance and the moves of incident response along three axes.

Don’t blame the fact that it happened: human error is a symptom, not a cause. A blaming culture hides information and slows both recovery and prevention.
The owner takes responsibility and leads the response: what you let go of is responsibility as punishment, not the responsibility to face forward and set things right. The owner, with the deepest context, steps forward.
Move by leadership, not by title: the incident commander is a role, not a rank. Even an individual contributor may lead from the moment they step up.

It’s always better not to cause an incident. But since one will inevitably happen someday, how you move at that moment is what reflects your team’s real ability and culture. Not blaming, the owner not ducking out, moving regardless of title: a team where these three mesh grows a little stronger with every incident.

That’s all from the gemba, thinking about the stance and the moves of incident response, from someone who has watched a good many incidents up close.