How did error management develop in aviation?

For a long time, the captain had a god-like status in the cockpit. Rather than questioning a captain about an apparent error, a co-pilot might assume that the captain knew something they didn’t. There was a big transition after a minor crisis turned into a strange, tragic accident.

In 1978, United Flight 173 was preparing to land in Portland. There was a problem with the landing gear. They aborted the landing and circled as they tried to resolve the issue. They were going through checklists and communicating with the ground while circling and circling. Over time, the captain lost track of the fuel situation. The first emergency was overtaken by a second that was much more problematic. The co-pilot kept asking the flight engineer for fuel levels and the flight engineer responded, but they never said, “We’re running out of fuel and need to get on the ground.” 

Ultimately, the plane crashed, killing 10 people. That accident led to the development of an error management system for aviation—which prioritizes open communication and avoids blaming in order to correct errors as quickly as possible—but even then it took years and another accident before it was fully accepted.

In 1989, United Flight 232 from Denver to Chicago had an engine explosion. It was a DC-10 which is a three-engine plane so if one engine blows, it flies perfectly well with the two others. But, in this case, the exploding engine severed the hydraulic lines, so the pilots effectively had no control of the plane.

It was one of the most intense communication incidents ever recorded. In the most extreme moments they were having an interaction almost every second—some talking with the outside, some coordinating within the cockpit. They were able to make minor adjustments by altering the thrust from the two remaining engines and managed a crash-landing. Of 296 people on the flight, 184 survived.

It was really a tremendous piece of airmanship, but the crew said, again and again, they got the results they did not because of superior flying skills but by working as a team and communicating openly.

Until that incident, the acceptance rates for the error management concept was hovering around 70%. After this accident, which was widely publicized among the pilot community, the acceptance rate jumped over 90%, and stayed there.

Q: How does this apply to communication in the corporate setting?

Information about a success moves very easily. It’s negative information that doesn’t move as well. I surveyed more than 300 executives about how they communicate negative information within their organization. It could be something bad you have done and need to communicate, or something you observe a colleague doing and have to correct.

Most executives said they do address the issue, but they always prefer to do it in a confidential setting. On the surface, that seems considerate because it protects people, but the main reason we feel the need to do it in confidential settings is that errors are associated with sloppy work, negligence, and those sorts of problematic qualities. Everybody expects you to perform perfectly, and if you make an error you don’t care enough. But if you look at the reasons why we make errors, in a lot of cases, it’s stress, fatigue, or distraction.

In business, we’d like to be 100% perfect, but that’s not possible. In complex environments, you will always have errors. Error prevention is unrealistic. What you want to do is manage errors well. If mistakes are corrected in a confidential setting, you don’t have an atmosphere or culture that allows for open communication.

Q: How does the error management system work?

The main focus of error management is capturing things that are going wrong and correcting them.

In flying, usually it’s not one error that leads to a crash but a series of uncorrected errors that ultimately ends in an accident. But we’re never sure whether we’ve captured the first error very early while it’s basically a non-issue or whether are we are three, four, five errors along a chain that is about to break and trigger a crash. For that reason, it’s important to correct each error as soon as possible.

When the focus is on preventing errors that quickly shifts to blaming. But if you don’t think about blaming, you don’t need the confidential setting to correct it. Putting the focus on simply correcting errors when they appear requires a big cultural transition.

To make the transition, you really need to protect people whenever they are reporting something. It could be their own fault; it could also be something a colleague has done, but it should never be something where you think about punishing them.

Cultural shift comes by always saying, “It’s great that you’ve highlighted this. It gives us an opportunity to learn.” That is a very different mindset for organizations. Creating an open error culture doesn’t happen in a one-time training event. It’s an ongoing thing.

Q: Without the fear of blame, do standards drop?

That implies a low view of people. Amy Edmondson from Harvard has done work on psychological safety. In an environment where it’s safe to speak up and it’s ok to make errors, people are more responsible. It is a bigger issue if people are over-cautious because whenever they do something wrong, they get punished.

And if you have errors coming out of negligence or because people are not motivated, I would say error management is probably the last thing that you should worry about.

In business, it may not be lives at stake, but an error, in a lot of cases, means extra work, so you’re affected, your team might be affected. That’s not something that people take lightly.

If you create a culture of open communication where people are taken seriously, their input is valued, and there is learning from experience, then you shouldn’t worry about standards dropping.

Q: Is correcting an error just raising a question? 

That would be the easiest way to start.

If you ask employees why they are not speaking up, the strongest motivation is because they are not sure there is an error. Sometimes things are muddy. Or they might think, “I don’t think this figure can be right,” but the necessary document is not at hand, so they don’t raise the question.

In hierarchies, people tend to assume those with more seniority have more information. But that’s not the right attitude because the more senior person might simply have overlooked something. So the best way to address it is to ask, “Can you explain that a little bit?”

In practice, people don’t want to reveal that they’re not fully informed or appear stupid in front of their colleagues. Those concerns prevent them from even asking questions.

Q: What’s the role of leaders?

We talk about authority gradients in organizations. What we’ve learned in the cockpit is to make sure the gradient isn’t too steep. You need to make sure it’s possible for individuals to question the senior leader while still having someone who can make the ultimate decision.

In flight crews, the most effective captains are not throwing out commands with the hope that any errors would be corrected by the co-pilots, but rather they ask neutral questions, “I see something is not right. Why are we having a problem with that?” Then the copilot, because he does not know in which direction the captain is leaning, has to give an unbiased view.

Transferring it to a corporate environment, it is more effective for a CEO or senior leader, instead of always talking in meetings, to ask people for their views. Once they have contributed, the leader could set the different views in context with his or her own assumptions and make a conclusion.

My belief is that it would be it would be great if senior managers, even the CEO, would talk openly about dumb things that they’ve done. Not to say they’re dumb people, but to say there are circumstances where each of us has been totally wrong. That openness would allow reflection from an organizational perspective.

Q: Correcting errors simply by speaking up is one thing; what about situations where it’s hard to know what actually went wrong?

This is somewhere else blame comes into play. It’s very handy to pick someone, say, “You did something wrong,” punish the person, and think, “That’s it. Lesson learned.” 

After a plane crashes, investigators gather facts. It almost always takes at least 10 to 12 months until they have a preliminary accident report even though they’re generally quite fast at recovering flight data recorders and they have a lot of resources. It takes that time because they don’t jump to premature conclusions. It’s an effective approach, and is something that should be done in corporate life at least for serious situations.

You don’t learn from experience. You learn from reflecting and analyzing. The military is quite good at it. They call it an after-action review. Pilots call it a debrief. When an organization creates a habit of looking at what has happened, it becomes second nature to think about why things developed the way they did. Then you’re analyzing instead of blaming one individual as the problem.

Wherever you have a company that focuses on innovation, they should also think about this process because a project that isn’t developing as expected may not be a failure. It may simply be that an assumption didn’t prove right. Now that you know it’s wrong, you try again.