What Is a Blameless Post-mortem?
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.
|Regular Post-Mortem||Blameless Post-Mortem|
|You didn’t send the data on time, so I couldn’t create the report.||I didn’t get the data I needed to create the report.|
|James should have ordered the packaging supplies sooner.||The packaging supplies weren’t delivered on time.|
|Bob didn’t proofread the text, so all the documents had to be reprinted.||There was an error in the text so all the documents had to be reprinted.|
|The project manager didn't have contact information for everyone on the shared drive, so I wasn’t able to get in touch with the IT contact when the server went down.||Contact information for everyone wasn’t posted on the shared drive, so I wasn’t able to get in touch with the IT contact when the server went down.|
Why Have a Blameless Post-Mortem?
By eliminating blame in post-mortem meetings, people are more likely to speak up — finger-pointing can cause a lot of people to focus on covering their own actions. This method creates an opportunity for more facts and data to surface and reveal issues that might otherwise have remained hidden.
A blameless environment can be difficult to create and maintain, but due to the overall benefits, it's worth the effort. Going blameless fosters a healthy and trusting culture, both between and within teams. Trust among team members leads to better communication and support as well as a culture of continuous improvement, which creates an environment where people can feel free to take risks and do their best work. In a blameless post-mortem, teams capture better data about the causes of problems. So, processes and policies can be constantly improved as they are tested by new situations that expose flaws or oversights. Read “Continuous Improvement 101 & 201: Models, Processes, and Plans” to learn more.
Simple, powerful project management with Smartsheet. See for yourself.
Smartsheet is a cloud-based platform that allows teams and organizations to plan, manage, and report on projects, helping you move faster and achieve more. See Smartsheet in action.
The Blameless Post-Mortem Process
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.
- 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.
- 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.
- Applaud What Went Right: Highlight successes and focus on what went right with the project (this helps prevent finger pointing).
- 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
- 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.
- 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.
- 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.
- 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.
- Document the Meeting: Once the meeting is over, publish the notes of the discussions and potential solutions.
- 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
You can also view and download other free project post-mortem templates.
Best Practices for a Blameless Post-mortem
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.
A Blameless Post-Mortem Success Story
Ted Wolken is an experienced project manager, who has worked in finance, telecommunication, and healthcare. He currently works in a company with a blameless culture. Wolken gives an example of how it works: “A project team member went on PTO. A member of another team was frustrated because he didn’t know who to reach out to while that project manager was out of the office. He called a couple of people on the project team, but they were unfamiliar with the project in question and couldn’t provide much help.
“The project team and their manager discussed this incident during a subsequent meeting where the emphasis was not on just the project team member being out, but more on the fact that it revealed an overall team gap of serving customers when a particular project manager is out.”
They had a useful discussion about the gap in the process that didn’t cast aspersions on either the project manager who had been on PTO or the rest of the team for not being up to speed on their co-worker’s project. “We now have a process in place where we designate (with their agreement) a fellow PM to act as back up for us when we go on PTO,” says Wolken.
Why Some People Think Blameless Post-Mortems Don’t Work
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.
Blameless Post-Mortem for IT and DevOps
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.
How to Cultivate a Blameless Post-Mortem Culture
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.
What It Means to Investigate Mistakes
Investigating mistakes requires some digging. The first thought may not always be relevant, so you might have to keep looking to uncover the root cause. Here are some tools to help you investigate:
- Focus on the Situational Aspects of Failure: Discerning the environmental factors that contributed to the problem can lead to changes that will prevent the problem in the future.
- Examine Decision-Making around Failure: Look at why decisions were made, not just at the decisions themselves. Remember that a blameless culture assumes people made the best decisions with the information they had at the time.
- Understand How It Happened: Walking through the steps and why they were taken — while filtering out your reactions — will provide a clearer picture of the fix.
By removing the possibility of blame, people are more likely to be honest and want to work toward fixing the problems, instead of worrying about protecting themselves. Creating an environment of psychological safety allows people to focus on finding solutions rather than protecting themselves.
All participants in blameless post-mortems need to keep in mind that they’re not there to reprimand people for mistakes. The reprimanding mindset leads to a cycle of naming, blaming, and shaming, which doesn’t help you solve problems in the future.
Instead, a blameless culture empowers employees to own their stories. When people feel secure providing information about an event, they are also willing to be held accountable. The people who are most familiar with what went wrong are good sources of information about which processes and procedures need to change. For example, a developer who inadvertently pushed code to a production server before it was debugged, which caused a crash, would be a good person to ask what safeguards should be put in place to prevent it from happening again.
A fully blameless culture needs to build the concept into processes beyond the post-mortem. This includes personnel policies, such as hiring and promotions. Grant Aldrich, Founder of OnlineDegree.com, advises, “When hiring, bring on people who are adamant about producing excellent work and always making everything they do better. The flip side of that coin is someone who does not want to improve, who is very sensitive to criticism, and is going to be a problem when you point out things that they're not doing well. You might want to rethink having that person in your organization.”
The way teams gather data during blameless post-mortems can shine a light on how people complete work in an organization. Below are some examples:
- Making incorrect assumptions about the critical path at the beginning of a project may lead to mistakes in planning. These mistakes can be uncovered during a post-mortem by examining those assumptions.
- If there are steps that are always overlooked, you can find them and either remove them from the process (if they are unnecessary) or examine the effect of skipping them.
Streamline Your Blameless Post-Mortem Meetings with Smartsheet for Project Management
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.