Introduction

When a system incident occurs, most organizations hold a review once service is restored. They organize the sequence of events, analyze the cause, and consider measures to prevent recurrence. This activity, often called a “postmortem” or “incident review,” is one of the important practices in IT service management.

But in your organization, is that postmortem truly working?

You prepare the materials every time, hold the meeting, and decide on preventive measures. And yet similar incidents keep happening. In the review, someone says, “We talked about the same thing last time, didn’t we?” Before you know it, holding the postmortem has become the goal in itself, and no one feels it is actually leading to improvement. Does that sound familiar?

There is one more thing worth noticing.

In these reviews, a great deal of time goes into “What was the cause?” and “How can we prevent the same incident?” Yet the question “Was our incident response itself appropriate?” comes up surprisingly little.

In other words, many organizations are eager about preventing recurrence but do not spend enough time improving the incident response itself.

I believe these two points are why postmortems tend to stop working. In this article, I want to think about the structure that makes postmortems hollow, and what they should really look like.

What Is the Real Purpose of a Postmortem?

First, let us confirm the purpose of a postmortem. “To clarify the cause and root cause of the incident.” “To build recurrence prevention based on the root cause.” Many people would answer this way. Of course, that matters. But it is not enough on its own.

Clarifying the cause of an incident explains something that already happened. A postmortem, however, is also an activity for making future incident response better. This is the part that easily gets buried. So a postmortem has two purposes.

One is to define recurrence prevention. Depending on the case, this may mean fixing a system defect, revisiting a configuration, or strengthening monitoring. Improvements to development and operational processes may also come into view. These are improvements aimed at reducing incidents themselves.

For example, suppose a service outage was caused by a database configuration error. In the postmortem, measures such as “add a configuration review” or “introduce an automated check” are decided. These are necessary improvements in their own right.

The other purpose is to improve the incident response itself. Was the initial judgment appropriate? Was information shared well enough? Was the timing of escalation right? Was the information needed for decisions actually in place? These are improvements that help the organization respond better the next time.

During an incident response, don’t situations like these happen? It takes too long to declare a major incident, the first notice to users is delayed, contact to related departments is duplicated, or the recovery meeting becomes tangled and no one knows who makes the final call. If these situations exist, then what you need is not only recurrence prevention. It is improvement of the incident response itself.

The Postmortem You Are Wasting

Yet in many postmortems, much of the time goes to “What was the cause?” and “How could it have been prevented?” while questions such as “Why was that judgment made?”, “Was the information behind that judgment enough?”, and “If the same situation arose again, how would we decide next time?” are not explored enough. As a result, recurrence prevention happens, but the maturity of the incident response does not change.

Looking back at the past and building recurrence prevention are important. But activities that improve future incident response deserve just as much attention.

Every incident is different. The causes differ too. Yet the work of incident response has common elements: organizing the situation, grasping the impact, gathering information, making judgments based on criteria, internal communication, and external communication. These actions are carried out every time, regardless of the incident and regardless of the root cause.

In other words, incident response holds knowledge that can be reused. It is a waste when that kind of knowledge is not put into words in the postmortem.

A Review of “Judgment” Based on Facts, Not a Hunt for Culprits

One typical reason postmortems become hollow is the “hunt for a culprit.” Of course, no one starts a meeting intending to look for someone to blame. But sometimes questions like these pile up: “Why was the escalation late?” “Why did you make this change?” “Why did you miss this log?”

At first glance these look like fact-checking, but the person receiving them may feel their own judgment is being blamed. When that happens, people unconsciously move to protect themselves: “We had no information at the time.” “There was no precedent.” “We followed the procedure.” As these explanations increase, the meeting becomes a place of defense rather than a place of learning.

What we really want to know is not “who was at fault.” What we should learn is “why that judgment was reasonable at that moment.” Certainly, judgments can be wrong. But a judgment is reached for reasons: information was lacking, the necessary action was not recognized, or the right people to rely on were not known. If so, the real question is how we can make sound judgments going forward.

Incident response is a continuous series of decisions under uncertainty. Complete information is almost never available. A judgment that looks wrong in hindsight may have been the most reasonable one at the time.

Precisely because decisions must be made with limited information, we need to look back at the information and the criteria that supported those judgments. What deserves evaluation is not only the outcome but the process of judgment. Unless the organization can learn, the maturity of its incident response will not rise.

The Real Reason Learning Does Not Happen

So why does learning not happen?

Some readers may feel it is because of a lack of psychological safety. Lately we hear this explanation more often. An atmosphere where people can speak up safely is certainly important. But that alone is not enough.

Even in a meeting where everyone can speak freely, if it is not clear “what we are discussing today and what we want to learn,” the discussion ends as a mere sharing of impressions.

For example, “Let’s improve communication,” “Let’s share more information,” “Let’s be thorough in our checks.” Conclusions like these come out of any incident. But the next incident produces the same conclusion, because the target of improvement is vague.

A learning organization does not stop at an abstract conclusion like “communication was poor.” Concretely, it breaks the judgment down into its components: “Which judgment lacked the information it needed?” “Were the criteria for severity assessment appropriate?” “Who should have made the decision, and at what timing?”

Rather than only digging into the incident in front of you, and rather than only defining recurrence prevention, it matters to raise your line of sight one level and look back at the incident response process itself.

What Makes a Learning Organization Different

In organizations where incident response is mature, the questions in the postmortem are different.

They do not stop at “What was the cause?” They dig deeper: “What hypothesis did we form first?” “What information was that hypothesis based on?” “Could we not have considered another option?” “Even with only the same information, could we have made a different judgment?”

By layering these questions, individual experience turns into organizational knowledge. The tacit knowledge a veteran holds is first put into words through this kind of dialogue. As a result, “a response only that person could pull off” turns into “a response the organization can reproduce.”

Here, we sometimes hear, “Our organization has no culture of reflection.” Culture certainly matters.

But I believe there is something to consider before culture: building it into the system.

What do we review, and for what purpose? Who takes part? What questions do we ask? What learning do we keep? Who follows up on improvements? Only when this kind of system is designed does culture begin to grow. Trying to change culture alone will not change concrete behavior.

Meanwhile, as the system takes shape and the questions become sharper, people’s dialogue and behavior begin to change little by little, and that accumulation becomes the organization’s culture.

A Good Postmortem Leaves “Learning,” Not Just “Fixes”

At the end of a postmortem, in many cases a list of “recurrence prevention measures” lines up. But what matters even more is what the organization learned.

Suppose the improvement measure was “add a monitoring item.” That may well be effective. But if the learning behind it is “in a major incident, the information for judging user impact tends to be lacking,” then not only monitoring but also operational procedures, escalation criteria, and the way status is reported all become targets for improvement.

For a good postmortem, I recommend consciously separating recurrence prevention from incident response improvement.

Example steps for recurrence prevention
Why did the incident occur?
How can we prevent it from happening again?
Example steps for incident response improvement
Was the initial judgment appropriate?
Was situational awareness shared?
Were roles clearly divided?
Was information to users appropriate?
Did the meeting run well?

With only the former, you can become “an organization with fewer incidents,” but not “an organization strong at incidents.” Only when you improve the latter as well do you become an organization that can respond calmly even to the unknown.

What I Hope You Will Try in Your Next Postmortem

If you have a chance to run a postmortem next time, please do not stop at root-cause-based recurrence prevention. Remember to also ask, “What did we learn?” and “Was there any problem in the incident response itself?” And before you think about prevention measures, please discuss “Which judgment was difficult at that moment?” and “Was the information, and were the criteria, for that judgment sufficient?”

Incidents, ideally, should not happen at all. But an organization that cannot learn from incidents repeats the same failures. An organization that can turn incidents into learning opportunities turns each experience into organizational strength.

A postmortem is not a place to pass judgment on the past. It is a place where the organization keeps learning in order to make future incident response better. Simply holding that perspective changes the conversation in the next review.

And perhaps the accumulation of those small changes is what turns incident response from “an activity that relies on experience” into “an activity where the organization keeps growing.”