"Teaming" Day 5: Final Thoughts

This is the last in our weeklong series of posts on "Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy," by Amy Edmondson.

I will wrap up our week by highlighting some of the best quotes in "Teaming." I've added a couple of editorial comments in [square brackets]:

When facing an uncertain path forward, trying something that fails, then figuring our what works instead, is the very essence of good performance. Great performance, however, is trying something that fails, figuring out what works instead, and telling your colleagues all about it - about both the success and the failure. (pp 29-30)

Despite rhetoric to the contrary, many of us still expect ourselves and others to get things right the first time. We view failures as unacceptable. We give directives to those below, and look for direction from supervisors above. (p 40)

When people frame a task as a "performance situation" they are more risk averse and less willing to persist through obstacles than when the same task is framed as a "learning situation." Not only do people adopting a learning frame persist longer in unfamiliar, challenging tasks, but they ultimately learn more as a result. In addition, people with a performance frame engage in less experimentation and innovation and are less likely to formulate new strategies in difficult situations. Instead they're more likely to fall back on ineffective strategies they have used previously. (p 86)

To learn from mistakes and missteps, organizations must employ new and better ways to go beyond lessons that are superficial (procedures weren't followed) or self-serving (the market just wasn't ready for our great new product). This requires jettisoning old cultural beliefs and stereotypical notions of success and replacing them with a new paradigm that recognizes that some failures are inevitable in today's complex work organizations and that successful organizations will be those that catch, correct, and learn from failures quickly. (p 150)

People tend to be more comfortable considering evidence that supports what they believe, denying responsibility for failures, and attributing problems to others. (p 155)

The difference between failures that are truly blameworthy and those that are simply treated as blameworthy reveals a gap between logic and practice. [I would add that it reveals a gap between a person's vision, or what she hopes to be true, and raw reality.] (p 160)

Engineers' or scientists' intuition can be telling them for weeks that a project has fatal flaws, but making the formal decision to call it a failure may be delayed for months. Considerable resources are saved when such projects are stopped in a timely way and people are freed up to explore the next potential innovation. [I've experienced this in business-to-business sales environments. The declaration of a loss can take weeks or months, chewing up resources all the while.] (p 174)

Most of us would prefer to have reliable solutions to the problems we face, and we certainly like to feel that we are good at what we do. But execution-as-learning requires us to accept our individual and collective fallibility. (p 225)

You can find all our posts related to "Teaming" here.

"Teaming" Day 4: Varying reasons for failure

This is the fourth in our weeklong series of posts on "Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy," by Amy Edmondson.

Blame and fault-finding is as old as humanity. We learn this early in life: "It wasn't my fault. They did it!" For mistakes in the workplace, the context of the situation matters a great deal when deciding whether an unexpected result is, in Amy Edmondson's words, "praiseworthy" or "blameworthy." She describes a spectrum of situations that explain failures, spanning from ... to ... Here's the list of reasons for failure, from most blameworthy to highly praiseworthy. Items in quotes are taken from Edmondson's description.

Deviance - failure due to not following prescribed procedures is a cause for reprimand, discipline, or firing.

Inattention - "inadvertent deviation" from specifications. This sometimes happens to me when I forget to attend a conference call I'd committed to. Blameworthy!

Lack of Ability - failure due to lack of skills, training, etc. Blame here rests partially on the worker, and partially on management, who need to assess and verify ability on an ongoing basis.

Task Challenge - failure due to the inherent difficulty of a task. Failing to get a hit in baseball seven out of ten times is simply a facet of the game.

Process Complexity - a breakdown in a system due to "novel interactions." Not blameworthy, in fact workers need to be encouraged to report these types of failures, so the novel interactions can be diagnosed and training developed to overcome the new obstacle.

Uncertainty - failure due to circumstances unforeseen at the time an action was taken. This type of failure happens often when there is a long lag between action and outcome. For example, locking in the price of next year's natural gas supply, and then seeing prices fall dramatically. Failures due to uncertainty are reason to evaluate how decisions are made and whether steps can be taken to manage uncertainty or its consequences. (People who succeed in an uncertain environment get undue credit. This discussion by Daniel Kahneman on stock-pickers addresses this point.)

Hypothesis Testing - "an experiment conducted to prove that an idea or a design will succeed or fail." Whether the hypothesis is proven or disproven, you've gained valuable information as a basis for higher-stakes decisions.

Exploratory Testing - an attempt to probe and understand a novel area. Many of these attempts will fail, but even a small percentage of successes will yield large rewards. Praiseworthy!

This quote was cited in an earlier post, but it's worth repeating when talking about how to assess whether someone should be blamed or praised for a failure:

When I ask executives to...estimate what percentage of failures in their organizations are caused by blameworthy events, the answers usually come back between 2 and 5 percent. But when I then ask what percentage of failures are treated as if caused by blameworthy events, after a pause or laugh, their responses often yield a much higher number in the 70-90 percent range.

You can find all our posts related to "Teaming" here.

"Teaming" Day 3: Three Types of Failure

This is our third post on Amy Edmondson's "Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy."

Chapter 5 is called "Failing Better to Succeed Faster" and it's full of wonderful insights about learning from mistakes. Amy defines three types of failure so well and so crisply that I won't paraphrase the definitions, but will quote them directly:

• Preventable Failures: process deviations in well-understood domains, usually caused by behavior, skill or support deficits. 

• Complex Failures: process or system breakdowns that arise due to inherent uncertainty and may or may not be identified in time to prevent consequential accidents.

• Intelligent Failures: the unsuccessful trials that occur as part of thoughtful experiments and provide valuable new information or data.

Of these three, complex may be the most difficult to manage. In routine environments, preventable failures should be easy to spot and to diagnose. In innovative environments, tolerance for failure is built in. In complex environments, however, deviation from expectations could be a "near miss" that could lead to a "consequential accident." It could be valuable information about a change in the environment. It might be an anomaly, due to events out of your control. How do you learn and improve in complex operations?

When reviewing these types of failures, first, don't blame individuals. Second, don't jump to the first explanation that springs to mind. [Quote from "Teaming": "The primary danger in failure analysis is that people tend to leap prematurely to conclusions, unless the analysis emphasizes a careful consideration of all possible causes and effects."] Finally, take ownership of the failure by looking at things you and your team can do differently when confronted with a similar situation in the future.

Here's a real example. I was involved on a sales campaign with a large customer. We crafted a very innovative solution for them. The team at the customer was very confident in our capabilities and had justified this project. We had negotiated price, and contractual points. Finally, only one more signature was needed by a customer executive.

He did not sign.

We who had worked on the opportunity were crestfallen. We had done everything we could to win this deal, and had nothing to show for it. Our first reaction was to chalk the failure up to bad luck, or fate, or even an evil, conniving customer executive plotting to screw us.

But as we reflected on the situation, it became clear that we had not done everything we could have. We had not fully understood who at the customer could make a commitment for this business. And we hadn't gotten in contact with that person to see if this project helped him with his objectives, or whether there were other projects he felt more passionate about. So, the learning was this: the next time we engaged on a sales campaign, we would, as early as possible, understand who would sign the contract and assess how to enlist that person's support. And if we couldn't enlist that support, consider stopping the pursuit.

You can find all our posts related to "Teaming" here.

"Teaming" Day 2 - The Process Knowledge Spectrum

This is another post on "Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy," by Amy Edmondson.

One concept in the book is the "Process Knowledge Spectrum." This spectrum describes three broad types of business operations that require different approaches to learning and tolerances for mistakes. It runs from Routine Operations through Complex Operations and to Innovative Operations on the other pole.

Routine Operations are business processes that are well-defined and for which conformance to specification is crucial. A McDonald's hamburger is made the same way worldwide. Mistakes in this environment are unexpected and due to inability or unwillingness to following procedure. Learning in this environment involves observing and noting small changes that can improve outcomes. The classic learning environment for Routine Operations is the Toyota Production System.

Complex Operations happen over and over again, but never exactly the same way twice. For example, customer service interactions or sales engagements. The people involved are different, the context has changed, and the environment has evolved. So the idea of "best practice" as used in routine operations is not applicable. (This hasn't stopped many organizations from trying unsuccessfully to make it so, but that's a subject for another post.) Mistakes in this complex operations often indicate, as Amy points out, system breakdowns. They can also indicate weak signals of change in the environment. They are rarely the fault of an individual, and treating them as such has a very negative side effect - it promotes hiding of mistakes, and, therefore, hiding the system breakdown or weak signal that is vital for learning and improvement.

Examples of Innovative Operations are development of a brand-new product or starting up a new business venture. In these operations, much is unknown, and only by developing hypotheses, probing and experimenting can learning occur. Innovators are often unperturbed by mistakes, and in fact welcome them. (Consider this quote from a famous innovator, Thomas Edison: "Negative results are just what I want. They’re just as valuable to me as positive results. I can never find the thing that does the job best until I find the ones that don’t.")

Uncertainty increases along the Process Knowledge Spectrum, from low uncertainty in Routine Operations to very high uncertainty in Innovative Operations. That amount of uncertainty indicates the usefulness of standard practice and the predictability of outcomes. In innovative projects, outcomes are highly unpredictable, experimentation is important and tolerance for failure needs to be high.

This spectrum is very useful in analyzing mistakes. If you are involved in a project in which the result is not what you expect, think about which of the above definitions fits the project best. Is it routine, complex or innovative? Knowing this will help you understand how to deal with the mistake and how to manage for mistakes going forward.

You can find all our posts related to "Teaming" here.

Amy Edmondson's "Teaming"

I'm so delighted that Amy Edmondson has published "Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy," a summation of her 20-year study of organizational learning & performance. Amy's ideas provide one of the pillars for this site and have helped shape my thoughts about perfectionism, leadership and teamwork.

I'm equally delighted that the book is utterly worthy of the expectations I had for it. Impeccably organized and crisply written, it sets out Amy's arguments so cleanly that you forget how radical her ideas are. At least, until you read something like this:

When I ask executives to...estimate what percentage of failures in their organizations are caused by blameworthy events, the answers usually come back between 2 and 5 percent. But when I then ask what percentage of failures are treated as if caused by blameworthy events, after a pause or laugh, their responses often yield a much higher number in the 70-90 percent range.

If you are looking for an introduction to the ideas we're exploring on The Mistake Bank, please read Chapter 5, "Failing Better to Learn Faster," several times. And then all the other chapters.

We'll spend the rest of the week sharing a few of the countless valuable nuggets from "Teaming." Expect it to be on our year-end "best of" list.

A full collection of posts related to Amy Edmondson's work can be found here.