Leadership: Deal With The True Constraint

I am starting to read a review copy (courtesy of McGraw-Hill) of Jeff Liker and Gary Convis’ new book, The Toyota Way to Lean Leadership. (The hot link goes to my Amazon page.)

In the spirit of one-piece-flow, I am to share key thoughts as I go rather than save everything for a thousand word review at the end.

One of the first points that comes out – in the prologue no less – is the acknowledgement that people development is a constraint to growth that you ignore at your peril.

One of the results of Toyota’s breakneck pace of growth in the first half of the last decade was that they were still making North American decisions in Japan.

They were doing this because, in the authors’ words, “…Toyota did not develop enough leaders, or did not develop leaders that it trusted sufficiently, in the North American operation to allow decisions making and problem solving to be as close to the gemba as they should have been.”

But rather than say “we grew too fast,” the President, Akio Toyoda sees the limits and the relationship:

“The problem was that the pace of growth was faster than the pace of human resource development… It is not the growth pace itself, but it is the relationship between the pace of grown and the pace of [people development].”

When traditionally trained managers think about constraints to growth, they typically think about things they can buy. “People” as a constraint comes in only as a hiring problem.

But it takes time to develop “people” into a team that thinks and moves in unison. Today’s leaders, up to this point Toyota included, underestimate both the time and the effort it takes to do that.

Any good sports team knows what it takes to build a team. So does the military. We understand the science, the psychology. But perhaps because it is difficult and sometimes messy to deal with people (and it is certainly impossible to reduce the effect of good teamwork to a stoplight report and a spreadsheet), “people development” gets delegated to HR, or people are sent to classroom training and given “certifications.” Doesn’t work, never has.

Akio Toyoda was acknowledging an uncomfortable truth – that they had fallen behind on people development and they had continued anyway, without pulling the metaphorical andon and addressing the issue as soon as it came up.

This simple insight hits at the very core of what we, as a community, need to address, and what the flag-bearing institutions in our community still need to fully embrace.

“Continuous Improvement” means “continuously improving people.”

While just about every “lean overview” I have ever seen uses some form of lip service to the concept of “people based system” everything then goes straight into describing the technical characteristics of everything but how people are developed.

What I like is that in the last couple of years the mainstream books are starting to address this topic in a meaningful way. This, of course, isn’t the first of Jeff Liker’s books to hit here. And Toyota Kata is really the first to address the mechanics of people development as thoroughly as we have addressed the mechanics of kanban.

I am liking what I am reading in this book so far, and I’ll be working to correlate what I read with other works out there plus my own experiences. This should also tie in nicely with points I want to continue to make on Bill Constintino’s presentation.

Stay tuned.

Bill Costantino: Toyota Kata “Unified Field Theory”

Mike Rother and Bill Costantino have shared a presentation titled “Toyota Kata Unified Field Theory.”

I think it nicely packages a number of concepts in an easy-to-understand flow.

I want to expand on a couple of points but first take a look at the presentation.

This is a direct URL to the original SlideShare version: http://www.slideshare.net/BillCW3/toyota-kata-unified-field-theory

Challenges and Campaigns

First of all, this presentation differentiates between a “challenge” and the target condition. That is important, and (in my opinion) had not been as clear in Rother’s original book.

I have been advocating setting a challenge, or campaign if you well, for some time. This is where we address a class of problems that are a major issue. Things like:

  • Too much cash tied up in working capital. (Which can be expressed a number of ways, such as improving inventory turns.)
  • Poor schedule performance – “on time delivery” becomes the theme.
  • Quality issues (too much rework, scrap, etc.)
  • Our nurses don’t have time to prepare rooms for the next patient.
  • Of course, safety can come into this arena as well, as can other issues that impact the organization’s health.
All of these things are not really problems in the sense that they can’t really be solved. These are the aggregated symptoms of lots of smaller underlying problems that accumulate into things on this list.

Setting a specific challenge doesn’t mean you ignore the other stuff. You have been coping with it and working around it for years. But you know you haven’t had time to fix everything, so stop believing that you do.

The point here is to galvanize the effort.

Chip and Dan Heath address the importance of setting the challenge in their book Switch (which I have reviewed here). They emphasize the importance of “scripting the critical moves” and “pointing to the destination” so that people have a good grasp of what is important.

Once the challenge is addressed, say “on time delivery,” it can be broken down into target objectives that are both local (large organizations need to have things broken down to what the local group is expected to work on) as well as those which cut cross-functionally. The scope of the effort is really defined by the depth of the organization’s skill at addressing the issues at this point.

Bill Costantino correctly points out that setting the vision, and deciding the theme or campaign, is a leadership function. This can’t be done by your “lean team” in a way that sticks. The discipline required here is for the leaders to maintain what Deming referred to as “consistency of purpose.”

Simply put, to say “this is the challenge” and then continuously ask about other stuff jerks people around and serves only to paralyze the organization until the leaders decide what people should spend their limited time on.

The good news is that it really doesn’t matter. If the organization can focus on One Big Thing long enough, their efforts will eventually touch on the other stuff anyway.

Jim Collins uses different words to make the same point in Good to Great with the “Hedgehog Concept.”

The Path to the Target Condition

One place where I think we can still use some more clarity is in the illustration of the path to the target condition.

This is the illustration from Slide 20 in the Slideshare version of the presentation:

The presentation (and Rother’s coverage in Toyota Kata) is quite clear that navigation through “the grey zone” is a step-by-step process (kind of like driving off-road at night where you only see as far as your headlights).

But the “plan and execute” paradigm is very strong out there.

My experience is that people in the field see this illustration, and fully expect the green path to be set out, and the “dots” identified, along with a time line and resources required to get there. It becomes a “project.”

This is a strong symptom of the “delegate improvement” paradigm that we should all be actively refuting.

Let’s look at how I think this process actually plays out dynamically.

Initially we know where we are, we have target condition, so we know the direction we need to go to get there.

We are still inside the red line of the “current knowledge threshold.” Solving these problems is generally application of things we already know how to do, perhaps in new ways.

And having solved one problem, we now identify the next known barrier:

Once that one is cleared, we see a couple of choices. Which one?

All other things being equal, pick the easiest, and move on. (As we said when I was learning rapid maneuver tactics in the Army – “haul ass and bypass.”)

Up to this point, we have been operating inside the “current knowledge threshold.” Our efforts are better focused by pursuing a clear target objective, but we aren’t really learning anything new about the process. (Hopefully we are becoming better practiced at problem solving.)

Pretty soon, though, we reach the edge, and have to push out the red line. Why? Because we can’t solve a problem we don’t understand. As we approach the boundary, things get harder because we have to do a better job assessing, and extending the knowledge threshold around the problem.

This is the essence of the problem solving process – If you can’t see the solution, you need to better understand the problem.

The process becomes one of progressively solving problems, identifying the next, and expanding our understanding. Once there is sufficient understanding to anchor knowledge and take the next step, do so. Step and repeat.

Putting the whole thing in motion, it looks like this:

The key is that the “green path” isn’t set out as a predictable trajectory. It is hacked out of the jungle as you go. You know you are going, are confident you can get there, but aren’t sure of exactly what issues will be encountered along the way.

Let me apply my “Project Apollo Test” to this process.

Vision: “The USA will be the undisputed leader in space exploration.” Vague, a long way out there, but compelling.

Challenge, Theme: “…before this decade is out, […] landing a man on the moon and returning him safely to the Earth.” In 1961, a serious challenge, but considered do-able based on extrapolating what we knew.

At this point, though, space exploration was exploring a lot of different things. Building a space station, reusable launch vehicles, pretty much the whole gamut was being explored by someone, somewhere. The effort wasn’t focused. The “man on the moon” goal focused it. Every thing was pretty much dropped except solving the problems that were in the way of making Lunar Orbit Rendezvous work.

There were four target conditions that had to be cleared.

Build and test the Big Honkin’ Rocket called the Saturn V plus the infrastructure to launch them in rapid succession.

And they had to answer three questions:

  1. Can people spend two weeks in space without serious physical or psychological problems?
  2. Can we build a space suit that lets someone operate outside the protection of a space craft?
  3. Can one space craft maneuver, rendezvous and dock with another?

Of course each of these objectives, in turn, had lots of smaller challenges. NASA’s effort between 1962 and 1966 was focused on answering these three questions.

In doing so, the threshold of knowledge expanded well beyond the immediate issues.

Yup, I’d say this thinking works, and it scales up.

Why did I go through this little exercise? Because if this thinking can put people on the moon, it is probably powerful enough to move your organization into new territory.

Back on Earth, a company undertaking “lean” needs to really grasp that they need to be committing to embracing this process. There are clear things that leaders need to do to make it work, and those things go beyond “supporting” or “sponsoring” the effort. We’ll get into some details on the next few posts as we continue to build on Rother’s and Costantino’s work.

 

 

Theory Tests Reality, Reality Tests Theory

“Experience by itself teaches nothing… Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.”

–W. Edwards Deming, The New Economics for Industry, Government, Education – 2nd Edition

The field of psychology, it seems, shares an issue with the field of operations management.

Wilson and Golonka, psychologists who blog on Notes From Two Scientific Psychologists lament about the lack of a unifying theory in their field in Theory, and Why Its Time Psychology Got One.

This is fairly heavy reading since it is likely from outside your field, but the core message is here (paragraph breaks added for readability):

Theory in Science
As I try to teach my students, the role of theory in science is to provide structure to your data. A good theory rules explanations in and out, and if it rules out the wrong explanation that will become clear over time as you pursue your theory guided research.

Good science means a) restricting your explanatory mechanisms to include things your theory allows, and b) keeping an eye on how well that’s working out for you, while c) allowing yourself to rest on your well supported theory to resist breaking the rules as long as you can.

As Deming points out in the quote at the top of this post, having a theory – a solid statement of what you believe is true is a prerequisite for learning to take place. Without that theory, events and information simply get filed away as “interesting.”

With a theory, each is compared against the prevailing thought and forces us to reflect on our understanding.

Sure, we run into confirmation bias (where we unconsciously exclude things that contradict our beliefs) and other logical flaws, but honestly – if scientific thinking were easy, we wouldn’t have to discuss it.

This is pertinent to us at a couple of levels.

At the macro-level we have the proliferation of “solutions” out there for management. We all talk about “flavors of the month” and “alphabet soup” as we see companies cycle through the various structures for “world class performance.”

Wilson and Golonka’s message, and our problem, is that in attempting to embrace everything, we embrace nothing.

Of course part of the problem is that book authors and management consultants are not, by and large, researchers who are interested in unifying the theory. Quite the contrary. They are interested in differentiation. This causes problems for people who see these various “solutions” as competing somehow. (In reality, they are mostly re-packaging of subsets of the same overall stuff.)

OK, we can’t do much about that in the larger sense, but within your company, you can.

I have yet to encounter a situation that is outside of my baseline theory of “what TPS is.”

As I said in a talk I gave last week, the only faith-based position I am asking you to embrace is that if your results seem incompatible with TPS, look at your understanding and deployment before rejecting it as unworkable.

While we wait for the MBA programs and influential institutions in our field to catch up, we can continue to identify in forums like this one which authors and researchers we think are largely congruent with one another and some kind of common baseline.

The other area where this message is applicable is in our daily approach to process design and problem solving.

Almost all of the “tools of lean” (and many techniques not especially associated with TPS) are really designed to develop and test a working theory of how the process should be working.

Takt time is a great example, though far from the only one.

I set up a process to operate at a certain speed. I say, in effect, “if the process has no unexpected problems, this is how long it should take.”

That is a theory.

I test the theory each and every time I run the process.

When (not if) something unexpected happens – when the team member can’t meet the standard work for some reason, then we have data that is not congruent with our baseline theory.

Now we can get into understanding why – what happened that we didn’t count on. Likely (in this example) something uncontrolled tripped him up. In experimental terms, we didn’t have the baseline conditions.

In our process terms, we now have a problem to solve – how do we keep that issue from coming up again, so that our team member can do the work in the time expected?

As we cycle through this thinking again and again, each iteration either cleans up some issue in the operation (which is continuous improvement), or we realize that we should have included this factor in the original plan (we modify the working theory).

Either way, our knowledge of the process is improved.

In reality, these two cases – micro and macro – point to the same thing. We need the macro (the theory of management) to reflect that we need to incorporate this thinking into the way we manage everything.

Support vs. Involvement

I spent last week teaching three sessions of Job Instruction. One session at the end of night shift starting at 5am, the second session catching the start of day shift at 7am, then the third session for swing shift at 1:30.

What is cool, though, is there is a senior member of the site leadership team in every session. They are not just observing, they are active participants.

Next week those leaders, with input from the team members in the class, are going to caucus and discuss the ramifications and how to deploy this method across their operations.

This is critically important because just teaching a few dozen people a skill and expecting them to each apply it independently doesn’t work. The company has to also develop the ecosystem that it can flourish in.

But this has been the pattern from this company from the beginning.

The Operations Manager has been leading the operations kaizen teams, working hard along side the team members to develop disciplined, effective pull systems. This is a high-variety product mix, with lots of different routings, so there were some real challenges to overcome. I was really impressed with their application of what would normally be very advanced thinking.

Results? Over the last six months, their metrics have taken a clear turn upward. You can see the inflection point on the graphs. Their company sister operation is starting to take notice. Good things all around.

A plant manager once shared a conversation he had with his CEO. The teaching is important, but what makes it work is willingness to be taught.

When we talk about management involvement, this is the crux. This team has been curious, willing to try and explore things – in front of their team members – and willing to keep at it until they figure out how to make it work.

That’s what it takes.

What Are You Sharing? What Are You Learning?

A common topic of discussion in many companies is how to document and share what has been learned as they improve their processes.

The most common approach is some kind of database (either online or on paper) that documents the various “best practices” solutions to various problems.

They might, for example, show the before and after of the development of a work cell, how their visual controls are set up, or a particularly clever tool or gadget they developed.

Perhaps not so surprisingly, these bits of information turn out to be far less useful than people think they should be.

Why is that?

Let’s back up a bit and look at a larger scale.

Toyota, and other companies that are doing these things well, have all been pretty open about letting people come on and see what they are doing.

Other companies seeking to benchmark these companies then want to find one that faces similar types of problems, say “low-mix / high-volume production” or similar process flows.

Our community has developed a sense of what a “lean system” looks like. We express it in terms of the solutions to problems that have been developed.

Work cells.

Kanban.

Clever tools or gadgets.

But we also (hopefully) know that seeing examples of these things with the intent of copying them doesn’t really help that much.

Oh, they can be copied… but the track record for sustaining is pretty poor.

Nope, we know (again, hopefully) that it is not about the solutions, but about the process of solving the problem. In other words, it is the method used to develop the solutions that is important to grasp. Seeing the solutions after the fact actually gives very little insight into how to develop the skills required to do it yourself, or sustain it yourself.

OK, back to the original topic.

IF we know that copying another company’s solutions doesn’t work very well, and that we need to instead get a grasp of the thinking process that resulted in those solutions, then what should we be sharing internally, and how should we be sharing it?

The classic way to share is with a single page that says “Before Kaizen” on one side, and “After Kaizen” on the other. There might be a space for “problem” but when it is filled in, the words are usually pretty superficial. 85% of the space is devoted to a couple of pictures.

Even if it does state the problem clearly, it still doesn’t get into the process used to solve the problem.

Nor does it get into what was learned about the process of solving problems.

Now… before you leap in and say “Sure, that is what an A3 is for!” I will agree with you. Except that unless an A3 is written with that specific purpose in mind, most of the ones I have seen tend to do little better than the Before-and-After pages. Or they are so full of charts and graphs that they are really impossible to follow.

In other words, they are too complicated to convey the message, because the intended message wasn’t clear when they were developed..

It really comes down to intent.

If you are trying to share, be crystal clear on what you are sharing. What are you trying to communicate?

I believe it would be far more valuable to depict where your problem-solving process was faulty, what mistakes you made, where you went back and corrected yourself, and what you want to pass along about problem solving.

That would be a far more useful for the next person to come along.

Mike Rother: Time to Retire the Wedge

Note – this post was written pretty much simultaneously with a post on the lean.org forum.

Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”

Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.

The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.

Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.

There are some interesting assumptions embedded in the “wedge thinking.”

The first one is that “the standard can be ‘held’ by the people doing the work.

That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”

With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.

Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)

This is the approach of control. The standard is fixed until we decide to change it.

Taiichi Ohno didn’t teach it this way.

Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.

Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.

We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.

The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.

Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.

The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.

I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.

It is time to actively refute the model.

If you own your corporate training materials, find that slide (it is in there somewhere) and change it.

If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”

“What, exactly do you expect the team member to do?”  That sparks an interesting conversation which reveals quite a bit.

“Find the Bright Spots”

One of the problems facing all of us – from pundits to practitioners alike – is “too much information.” We look at a complex state, like the way Toyota operates, try do describe it in great detail, break it down, build models, and say “OK, make it look like that.”

So one of the most common questions is “Where do I start?”

The platitude is “start with 5S” but in reality, that doesn’t really work very well either. It doesn’t really drive a cultural and behavioral shift. If you have to audit people into compliance, that’s how it is working for you.

What we know today is that TPS is much less about how it looks than it is about what people do.

I have seen a handful of other companies who have managed to get a true continuous improvement culture running (at least for a while). There is something very different about them vs. a standard “lean implementation.”

Yet these companies have the same caliber of people, the same resources, the same baseline problems as everyone else. They operate in the same environment, and yet operate differently.

A key point in Switch is “find the bright spots.” That is – look at who has success in the same environment, and grasp what few factors are actually making a difference.

Perhaps, rather than “looking for waste” we ought to be looking at what few things make a big difference. Just a thought.

Ambiguity and Perfect Plans

One of the paradoxes of TPS is the inherent distaste for ambiguity. A TPS practitioner doesn’t like to leave things to hope and chance that someone will work it out.

What makes this a paradox is that we simply can not see accurately more than a few steps ahead. The world just has too many variables that we can’t control.

And even if there IS the possibility of developing a 100% certain plan – a set of instructions that simply require execution, actually doing so is overwhelmingly complex.

Consider this trivial example.

Here is game #9121 in Microsoft Freecell:

Freecell-start

If a Freecell game is winnable (and there are a very few that are not), then by looking at the starting point it is theoretically possible to construct a list of moves which will result in a win.

Game 9121 is winnable. I guarantee it.

OK – given that you know are certain there IS a winning combination of moves, please look at this starting point and develop a plan – a list of the moves which will result in a win. Let me know when you are done, then we will try to execute and see if you are right or not.

Done?

Great. How did that feel?

Keep in mind that you have two real advantages here –

  • You knew that winning the game is possible – there is a solution to the problem. In the real world, that isn’t always the case.
  • This is a simple game. It is trivial compared to even the simplest real-world cultural and technical change problem.

Yet, in spite of those advantages, you probably didn’t see a really clear path from the starting point to the final state.

Now, take a look at this state of the same game:

Freecell-2 moves to go

If you know anything about the game, you know that, with two more moves, the rest of the cards will be free to auto-clear to the top. (the five of clubs / four of diamonds to a free space – which will auto-clear the two of clubs; then the queen to either a free space or to the black king)

This state requires no challenge at all. What to do next is obvious, it is simply a matter of doing it.

In the middle of the game, though, it looked like this:

Freecell-middle

To the experienced eye (which I have, sadly), this game is clearly winnable from this point. We aren’t down a dead-end condition that has no path out.

The next couple of moves are pretty clear, and I am 100% confident those moves will, in turn, reveal more, and the game will be won. (Truthfully, it reached that point much earlier, but wasn’t as obvious as it is here.)

Scripting the moves from this point is still more difficult than just playing them, though.

So what’s the point here?

As you construct improvement objectives and plans –

It is impossible to script every single move from the beginning. What you can do is be clear where you are trying to go, understand the rules, and be willing to try a few things and back out if you end up at a dead end.

It is important to have an overall strategy in mind. That gives you intermediate targets and goals that, if reached, should be progressing you toward the final objective. In this game, for example, I am generally trying to free up the aces, and build stacks on kings. Anything that advances me toward those intermediate goals is also advancing me toward winning.

Once the solution is obvious just execute it. Don’t call it “problem solving” or patronize people by making them build an A3 for something that requires no thought.

Seeing clear progress is important. So is a general sense that the game is winnable. Without that, people lose hope, which they demonstrate by losing interest.

The “Lean Plan”

In yesterday’s book review of Switch I alluded to the idea that a “lean implementation plan” is not so much about when and where to deploy the tools as it is a plan to shift the default behavior (‘the “culture”) of the organization.

This doesn’t mean you don’t deploy the tools. Of course you do.

But you have to do more.

The tools deployment has to have a purpose that goes beyond just creating flow.

The purpose is to shape the environment, at a manageable pace, so people have the opportunity to develop and practice the new skills and behaviors that you need.

Since most of us use “kaizen events” in one form or another, let’s take a look at our core intention during that week.

Do you have explicit learning targets as the foundational purpose? Or are your objectives expressed strictly in technical terms?

As you prepare for the event, are you studying, not only the process, but how people interact with that process? Are you grasping the current situation of the culture as well as the process itself?

Are you defining a clear gap between the behaviors you need (the target) and the behaviors you observe?

Are you structuring your week to have daily learning objectives that people have demonstrated, as they try to put the improvements into place?

You can’t complain that “people aren’t supporting the changes” if you haven’t been clear about what “supporting the changes” looks like.

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

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.