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 marciawalker 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?
