One of the biggest issues faced by organizations in creating a culture of continuous improvement is the underlying need to always have someone to blame and the way that this need figures prominently in the day-to-day language of its teams. This often fuels adversarial relationships rather than the true collaboration required for an improvement culture.
Sometimes, the language and finger-pointing is very obvious with phrases such as:
- If this fails, heads will roll!
- What the “H#@&!” happened here?
- Who did this?
- It was all ____’s idea.
- What were you thinking?
- That team/individual always sends us crap.
At other times, the verbiage is more subtle:
- Why was this done?
- Did we explore other alternatives?
- We don’t have authorization to do that.
Finally, we may judge future projects based on past results or prejudgements:
- We’ve tried that before.
- That won’t work here.
- The last guy that tried that ended up . . .
When these examples become the language of your team or organization, it is very difficult for Continuous Improvement (C.I.) programs to take root, because stakeholders become unwilling to experiment. Even worse, it is hard to engage others to be part of your improvement opportunity if you start out by putting their teeth on edge. I can guarantee that if you make changes to improve a process without involving other key players, you will experience the “flavour of the month” with changes that don’t stick or worse an escalation of the blame game.
I am reminded of a case from early in my continuous improvement journey when I was assisting a colleague with a time-consuming issue that he hoped to resolve. Here is his story (names have been changed):
Mark was providing support to a group of technicians who used their laptops to install our product on customer premises. He approached me with a problem he was looking to resolve. Mark had identified that when “his” technicians received replacement laptops (a process known as “Evergreening”), they often lacked all the tools to satisfy their customers’ needs, as the new laptops lacked the programs and interfaces required to perform their work.
Mark went on to describe how much of his time as well as the technicians’ were being wasted while the customer’s needs remained unsatisfied. He also went on to place the blame for these deficiencies squarely at the door of the Evergreen Program Manager, Alan. In fact, in his frustration, Mark had taken to referring to Alan as “that A$$hole Alan.” Hardly a great place to begin a C.I. initiative!
I spent about thirty minutes with Mark to help him put together some details using my “Simple C.I.” process. We defined:
- The Problem
- When technicians’ laptops are replaced, they often lack the required tools, programs and links in order to complete their work.
- The Desired State
- When a technician receives a replacement laptop, it should contain all of the tools, programs and links to be fully functional without any downtime.
- The Pains (which we later estimated in terms of time and money)
- The technician’s
- Additional time required to complete his work.
- The customer’s
- Additional time spent waiting for the service.
- Possible longer delay of service if a new technician must be engaged.
- The company’s
- The cost to dispatch a second technician.
- Possible damage to the brand (if we cannot make our own technology work, how can we make theirs work?)
- Unable to get the technicians running at full capacity.
- The technician’s
Once we were both confidant that this simple document could provide the starting point for a discussion with Alan, we scheduled a teleconference with him. Our plan was for Mark to walk him through our observations and to see what his perception was. Our measure of success for the call was to achieve an agreement with Alan about where we were, where we wanted to be and why we needed to make the changes.
I often refer to this as going on a journey. If we are going to be travelling companions, we all need a common starting point, a common destination, and everyone needs to have at least some reason for (or perceive some benefit from) making the trip.
The call took place a few days later. As the organizer, I made the introductions and explained that Mark had approached me with an improvement opportunity and that we wanted his input. I then handed the call over to Mark to “execute” the plan. Little did I know that he would take my use of the word so literally! Rather than reading from our prepared documents, Mark began an attack on Alan asking questions like: “Why do you do this?; “Why don’t you do that” and basically impugning Alan’s work. I stopped Mark and asked if he minded me sharing the document we had prepared. Once I had politely shared Mark’s problem, I asked Alan to provide his insight.
Alan’s summary of the challenges faced in the process changed Mark’s tune from one of blame to one of sympathy. He was now asking questions like: “You mean you don’t have line of sight to this?” or “You don’t have access to that?” and ending by asking most empathetically: “How on earth do you do your job?” What a change of tune!
Our discussions took on a new dimension and Alan became a partner in the solution that ended up being rolled out to the technicians Mark worked with, but also to all of the technicians in a large company with estimated savings of over a million dollars per year!
Today, I continue to tell this story about how moving beyond blame allows us to build collaborative teams. My question to you is what will you do with this learning?
- Will you check your own language and use of blame?
- Will you perform a similar check on your team?
- Will you be so kind as to share your thoughts and comments on this blog post?