“Resistance to change” is a common theme of discussion among practitioners on various online forums, as well as in emails I get from readers.
One thing I see fairly often is that a practitioner will be suggesting a visual control or a specific application of a “lean tool” as a “better way” in the process being examined.
“They can just look it up on the computer,” say those holding on to the status quo, “why do we need to put up a board?”
Why indeed?
So the practitioner tries to make a logical case, and often comes away frustrated. “Leaders aren’t supporting the changes” is a common lament at this point.
But let’s break down the problem and see if there is more we can do.
We are often debating whether or not a particular solution is better than the current way.
But in our “implement the tools” approach, we tend to make “lack of a specific solution” into a problem.
Whoa. Let’s back up a bit and see if we can head this off.
Do you have agreement on a clear target objective, one that all parties can describe? Do you know how the process should be performing?
Note I said “should” not “could.”
“Could” is potential.
“Should” is an unmet expectation. Big psychological difference there.
If everyone agrees that the status quo isn’t getting it done, and also agrees on what they want to achieve instead, then the next question is “OK, what is stopping us from taking the next step?”
This shouldn’t be an abstract exercise. As you watch the people in the process try to reach a higher performance level, look for “What just got in our way?”
You need to help the leaders, and your other constituents see it with their own eyes. Don’t expect them to take your word for it. You wouldn’t take theirs without your own observation.
If everyone can see, for example, that a team member gets too far behind to recover before anyone else notices, or that a machine is experiencing stoppages or excessive changeovers, for example, then you can start discussing solutions.
Perhaps the team leader needs to make quick status checks periodically, in a way that is not intrusive.
What is stopping him?
Well, that’s difficult right now, because everything is buried in the computer, and often updated in batches after the work is done.
Hmmm.. What could we do to make things more visible, in real time? Is there a way we can set up the work area so the team leader (and the worker, and anyone else just happening by) could readily see there is an issue here?
Now, and not before, is the time to start discussing solutions. But you can’t just make the logical argument. You have to get agreement each step of the way.
That might very well take longer than you want it to. People are funny that way.
But the bottom line is this: “Lack of your pet solution,” no matter how many books and name-brand authors refer to it, “is not a problem.”
We create a lot of our own resistance by running into things, and leaving fires behind us.
Thanks Mark. This is extremely helpful.
I’m just starting a Kaizen event and we are in the process of creating a goal, problem statement and future state. Then we will be looking for “what is getting in the way”. And of course I was worried about how we would get the workers to change their behavior.
This article has helped me be more prepared. You da’ man!
I constantly tell myself and my team, “Don’t be a hammer looking for a nail.” It’s much easier said than done. This post confirms my self-diagnosis. :o)
Just catching up on the lean thinker and I had to respond to this one. You should do a post on how long it takes and what it takes to get to the point that you can actually do what you are saying in this post.
I can say from personal experience that it was at least 10 kaizen events before I really recognized that I needed to build consensus at each stage in the process. It probably took 20 kaizen events before I could do it. After I had personally facilitated over 30 events I got to the point that I felt like consensus wasn’t just an accident but was a natural result of the process.
I executed a kaizen event 3 months ago that was without a doubt the most complicated culture change event that I have ever dealt with. I knew going into it that the end result was going to change people’s job titles, dramatically change the roll of the supervisor, and even eliminate certain positions (no cutting of heads but a serious realignment). It was going to affect people’s lives, not just professionally.
I knew going into it that this is what the organization needed. As the manager over the area I also had the authority to simply make it happen by writ. Luckily, with my experience in kaizen events, I knew better than to try. Instead we started with the problems and we got consensus that there was a real problem and that our target condition was a good one.
Then we went through all of the steps you described above. The intense socratic questioning continuously. The ending target condition: exactly what I expected it to be in the beginning. But it wasn’t my idea, it was the teams. They created the idea and with very little prompting from realized that this is what the organization needed. 3 months later with intense follow up and continuous refining, the results are worth every bit of the effort.
Why do I tell that story? Because I could not have executed this event a year ago. I certainly couldn’t have executed it 2, 3, 4, or 5 years ago when I first started facilitating events. In order to be the right person to do this job, I needed all 100+ kaizen events that I have under my belt. There were hundreds of pitfalls that had to be steered away from in this. I don’t think any organization understands this in the slightest when they set out to create a lean organization or they assign a lean champion…
Kris –
I think you have said it pretty well.
Skill comes from experience, and “experience is what you wish you hard right before you get it.”
Excellent point Mark.
One thing I would like to add is that many times those of us in the continuous improvement business have to argue in favor of changes to a process for which there is no agreement that the status quo “isn’t getting it done.” In fact, at times, most people involved with the process may be just fine with it they way it just is. However, because we are continuously seeking to improve, we must then argue for an “improved” method or solution where the consensus is that none is needed.
The point I am getting at is that the status quo not getting it done isn’t always the reason to seek change. Just simply seeking to improve an already efficient process is necessary or required. These cases truely represent a more challenging situation.
True – if the leaders, and the team, are all 100% satisfied with how the business is performing, their margins, their profits, their market share, their working capital levels, their speed-to-market, their product mix, safety levels, and the working environment then you are going to have a tough time finding agreement that “things could be better.”
On the other hand, I haven’t yet met a business whose leaders weren’t looking to do better. What is stopping improvement in those cases might not be a technical issue, but an operational, strategic or management issue.
True continuous improvement is a problem-solving process. Some form of “What is the problem?” has to be the leading question, otherwise you are trying to make the logical case to do things differently rather than do them better.