Skip to Content
Author's profile photo Marilyn Pratt

How Blame Impacts Failure and Impedes Innovation

In preparation for our SAPTechEd failfaire, and during our thinking of Why Owning Failure Makes Good Business Sense and while defining a new vocabulary for innovation, co-lead and co-conspirator Marcia Walker  introduced me to the article titled “Moving From Blame To Accountability” (Systems Thinker , Pegasus Communications 1997). 

In it, author Marilyn Paul describes a common scenario in work environments: namely, that when something goes wrong and errors surface, blaming seems to be the natural reflex.  But, as Paul maintains, “Where there is blame, there is no learning”.  She goes on to say when true analysis of and accountability for a situation, a product, or a deadline are absent and in their stead a fear of blame and fault are present, there are often cover-ups, cosmetic fixes, informational blackouts or institutional denials of less-than-optimal outcomes.  These responses lead to the producing of more errors and failures.  Thus, ill-treated failure, often even camouflaged as success failure, creates more failures in its wake.  From a human and personal perspective where there is fault and blame, we tend to fear being the failure rather than properly analyzing and addressing an undesired outcome.

Paul’s contention is that finger-pointing engenders fear which blocks the ability to problem-solve effectively and fear inhibits risk-taking which, in turn, inhibits innovating.  This creates a “cycle of blame” as “blame is a fix that actually diverts the blamers’ attention away from long-term inter-personal or structural solutions to problems” and “the lack of long-term solutions reinforces the need for additional quick fixes”. (Systems Thinker, Pegasus Communications 1997 Marilyn Paul)

Clearly, working in an atmosphere of fault and blame is antithetical to job retention, good communication and job satisfaction. Important in any industry and perhaps especially important for those in the high-tech industry, is an understanding, that blame cycles are counter-productive to innovation. 

In a conversation around failure therefore, organizationally or personally, it would be beneficial to explore how we can define a language of accountability.  Any discussion of defining a new vocabulary that moves from blame to accountability should start with a simple awareness of language constructs.  We can explore those used in individual conversations and assessments, as well as the vocabulary that is used more globally in an organizational analysis and review.   These reviews may be called, as I’ve just learned from Chris Paine  (and thanks to you @wombling found an excellent resource called Agile Retrospective Resource Wiki),  Retrospectives or they can be viewed as Failure Analysis.  In this excellent discourse by Aino Corry, Retrospectives, Who Needs Them, Anyway? 

During our FAILfaire we will attempt to recognize and explore the use of language constructs.   We will map conversations that unintentionally propagate failure as contrasted to those that can produce more favorable outcomes. 

Some of the examples that Marcia provided in “breaking the mental models” of our blame vs. accountability speech habits were in shifting from the use of “you” statements  to “I” and “we” statements or moving from the word “but” to the word “and”.

Jeanne Carboni offered the idea of transforming “criticizing” to “coaching”.

In the article “Moving From Blame To Accountability” cited above, Paul suggests distinctions in analysis, focus, intent and outcomes for accountability conversations with examples such as shifting from “who did that?” and “what you did was wrong” to “what happened here?”. Other examples included “It’s your fault” (which of course can be much more an inference) vs. “what do we need to do to get the results we want”.

While it may sound a bit simplistic that a language change can create an organizational change, consider this: the words we attach to our experience become our experience.    If we start from the premise that failure is simply an instance in which “we didn’t get what we hoped and planned for” we will be less likely to collapse our fear of being a failure with a fail instance.  We will need to learn to distinguish attributed meaning and facts when dealing with outcomes.

Hope to continue the dialogue both here online and during the FAILfaire events globally.

Have you experienced language constructs that are unhelpful during a retrospecitve or Fail Analysis?

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Paul Hardy
      Paul Hardy

      I have lived  with this in a country I will not name. Instead of solving the problem the focus was at pointing the finger, thus ensuring anyone who could actually solve the problem was prevented from doing so, because they were in a Star Chamber having the Finger pointed at them.

      You might think that one day management is going to move from running round in circles poitint fingers to doing something about the underlying probem but in 23 years in IT I have seen no evidence to suggest this might ever be the case.

      I make a mistake about once an hour on average. I wonder if ANYONE csn go 24 hours withoust making a mistake of anysort?

      If you make a mistake, maybe say so. Is this really a radical world changing idea?

      Author's profile photo Marilyn Pratt
      Marilyn Pratt
      Blog Post Author

      Wow.  Seems like this stuck a chord or a raw nerve.

      I found it interesting that different cultures regard failure quite differently.  When I was in Israel last month, colleagues there couldn't quite understand why I would need to have an event where we discuss failure and accountability.  They asked me if I had read Start Up Nation and I hadn't although I knew the premise.  They also told me something about the culture of the IDF and why "Major Albert Schmidt  a senior accident investigator in the IAF has written on the top of his whiteboard his mantra: “Good judgement comes from experience. A lot of experience comes from bad judgement.” If we are lucky, we will get some workshop materials from someone with real experience in this realm of "Learning From Accidents".

      It might not be a radical world changing idea, but I'm thinking that some cultures really struggle with calling something less than success.

      Author's profile photo Chris Paine
      Chris Paine

      Ha ha - wrong Chris Paine - oh the joys of having multiple SCN accounts I'd be on my way to somewhere near a quarter of the SCN points you have Marilyn if they we all merged together 😉

      Glad you got value from the presentation about retrospectives, it seems to me that these ideas are just part of the way of doing things when you move into the broader software development community.

      As mentioned in the piece by Aino Corry, sometimes even the words we use can frighten people. But perhaps we need a shock to understand the value?

      Looking forward to your session and perhaps sharing some Anglo/Aussie perspective.



      Author's profile photo Marilyn Pratt
      Marilyn Pratt
      Blog Post Author

      Chris, you tapped into the exact theme we will open with: "Why is Failure Scary".

      Got permission from Zane Hollingsworth to use this great pic: scary pepper smaller.jpg

      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      I have witnessed people in negative workplaces sift through their 5+ years of emails to find evidence to exonerate themselves and blame others rather than fix the issue.

      Fault is rarely caused by one person and most times it's a combination of errors, misunderstand and bad luck. Unfortunately, when fault and blame become the cultural norm it is difficult to do a proper root cause analysis and learn as few are willing to take accountability.

      From a cultural point of view, I have run internal training courses whereby I have rewarded the person for putting their hand up and being incorrect as it has generated more debate, broken down some communication barriers and built trust. Once trust has been established, collaboration and improvement became possible.

      Author's profile photo Marilyn Pratt
      Marilyn Pratt
      Blog Post Author

      Hi Colleen,

      Thanks for stopping by.

      I love the "gifts" that you gave for raising hands and being "incorrect".

      That goes a long way in creating a culture of trust. This is another theme we will discuss during our FAILFaire.

      What are the gifts we can give to help reframe or define a language that promotes innovation.

      Thanks for sharing your gifting.

      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      As a photographer this often is linked to Henry Cartier-Bresson's attributed statement:

      “Your first 10,000 photographs are your worst."

      As this is a creative issue, there is really not so much a concept of blame (although I will probably use a photography related fail as an exmaple in two weeks 😉 ).

      In business failure of one person sometimes makes people that come after him/her in the process chain look bad, which is the cause for resorting to blame (I think) - "you made me look bad" or "you made my life more difficult".

      In order to foster a fail culture, we need to provide the time and the opportunity to fail gracefully (which is the #1 issue in my professional capacity, security implementations 😉 ). In our time-to-market culture this seems to be more difficult, and people who provide retrospective are often seen as "adding delay".

      That's the conundrum we need to address in business - failing early and having retrospectives would certainly be the best implementation of "work smarter", unfortunately management seems to prefer "do more with less resources" instead.

      Oh, and our IDF example may not work universally - all you learn in the german army during mandatory service (which we got rid off fortunately) is avoiding work as good as you can 😉

      Author's profile photo Marilyn Pratt
      Marilyn Pratt
      Blog Post Author

      Great point about universality and culture being an obstacle to acceptance. But also very important, is your point about building time for retrospectives within the "time to market" frenzy and allowing the ability to fail gracefully.  I would even say we need to allow the ability to fail productively with very specific guidelines as to how to do that and metrics around the benefits of allowing for that.  And work to make that concept universal.

      And please, let's strip the stigma of "military" from those same cultures that DO factor in and welcome Fail Analysis and instead of dismissing them as culturally inappropriate, analyze them and learn from them.  Let's look together at why they embrace retrospectives rather than view them as a luxury or even an impediment or an impossibility from a resource stance.  In some cultures, the military is viewed as a type of mission critical business, as unpleasant and uncomfortable as many of us are with that kind of thinking of the military/defense industry as a well-oiled or necessary machine.

      Recognizing that we and management need  time for retrospectives and value them not as a "nice to have" but as an inherant part of innovation does necessitate a cultural change. We need to help management find useful language to foster accountability and break blame cycles and to see that if we don't make the time for such activities we actually lose even more time  fixing things post production when we bring damaged goods to market that are less marketable and useful with their flaws cosmetically concealed but inevitably discovered.

      Creating that kind of change in thinking about how we create software is what we are about, no? A language shift that brings about a cultural change should be our important first step.

      Let's just say 10,000 photographs need to start with the first shot.  Let's click that shutter.  With me?

      Author's profile photo Former Member
      Former Member

      Great that you point out the importance of language in such situations! Often overlooked, this is actually an important factor for feedback to be constructive. People tend to provide interpretations of a situation or outcome – like you stated: the words we attach to our experience become our experience.

      Simply stating factual observations could definitely avoid judgments or even blame. However, it is necessary that people realize this first.

      Thanks for the article!

      Author's profile photo Anthonie Benson
      Anthonie Benson

      after reading this comments it seems that management has a lot to learn 🙂

      I feel that management is blamed of this in some statements above and this makes sense if you work in a team where your manager is considered the "BOSS".

      In an High Performance team each individual understands their impact to success and to failure (I prefer the word misses) so that Blame discussions don't need to occur.  This team simply states that they are impacted by a late delivery or error and work together to address the problem and move forward again to ensure successful outcomes.

      in such a team the manager is more a guide and mentor to the team than a boss who doles out disciplinary actions.

      Author's profile photo Marilyn Pratt
      Marilyn Pratt
      Blog Post Author

      I like your use of the word "misses".  In our defination of Failure we came up with a simple sentence.  "You didn't get what you hoped and planned for".  I love the idea of manager as guide and mentor rather than disciplinarian or critic.