Switch: How To Change Things When Change Is Hard

I have been touting Chip and Dan Heath’s book Switch for some time now, so it I thought I ought to actually write about why.

If you are in the role of a “change agent” this book is your manual.

Up to this point, the bible for “organizational change” has been John P. Kotter’s book Leading Change published by the Harvard Business School.

Based on his article Eight Reasons Why Transformation Efforts Fail, Kotter outlines (not surprisingly) an eight stage process for changing a culture:

  1. Establish a sense of urgency.
  2. Create the guiding coalition.
  3. Developing a vision and strategy.
  4. Communicating the change vision.
  5. Empowering employees for broad based action.
  6. Generating short term wins.
  7. Consolidating gains and producing more change.
  8. Anchoring new approaches in the culture.

I have found it quite valuable in the past to challenge a leadership team to assess their own efforts against these factors, then listen to what the next level down has to say. There is always a large gap – what the leaders THINK they are saying clearly is much more muddled to the listeners.

Chip and Dan Heath take things down another couple of levels. They deal with the psychology – what goes on between our ears, and their process maps very well back to Kotter’s – as a much more explicit “how to.”

The Psychology of Continuous Improvement

What really hooked me into this book, though, was just how well it maps to key characteristics of a Toyota-style management system.

People in companies that are exceptionally successful with continuous improvement have the same baseline thinking patterns as people in every other company out there.

The difference is not about hiring different people, it is about how the work and the environment itself is structured. It is likely that structure wasn’t deliberate, these outlier companies just stumbled into it. But if we look at what makes them different (see “Find the Bright Spots” below), we can see they are better at dealing with the things outlined in this book.

That, to me, is encouraging because it reinforces the idea that true operational excellence is within the reach of anyone who is willing to deal with the real issues.

And – key point here – these changes are within the power of the mid-level change agent to affect. You don’t have to be “top management” or even in charge to have an impact. (You do have to work harder and more explicitly, though.)

We (like to) Think It’s About Logic – But It Isn’t.

In business we operate on the assumption that decisions are based on objective, rational analysis of facts and data. If presented with a compelling case, we say, the logical conclusion should follow.

So our efforts to enact “change” start, first and foremost, with trying to educate so that people will “understand the changes” and the “reasons why.”

If they don’t get it, we think, it is because they don’t understand the goodness, so we need to explain it better.

This thinking drives us to try to construct more compelling models and representations of “the system” in our effort to explain why it is better.

If we address the emotional aspect at all, it is usually with trying to “create a crisis” or a “burning platform” – in other words, using fear as a motivator. Or, even worse (apparently), we try incentives to manipulate behavior.

Switch uses a metaphor of the human psyche that is borrowed from Johnathan Haidt’s work in The Happiness Hypothesis.

Haight constructs a metaphor of our mind as an elephant, representing our emotional responses, and a rider on the elephant, representing the logical and rational side of our mind.

You can quickly get the idea here – the rider can influence where the elephant goes, but that’s about it. Unless the elephant feels safe going there, and trusts the rider’s judgment, it ain’t gonna happen.

Following that metaphor, Heath and Heath outline nine actions that shape how groups (and individuals) respond to changes. The book describes them in detail, with stories, examples, and structure.

Online, they have the Switch Workbook which provides a great quick-reference for the book. I highly suggest reading the book rather than trying to use the workbook as a substitute, though. Otherwise you lose a lot of context.

The overview and comments below are organized the way the key points are covered in the workbook.

Direct the Rider

Our metaphorical elephant rider is busy and stresses easily. Given too many choices, the rider becomes paralyzed and takes no action at all.

This is what happens, I think, when we present tons of general, theoretical education and then expect team members to pick up their own initiative and “improve things.”

So it is necessary to provide enough structure to allow people to focus their attention on “how to do it” rather than “what to do.” This means being far more explicit than we typically are. “Vision” is not an ethereal saying on the wall. It is a concrete description of how we want the organization to work.

In this category, Heath & Heath cover three key points that address the logical approach:

1. Find the Bright Spots

Rather than focusing on what isn’t working and trying to fix it, go find examples of where things are working and try to understand why – what makes them different.

Often there are one or two key factors involved and, once understood, they are fairly easy to educate and replicate.

Of course, to understand what makes them different, you must also understand the normal way things are done, and compare that with what you find in the positive outliers.

If I were to use Toyota-style language, I would say “understand the current condition” and use the positive outliers as the basis for a target. Then look, at a detailed level, at what small things make such a big difference. This is a classic “is / is not” analysis, but applied rather than just theoretical.

2. Script the Critical Moves

The most common theme of frustrations I hear from change agents and practitioners has to do with people “not supporting the changes.” But when I question them about what they WANT people to do, I often get a list of abstractions.

To make things even more interesting, many of us (myself included) have been taught to focus on the physical process changes rather than the behaviors required in a continuous improvement culture.

From the Switch Workbook on the Heath Brother’s web site:

Be clear about how how people should act.

This is one of the hardest – and most important – parts of the framework. As a leader, you’re going to be tempted to tell your people things like: “Be more innovative!” “Treat the customer with white-glove service!” “Give better feedback to your people!” But you can’t stop there. Remember the child abuse study [from the book]? Do you think those parents would have changed if the therapists had said, “Be more loving parents!”  Of course not. Look for the behaviors.

Another common source of frustration among practitioners is the comparison with perfection. Now there is nothing wrong with this. It is actually how we should think. But there is a difference between using perfection as your benchmark and expecting it to be achieved in one fell swoop.

By setting a limited theme that you know will advance the process, you help people focus on specific actions – you script what they should be working on, and give them permission to not try to fix everything at once.

One good way to test a theme or critical move is to ask whether or not it is “sticky.”

The other thing that helps, according to the workbook, is keeping the change within the scope of how people think about themselves. It is far easier to reinforce behavior that fits in with an existing self-image than to try to change something so fundamental.

3. Point To The Destination

Do you have a tangible objective that is “met” or “not met?”

What happens in too many “lean implementations” is that the process itself is the objective. “We want to be a lean company.”

So what?

“OK, we want all of our materials on a pull system.”

So? Why?

“We want zero parts shortages.”

Ah! That is something you can rally people around.

At the same time, avoid abstract metric targets. “Gross margin” or “inventory turns” targets might be OK in the board room, but in the real world (which, unfortunately, rarely extends into a board room), you need something tangible that people can see and experience.

Motivate the Elephant

The next three items come under the heading “Motivate the Elephant.” The elephant is the metaphor for our emotional responses to things. As much as the business world likes things to be sterile and logical, people never work that way.

Our logical decisions always follow emotional decisions. If there is a misalignment between the two, we feel great anxiety. Haidt describes “the rider” (our logical mind) as a skilled attorney who can construct a logical, sound rationale for any actions that the elephant takes.

So, where “the rider” can be paralyzed by too many options, “the elephant” needs to feel it is safe to go where the rider is trying to take him.

4. Find the Feeling

Taiichi Ohno talked a lot about waste. He described wasteful actions in ways that made it easy to see. His point, I think, was to give his managers a clear picture of just how much opportunity there was, if only they worked to make things flow.

As a sidebar, I don’t believe he made TPS about “eliminating waste” per se. He doesn’t talk about it much once he makes the initial point. Different topic.

The idea of concentrating your effort into a small model area (rather than trying to take everyone along at once) fits into this. It shows people, in a tangible way, what is possible.

The principle of “go and see for yourself” makes the current condition (and the possibilities) real to people in ways that the best PowerPoint presentation never can.

The key is to acknowledge that “rational analysis of facts and data” rarely (if ever) evokes the kinds of things that cause change.

5. Shrink the Change

When I read this chapter, I saw an immediate correlation with the process of rapid coaching cycles and target conditions that Mike Rother describes Toyota Kata. Aside from driving continuous improvement, that process seems to be almost engineered to shift the culture.

This might seem contradictory with “Find the Feeling” but Big Change overwhelms people – it scares the elephant. So while it is important to have a compelling sense of destination, it is equally (if not more) important to have a sense of immediate progress – “we are getting somewhere.”

In the book, the authors give a couple of great examples. In one, they outline an experiment with customer loyalty cards for a car wash. Two groups of customers were given loyalty cards.

One group required 10 stamps to get a free car wash.

The other group required 12 stamps to get a free car wash – but they were given two free stamps to start with.

Thus, each group actually had the same distance to the goal. But the response was significantly higher for the second group. Why? Because they started with a sense of investment. They had runway behind them, which made the distance to close seem shorter.

The two free stamps also gave them a sense that they would be “wasting” or “losing” something of value if they didn’t go ahead and complete the card.

When we look at an area for improvement, do we focus on how bad it is, or do we frame our next steps to honor the work they have already done and work to build on it? We are going to be doing the same work either way, this is a matter of presentation.

At the same time, do we try for the “big leap” and the 80% reduction as the goal, or do we set a series or more modest objectives that anchor a sense of success and moving forward?

Do you structure a big, complex “lean implementation plan” or do you take on one value stream loop at a time?

6. Grow Your People

Humans are incredibly social. We want to feel we are part of a group. We want a group identity that we can share.

Can you cultivate that sense of group identity in a way that aligns people in the direction of the changed behavior? What sense of identity already exists?

At the same time, you can strengthen people’s resolve in the face of obstacles by predicting them.

“When we implement flow, we are going to see a lot of problems come to the surface.” By warning people in advance about what to expect, you can shift the response from being discouraged to accepting the challenge of solving those problems one by one – because those problems tell us “This is working” rather than “it isn’t working.”

If you can challenge people to embrace what Heath and Heath call “the growth mindset” – we are going to build out competency by practice, which means failing and learning sometimes – that helps turn a surprise or disappointing result into a challenge to learn and grow.

Shape the Path

This is, in my opinion, an area where we make the biggest mistakes. A lot of efforts to implement start off with a “lean overview” of some kind – even to the top leaders – and then leaves it up to them to decide how to go about implementing all of this.

But they are still operating in the same environment they always have, and no matter how compelling the vision, there are obstacles in the way. The path is not clear.

The last three actions cover how to structure the process, the environment, even the organization in ways that clear the path you want people to follow.

7. Tweak the Environment

As I was reading these examples, I was getting really excited because it was all familiar. But Switch was adding even more weight behind the things that we do under the name of “kaizen.”

Yes, we are stabilizing and improving the process, but we are also clearing the path toward the behavior we want.

Consider these two examples from the workbook:

Do a “motion study.”

If you’re trying to make a behavior easier, study it. Watch one person go through the process of making a purchase, filing a complaint, recycling an object, etc. Note where there are bottlenecks and where they get stuck. Then try to rearrange the environment to remove those obstacles. Provide signposts that show people which way to turn (or celebrate the progress they’ve made already). Eliminate steps. Shape the path.

If this doesn’t sound familiar to you as a kaizen practitioner, you need to dig out the basics. This is not only exactly what we should be doing every day, it is exactly what we should be teaching others to do as well.

TPS / “Lean” is a management system that strives to do this every day. The cool thing, in my mind, is that Switch is as much describing what should be our routine as it is describing how to change the routine.

Or try this example:

Can you run the McDonalds playbook?

Think of the way McDonalds designs its environment so that its employees can deliver food with incredible consistency, despite a lack of work experience (or an excess of motivation). They pay obsessive attention to every step of the process. The ketchup dispenser, for instance, isn’t like the one in your fridge. It has a plunger on top that, when pressed, delivers precisely the right amount of ketchup for one burger. That way, if you have to deliver 10 burgers in a minute, you don’t have to think at all. You just press the plunger 10 times. Have you looked at your own operations through that lens? Have you made every step as easy as possible on your employees?

Here is where the nay-sayers tell us “But that work environment gives people no sense of creativity.” Damn right. I don’t want any creativity around the way the product is made. I want to know that my customers are going to get exactly what was specified.

The opportunity for creativity comes from challenging people to create a work environment that makes it easy to consistently deliver the product. And there are endless opportunities to do this. If / when quality is perfect, then work on productivity.

So as we work to “tweak the environment” the real question for a lean practitioner is how to structure things that make and hold space for this creative process of improvement to happen. What blocks the path? Have you carved out that space, or do you expect people to just find a way to do it?

And finally, Heath and Heath challenge us to look at the environment before we start blaming people. Good people working in a bad environment are often painted as flawed in some way. This is called “attribution error” – attributing bad results to the person rather than the process. I have yet to meet anyone (myself included) who was not guilty of this now and then.

The people we call the “anchor draggers” and “cement heads” are making the best decisions they can in good faith, based on the environment and information that surrounds them. We have an opportunity to shape that environment, and thus alter the inputs they deal with.

8. Build Habits

“Behavior” is built up from how people respond to the things around them that trigger those responses. When we talk about “habits” we are really talking about consistent responses or actions.

If we want to change those responses, it is helpful to link the new response to a specific trigger.

Again, looking at a TPS environment, I immediately think “andon.” There is a specific trigger (the light is ON or OFF) and a specific response.

Digging in deeper, and looking at the work Steven Spear did in his original research (which is summarized in Decoding the DNA of the Toyota Production System) we see an environment that is precisely structured to provide explicit triggers for explicit actions.

Further, there are processes to verify that what was expected is what happened, and any deviation triggers another specified response. So I see yet another area where the Toyota management structure is engineered to provide the kind of environment that Switch talks about.

If I am trying to alter behavior, I ask the same questions. Can I set a specific trigger that calls for a specific action that I can check?

Can I take something that people already do and structure the work (“tweak the environment”) so that routine action triggers the new behavior?

Can I structure the work to sequentially cue the next process step as each is accomplished?

9. Rally the Herd

And finally is reinforcing, again, the fact that humans are naturally biased toward wanting to be part of a common social structure.

What is the prevailing social pressure in the organization? Is it counter to what you are trying to do? Are the people who are adopting the new behavior isolated from one another? Are you trying to spread the early adopters too thin, in the hope that they will inoculate the rest of the organization? They will inoculate the organization – by creating powerful antibodies against the change. Small, isolated efforts dissipate your resources to the point where they are ineffective.

What can you do to create a majority from the minority? This is one benefit of the model line. It establishes a concentrated environment where everyone is focused on the same thing, and eliminates (or at least reduces) the social pressure against the new behavior. “We are in this together.”

Now, having a model line does not guarantee that the rest of the organization will spontaneously adopt the new way. Far from it. It takes deliberate action.

“Rally the herd” also means that the group that is doing what you want are celebrated as “doing it right.” But you have to do this in a way that doesn’t rub people the wrong way. Believe me, I’ve seen with my own eyes the pushback created when one division of a large company was constantly lauded as the “shining star” to the others.

Nevertheless, you want to highlight the bright spots, and then find specific, small things that have made a difference. GM couldn’t “just be more like Toyota” or “more like NUMMI.” That wasn’t enough. They wanted the results, but apparently never dig in to truly understand the few key things that went deeper than the mechanics.

Conclusions

Practitioners are often expected to “drive the change” into an otherwise passive-aggressive organizational culture. This can be a frustrating experience because lean practitioners are rarely given the tools to affect social conventions.

It is a sad fact that the vast majority of efforts to “implement lean” falter or fail within a few years. The message that I draw from this is “Look at what most people are doing, and do something different.” The mainstream message we have been getting doesn’t work very well, and just “trying harder” is no more effective here than anywhere else.

This book, with some careful study, discussion, and a little collusion, can form a great blueprint for how to actually structure your work to move the cultural change along.

The key is to remember that the “lean implementation plan” is NOT about how to implement takt, flow and pull. It is a plan to shift how people behave and respond to issues every day. The tools are important, but only because they create opportunities for people to learn and demonstrate the new way of daily management.

Why Don’t They See This Is Better?

“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.

Lego Moonshine

In the Production Preparation Process (3P) we use the term “moonshine” to refer to process of rapid prototyping and iteration. The team creates concepts and tries them out quickly and cheaply in order to learn more.

Today we have some really powerful tools available to do this. One of them is Lego Technic. It is versatile and modular, and you can make machines that actually work.

But the spirit of moonshine means you don’t just think up a complete machine and build it.

Moonshine is a progressive process of adding automation step by step. The final characteristics of the equipment emerge from the process rather than everything being designed from the get-go and just built.

5S in Three Bullets

I was in a conversation today and we ended up boiling 5S down to three key points:

  • You have everything you need.
  • You need everything you have.
  • You can see everything clearly belongs where it is.

Of course at the next level, these statements are the standards you are continuously checking against.

Presumably we have cleared out everything else, leaving only what we thought was needed, and established visual controls to verify we have those things, and only those things, in the work area.

Then, as the work is done, the moment someone discovers something else is needed, THAT is the time to deal with the issue.

– Ask “Is this something we should need in the normal course of the work?”

If so, then you learned something that you didn’t know or didn’t remember when you first organized the area. Add that item, find a place for it, and establish a visual control. Right now.

If not, then “Why did we need it this time?”

What broke the normal pattern of work?

This is where 5S breaks down – when we don’t discriminate between something that is needed in the normal course of work, and something that is needed as an exception.

If we just “get it” and add it to the work area, then we normalize deviance and incrementally erode the process. If we ignore the issue, we add “getting this when it is needed” to the work cycle.

If, on the other hand, we seek to understand what broke the normal pattern and deal with the core issue, we have a shot at real kaizen. (It is perfectly OK to get what you need and keep it around as a temporary countermeasure. Just put it someplace where you will KNOW when you used it.)

The worst thing you can do is allow these small problems to accumulate and try to correct them en-mass as some kind of “corrective action.”

Kanban

Likewise, kanban can be expressed the same way. It is more dynamic, but is really answering the same questions in the context of materials.

 

Standard Work

If you paraphrase these key points to just about any other “tool of lean” then the purpose of surfacing problems and driving solution becomes apparent.

  • You are doing everything that is required.
  • Everything being done is required.
  • Everything being done clearly is part of the sequence.

Take a look at the other classic “tools of lean.” How would they fit into the same pattern?

 

Continuously Improving

The term “continuous improvement” has been around a long time. The truth is most companies don’t do continuous improvement at all, rather they schedule improvements in batches and projects.

The effect of batch improvements is that “improvement” is not “business as usual” and people learn what they do every day, not what they do intermittently. That is one reason why it is usually necessary to precede a kaizen event with a training session.

But there is a deeper ramification here that challenges the very goal of the process.

We all assume (myself included up to this point) that the goal is continuous process improvement.

Maybe it is.

But we also say it is about developing people.

Processes come and go with new technology, new products, reorganizations, etc. The people are the only constant.

Let me float this idea out there –

How would your continuous improvement process change if you thought of its  primary objective as continuously improving the capability of your people?

Process improvement would be a vehicle for people development. In effect, your success at process improvement would be an indicator of how well you were developing people.

To paraphrase a common expression, process improvement is the shadow of how well you develop your people.

That would mean if your process of continuous improvement is targeted at anything other than the capability of people, you are trying to move a shadow by pushing on it.

Its about the people.

hmmmm.

Thoughts?

People Kaizen

Tommy raised an interesting question in his comment to Internalizing Outside Knowledge. He said:

In my company we are working with the developing people concept. Our objective is to make ourselves redundant, but it is hard. What are the best ways of developing people? How do you do it?

How do you do it indeed?

I don’t know the specific situation he is facing, but I can ask some questions that are pretty universal.

What, exactly, are you striving to achieve with your people development? What do you want people to be able to do that they are not doing now? What would that look like if you were to observe it? How would they be interacting with the process, with each other?

If you observe today, what do you actually see? How does that differ from what you described above?

What is the gap between what you want and what you have?

I ask these questions because often we talk about “developing people” but we don’t get specific about what we expect as a result. It is easy to set objectives for kaizen of processes, quality, output, cycle time, etc. But when we talk about people, we get squishy about it.

But the process of improvement remains the same, no matter what (or who) you are trying to improve. And the first step is to know two things:

  • The direction you are trying to move – the ideal, the True North.
  • The next target you are trying to hit now which will move you in that direction.
  • When you expect to be there.

Once you have that, it is time to take a look at what you are actually doing and ask how, exactly, that effort is expected to advance you toward your target.

If the answer to that question is not crystal clear, it is time to step back and reassess your approach. Likely your approach is general and broad-brushed, rather than focused.

What never works is telling people about improvement and expecting them to get excited enough by that message to fill in the details on their own. The idea that “once they grasp the true vision they will engage on their own” is a common one.

But consider this analogy. We all know that mathematics is a wonderful tool. I can tell you all about the great discoveries and engineering feats that mastery of mathematics has enabled. I can show you dozens of examples, even take you through demonstrations of how others have used mathematics to solve problems.

At the end, you might be fired up about math, but you still can’t do it. I may have motivated, but I have not developed anyone.

If I want you to actually use mathematics, I have to assess where their current skills are, establish the next step for them, and construct a situation where they must practice and struggle a bit, but not too much, to “get” the next understanding.

That is called “practice.”

So – back to the original question.

You want to develop people.

What are you having them practice for a little while every day?

How are you providing them immediate feedback on success or failure, and coaching them?

How are you checking your results against the results you intend? What are you doing to develop and improve your own process of people development?

PDCA

Rapid PDCA with 3P

“3P” is not a Toyota term. The workshop structure was taught by Shingijutsu and is now being propagated by people who learned it while working in their client companies.

The most visible characteristic of 3P, the Production Preparation Process, is the idea of creating quick and dirty mock-ups of the product and the process. These mockups are often constructed of wood, cardboard, PVC pipe – materials at hand.

600x3p-benches

The idea is to be able to quickly and cheaply try out, and experience, a process (or product) so that problems can be surfaced, opportunities for improvement can be seen, and the PDCA cycle can be turned far more rapidly than would otherwise be possible.

The purpose of the mockup is to create a gemba of sorts, where you would not otherwise have one. Now, rather than doing an abstract analysis, you have something that people can see, touch, and interact with. Doing so forces details to the surface that are simply invisible in abstract models in computers or on paper.

Some companies use the process to design their products as well as the processes that are used to manufacture them.

Last week one of my clients took their first steps into this process. The photo above has been pixelated so as not to reveal details about their product design.

They had done pretty extensive analysis using traditional industrial engineering methods, and had a CAD drawing of the proposed layout. That was the starting point.

The first step, then was to create that layout in real-size. That took the team about 90 minutes.

They assembled some tables, got some boxes and cardboard, and represented the machines, the work positions, the material and people flow.

Even as they were doing this, some of the team members saw things that they questioned, such as an ergonomically awkward operation. Others simply had questions. Why? Because in translating the drawing into the real world, even a superficial one, details already had to be resolved.

Once they had the starting condition mocked up, the team took prototype parts of the product and went through the motions of a team member trying to assemble it.

This felt a little awkward at first, but they began to see more opportunities, and resolve more detail.

We did a little coaching, pointing out motions that could be eliminated, others that could be consolidated. We talked about the smooth flow of people’s work, and looked for opportunities to better match the work flows to the takt time.

In the next couple of hours the team went through dozens of small PDCA cycles, each time adding a little more detail, adding a physical control, or a visual control. They found “knacks” that enabled quicker assembly with less adjustment.

They identified exactly how and where parts should be presented to the assembler.

They discovered small design and packaging changes that could make a big difference in the assembly time and quality. It did not hurt that the design engineer was trying to work out the details of one of the more awkward elements of the assembly.

They found key points that were critical to quality, examined the vulnerability to simple mistakes, and worked on how to make those more clear.

3pAndon

They identified characteristics that would help the machines better support the work flow. How do parts move in, move out? Where do the hands go to start the machine? How does the location of the controls support (or hinder) the work steps that come before and after?

As they looked at test operations, they started working out what they wanted to happen when there was a problem. They started to work out a line stop protocol and added andons to those machines, so they could signal an abnormal result.

Curious visitors, some senior managers, others just happening by and wondering what was going on, were enlisted as test subjects. Is the work cycle simple and clear? Is it easy to teach? Is the layout intuitive?

What can we do to make the visuals more clear, and to lay things out to guide the correct process sequence? Which “knacks” have to be taught? How quickly can a “new operator” be brought up to speed and make the takt time?

Over three days, the details came into sharper and sharper focus.

In the end, the team had constructed a full size model of their target condition. They are clear how the process needs to operate to give them the performance they want; and they are equally clear about the next problems that must be solved to get there.

They can specify their equipment with far more insight, and many of the details of how to guide the product and people through the process are now much better understood.

And, as a side benefit, this cross functional team has communicated far more than they would have otherwise with meetings and email. They have spent three days embedded in a joint project to envision what they want this to look like.

To be clear, a lot of work remains, and many more details remain to be worked out. But over three days this team now has a much more clearly aligned concept of what they are striving to achieve.

What Do You Teach and Practice Every Day?

Mike Rother forwarded this link to an article by Bruce Hamilton in Quality Digest with the observation that “the lean ship may be turning.”

The key point is that people learn what they practice. And if you practice kaizen every day, you learn kaizen. But if you practice something else every day, you learn that. If kaizen is only an occasional “special event” then it never becomes engrained as “the way we do things.”

From the article:

The truth is, when everybody practices status quo behavior almost every day,that is what is sustained. If employees are not practicing the new way every day, by default they are practicing the old. Practice makes permanent.

Mike illustrates this principle well in his presentation Introduction to the Improvement Kata.

batch-improvement

In reality, rather than days between events, the experience of the team members is more often like weeks or months. Some companies set a goal of getting every team member through one or two kaizen events in a year.

While this may spread the effect wide, it ensures that nobody has more than superficial experience. It is build on an expectation that once a process is “leaned out” that it should stay that way until there is an opportunity to come back around and “fix it again.”

Of course it actually begins to erode right away because the daily habits have not changed, and it is those daily habits that put the waste into the process to begin with.

The traditional model for kaizen is firmly anchored in Fredrick Taylor’s concept of separating experts from workers. Even though we solicit worker’s input during kaizen events, the process of kaizen itself is still largely the domain of technical experts. They are the ones who own the process.

Some companies go so far as to not allow kaizen to be done by people who are not “certified” in some way.

What we have to do is shift the role of those kaizen experts from one where they plan, conduct and lead special improvement events to one where they are on the shop floor every day teaching and coaching the line leaders. This is the only way (that we know of) that will actually transfer the knowledge.

Only when those line leaders are, themselves, teaching and coaching can the effort let up a bit and move on.

The “ship may be turning” because this idea is beginning to find its way into the mainstream discussion in the lean community. This will not happen overnight, however. There is huge inertia in the expert-as-implementer mode across all approaches to improvement. But if we (the lean practitioners) want to know why the results do not sustain, a large part of the answer is in the mirror.

“If the worker hasn’t learned, the teacher hasn’t taught.”

Standard Problem Solving

A key point of Mike Rother’s book Toyota Kata is that the organization develops a very deep core-competency in problem solving.

In order to develop competency at anything, there must first be a standard to strive for. What I am realizing is the precise method used doesn’t matter nearly as much as having a method (that works) and rigorously striving to follow it.

Why is this important?

Consider the opposite. Let’s say, hypothetically, that we have a team of very good problem solvers and they are trying to tackle a tough problem. However each of these people brings a different method to the table.

As they discuss the problem, each will be trying to frame it in his or her paradigm for how to go about arriving at the root cause and finding a countermeasure. Indeed, even those words (root cause, countermeasure) might be different.

Some of them might not even call it a “problem.” A team member steeped in Theory of Constraints is going to be referring to a “constraint” – what is constraining the system from advancing to the next level of performance.

Someone else will insist on calling it an “opportunity.”

No matter how competent each individual team member, the group is going to expend a lot of time and energy with how to go about even defining the problem. This is time and energy that is not spent actually solving it.

Things get worse if there are weak problem solving skills to begin with. Someone might have heard of “5 Why’s” for example, and try simply asking “Why?” repeatedly, and writing down the answers on the flip chart in a mistaken belief that this effort leads the team to the root cause of the problem. (it doesn’t, as the room is hermetically sealed to information flow).

So if the organization has a structure, a method, for problem solving there are at least steps that should be consistently followed.

Introduce a good facilitator / teacher / mentor into the mix, and they get an opportunity to practice with coaching, and develop skill.

But “without a standard, there can be no improvement” and the same thing applies to problem solving and improvement itself. If you want to get better at it, you need to start with a standard you are striving to achieve, and then study what keeps you from achieving it.

Lean Facilitators are Countermeasures

What is the role of your lean facilitator?

This question comes up now and again, was recently posed on the LEI forums by someone looking for help with a job description.

I extrapolated from his question that he was looking to the job description as a line of defense against dilution of the facilitator’s focus and effort by projects that might not be going in the appropriate direction.

In effect, this is putting the lean facilitator in the role of a weakened zampolit with the role of educating the “correct view” and challenging decisions that run counter to it. Except that more often he has to sell the “correct view” rather than impose it.

The fact that the question is being asked at all indicates that the organization has not really thought through what their operational vision is. How will the company work, what are the responsibilities and roles of the leaders?

What are the leaders’ job descriptions in this new world?

Those job descriptions become a target condition for each of them.

What is the gap?

If there are gaps in skills and knowledge, then we need countermeasures.

At this point, the role and responsibility of a lean facilitator might begin to emerge as one of those countermeasures. Don’t have the expertise? Import it.

What doesn’t work, though, is to use the lean facilitator to substitute for the leader’s full and direct participation in the process of improvement. And no job description, no matter how carefully crafted, can fix that.