Essential Blameless PostMortem Guide - How to Run, Setting the Culture, Being Blame Aware

A blameless post-mortem is a post-project meeting in which you review problems to learn why they happened and prevent them from reoccurring. In this type of meeting, there is no finger-pointing. 

There are a few different types of blameless post-mortems. The first occurs after a DevOps or IT incident (such as a website crashing or data corruption). The second type occurs at project completion o (or, if it’s a long or complex project, at regular intervals throughout). 

In many ways, a blameless post-mortem is the same as a regular post-mortem meeting. The difference is that the blameless version investigates problems and incidents without making accusations or blaming any particular person or team. A blameless mindset assumes that all parties were doing the best they could with the information that they had at the time. 

Blameless post-mortems don’t cover remediation of mistakes or errors in execution. Rather, they look backward to look forward and try to prevent issues from recurring. Remediation should be handled by other means (e.g., process improvements or personnel improvement plans).

Language is essential for keeping a meeting blameless. Here are some examples of blameless statements compared to ones that point fingers.

If you need to learn the basics of project post-mortem meetings and what questions to ask, please refer to this article about business post-mortems.

The blameless post-mortem process is similar to the standard post-mortem process, but differs in the way it discusses problems. Conversation focuses on gaps in processes and procedures, rather than the people involved in the process. 

Throughout the meeting, keep an eye out for hindsight bias and negativity bias. With that in mind, use the steps below to run a blameless post-mortem meeting. A couple steps (noted) only apply to DevOps or IT incident reviews.

1. Set the Stage Prior to the Meeting: Share an agenda that includes all items to review, so you don’t blindside any participants. Inform participants early and often that the post-mortem meeting is blameless. 
2. Start the Post-Mortem on the Right Note: Reiterate at the beginning of the meeting that the meeting isn’t about the blame game — and repeat as necessary. Use a little humor to set a pleasant tone during the discussion.
3. Applaud What Went Right: Highlight successes and focus on what went right with the project (this helps prevent finger pointing). 
4. Focus on the Steps in an Incident: If your actions contributed to an error or incident, concentrate on the relevant systems and processes, not on the people involved. You should be able to explain the following:
   • Which actions were taken at which times
   • The observed effects of those actions
   • Your expectations of what was going to happen
   • Any relevant assumptions that you made
   • Your understanding of the timeline 
5. Hear From the Correct People: During this discussion, for IT/devOps issues, the group should hear from the person or persons who introduced, identified, responded to, debugged or resolved the issue, as well as anyone else who is interested in it.
6. Dig Deeper with the 5 Whys: The technique known as the 5 Whys can help get to the bottom of an issue. The process is as simple as it sounds: Ask why five times to identify the root cause and expose any corrective actions. You can use this 5 Whys template to record the answers and the corrective action. For example, if a construction project deadline was missed, the five why chain might look like this:
   • Why was the deadline missed? A form was not filed with the county on time. 
   • Why was the form not filed? It was not signed by all required parties. 
   • Why were the forms not signed? One of the VPs that needed to sign was on vacation the week the form was due. 
   • Why did the VP leave without signing the forms? The team responsible for gathering signatures didn’t know the VP’s vacation schedule. 
   • Why didn’t the team responsible not know the VP would be on vacation? Vacation schedules are not tracked on the project plan. Therefore, we should add vacation schedules to the project plan.
      
     
     
     
     For IT/devOps issues, you’ll want to collect important metrics, including mean time to resolution (MTTR) and mean time to discovery (MTTD). These two figures tell you how long it takes to implement a solution (whether that’s a software patch or installing a replacement component) and how long it took to discover the problem. Knowing these metrics may help lead to ways to decrease them for the next outage or intrusion.
7. Identify Potential Solutions: Once you’ve identified the causes of potential issues (and all without blaming anyone), brainstorm how to avoid the problems going forward. Make a list of potential improvements you can make to processes and procedures.
8. Assign Changes to Team Members: Get commitments from team members to commit to making changes that can drive the improvements you’ve identified. Once they make a change, share that progress with the team and stakeholders.
9. Document the Meeting: Once the meeting is over, publish the notes of the discussions and potential solutions.
10. Circle Back to Track Results: After the meeting, follow up with the team and key stakeholders to ensure that they’re implementing changes and that troubled processes are moving smoothly. 

Use this free template to record the results of blameless post-mortem meetings, document the decisions made, and record the responsible party for each action item. You can also use it to track any communication that stems from the meeting. 

Download Blameless Post-Mortem Meeting Notes Template

Excel | Word |  PDF  | Smartsheet

You can also view and download other free project post-mortem templates.

Many well-known companies use the blameless post-mortem model, including Etsy, Google, Atlassian, and Hootsuite. Maintaining the blameless mindset can be challenging, but the resulting information makes it worthwhile. Here are some tips and techniques to help support blamelessness:

• Make sure everyone provides constructive criticism rather than casting blame.
• Review notes and findings from post-mortem meetings to ensure they are producing results that drive process improvements.
• Visibly praise or reward participants for following the blameless format.
• Encourage people to be honest and accept that failure will always occur.
• Build a timeline of the project or incident, and use this format to gather and share information.
   
  
• Encourage the use of “I” statements rather than “you” statements. Paula Cizek, Chief Research Officer at nobl.io, an organizational design firm, suggests, “If people do start falling into the habit of blaming others, then the facilitator can ask them to use ‘I’ as opposed to ‘you’ statements and to be specific about the behavior. For example, they should say, ‘I feel frustrated that we received the contract late,’ instead of, ‘Your team never turns things in on time.’” 
• The people upstairs need to support a blameless culture, so get buy-in from the C-suite.
• Collaborate with other teams and your colleagues to promote and spread the benefits of running a blameless post-mortem.
• Studies show that helpful teams are better at resolving issues, so support those you work with — collaboration leads to improvement. 
• If someone feels like they are receiving blame, get back on track by restating the goal of blamelessness. Explain the intention behind a comment and how that compares to its delivery. This tactic can help reestablish shared purpose and respect.
• Consider diverse perspectives. Team members will have different backgrounds, experiences, and work styles. These differences are beneficial for providing unique views of the causes and effects of issues. They may see or value things that you don’t.
• Review the reasons that a reasonable, rational, and decent person would take a particular course of action in a particular situation. Try to see what they saw and feel what they felt.  
• A meeting leader should model behaviors they want others to exhibit. For example, if a leader’s actions contributed to a success or issue, they should participate in the discussion. 
• If the meeting veers into blaming or finger-pointing, the meeting leader should steer the meeting back toward blamelessness. If that doesn’t work, they should consider pausing or ending the meeting, or asking problematic attendees to leave the room.

Jordan Kentris is a designer who has worked with major brands, and has led many post-mortem meetings. He says, “When a post-mortem is happening and you're starting to see some of those things happen, take a step back and ask the team to take a breath. Sometimes you have to assess, take a pause on that post-mortem, and pull those members aside.”

Check out some free downloadable post-mortem templates for running both IT and project post-mortems.

Some studies show that assigning blame may be innate to the human brain and culture. For that reason, some believe that trying to create a blameless culture is futile, and that people will end up not saying what they really think. A proposed alternative is being blame-aware, which some see as a more realistic mindset.

In a blame-aware environment, team members know that they will either blame or be blamed. However, they have the same goal as blamelessness, which is to find the causes of issues and prevent them from reoccurring. Therefore, people in a blame-aware environment care more about improvement than blame.

A DevOps or IT post-mortem occurs after an incident, like a website crash, data corruption, or security breach. Like project post-mortems, having a blameless culture helps uncover the cause of a problem.

When evaluating an incident, DevOps or IT teams may rely on second stories. The first story is generally true on a surface level, but points to human error as the cause of a problem, rather than looking deeper. A second story will look at what allowed that human error to have a negative effect and point at ways to remove that vulnerability. If a database gets corrupted and some data is lost, a first story might be that the administrator didn’t perform backups often enough. A second story might ask why the admin has to manually trigger a backup and recommend automating the process.

A common feature of blameless DevOps/IT post-mortems is that it expects engineers and developers to own their stories. This means they are the best resources for finding the root causes of incidents they are involved in because they are familiar with what went wrong, and will evangelize the fix to the rest of the organization, as well as any remediation that arises from the incident. 

You can download free IT incident post-mortem templates to plan and execute your incident post-mortem meetings.

Creating and fostering a blameless culture requires constant reinforcement, both before and during post-mortem meetings. You’ll also need to evangelize a blameless mindset throughout the organization — doing so starts when you bring people into the company. 

The idea of a blameless culture originated in the aviation and healthcare industries. In both of those areas, mistakes can lead to fatalities. Therefore, there is a great need to dig into a problem and find and fix the root cause, and it’s critical to create a blameless culture and processes that support it. Having this type of culture allows people to see problems as opportunities to fix systems and processes, which ultimately creates a safer organization. The environment also balances safety and accountability by focusing on the situational aspects and decision-making processes behind an issue, rather than on calling out an individual. 

For example, if a toaster manufacturer is trying to find out why some of their toasters are burning out, they may discover that some of the heating elements for a lower-power toaster were installed in a more powerful model. If they just disciplined the employee who distributes the parts, they probably won't discover that the elements of the two separate toasters look the same. Identifying that issues means they can work with their supplier to differentiate the two parts.

A blameless culture encourages learning. By framing issues and incidents as opportunities to improve rather than as the fault of a person or team, an organization that cultivates blamelessness allows people to focus on making things better rather than on protecting themselves or shifting responsibility. As an example, a company that doesn’t support blamelessness might fire someone responsible for issuing ID cards when they gave an employee access permissions they shouldn't have, which led to a data breach. A blameless organization, by contrast, would learn that when employees change positions, the job data in the database isn’t updated in a timely manner. 

One hurdle to a blameless culture is hindsight bias, which refers to people’s inclination to overstate the likeliness of an event that has already happened and conversely, understate (or even forget about) the factors that actually made it unlikely.  For example, say a manager decides to take the small chance that a critical delivery won’t arrive on time. When the delivery is late, others may say it was inevitable and the manager was negligent. In a blameless environment, hindsight bias can make people think that the problem was inevitable, and therefore, make them less likely to look for a root cause and more likely to point fingers. Instead, people should focus on the situation beforehand in order to prevent the problem from recurring.

Another hurdle is the fundamental attribution error, which is especially hard to overcome. A fundamental attribution error is the tendency of people to assign another person’s character as the cause of a problem, rather than environmental or situational factors. Conversely, they give themselves the benefit of the doubt. For example, if a co-worker didn’t post a report on time, the first thought might be that person is bad at their job or disorganized, rather than thinking they couldn’t access the necessary data due to a server crash, or that they were late to work due to bad traffic. During a post-mortem, applying this mindset can prevent revealing the real cause of a problem. It’s not easy to escape this type of thinking, but becoming aware of it is the first step. Then, when it creeps into your thinking, you can try to put those judgments aside and seek out situational causes for problems. 

A third hurdle to be aware of is negativity bias, which is the tendency for people to give greater weight to negative occurrences than to positive ones. Negative things will have more impact and be remembered better than positive things. This notion can easily creep into discussions and thoughts. If you’re not aware of negativity bias, it can have an unfavorable impact on the blameless culture.

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.