What Follows “Yes, but…”

I am in the process of (finally!) reading Mike Rother’s great book Toyota Kata. The book has already gotten great reviews out there, and I am not going to contribute a lot more to that dialog except to say I think it is the first substantial addition to community knowledge about TPS since Steven Spear published his dissertation in 1999.

As I go, I am taking notes of thoughts that are provoked, and I will share a few of them as they come up.

Early in the book, Rother makes a clear distinction between managerial systems that try to cost justify each and every activity, and those which have their focus on an ideal future state.

He cites a number of examples of how the dialog in these companies is shaped by this vision, or lack of it. This is one:

Almost immediately the assembly manager responded and said, “We can’t do that,” and went on to explain why. “Our cable product is a component of an automobile safety system and because of that each time we change over to assembling a different cable we have to fill out lot traceability paperwork. We also have to take to the quality department the first new piece produced and delay production until the quality department gives us an approval. If we were to reduce the assembly lot size from five days to one day we would increase that paperwork and those production delays by a factor of five. Those extra none-value added activities would be waste and would increase our cost. We know that lean means eliminate waste, so reducing the lot size is not a good idea.”

The plant manager concurred, and therein lies a significant difference from Toyota. A Toyota plant manager would likely say something like this to the assembly manager: “You are correct that the extra paperwork and first-piece inspection requirements are obstacles to achieving smaller lot size. Thank you for pointing that out. However, the fact that we want to reduce lot sizes is not optional nor open for discussion, because it moves us closer to our vision of one-by-one flow. Rather than losing time discussing whether or not we should reduce the lot size, please turn your attention to those two obstacles standing in the way of our progress. Please go observe the current paperwork and inspection process and report back what you learn. After that I will ask you to make a proposal for how we can move to a one day lot size without increasing our cost.” [emphasis added]

To this hypothetical Toyota manager, the ideal state is achieving one-by-one flow, on demand, in sequence, as requested, without waste. He sees the drive toward this ideal state as the method to drive the next problems to the surface which, when solved, will remove a round of waste from the process.

There are a number of key points to take away from this.

Avoiding waste vs. removing waste. The assembly manager is confusing the avoidance of wasteful activity from removing wasteful activity from the process. The large lot sizes are avoiding wasteful activity, but it is still there, lurking under the surface as a barrier to further improvement.

One-by-one flow as a crucial goal. In this example, the concept of one-by-one (or one piece) flow worked exactly as it should. The discussion, or attempt, to implement the next step in that direction revealed the next barrier that must be addressed on the way. Without the imperative to reduce lot size toward that ideal, these reasons, justifications, barriers, excuses prevail and the wasteful activity remains. Yes, its effect can be mitigated by larger batches, but applying that logic, why not make the batches even larger?

It isn’t about what waste you can remove. It is about what wastes must be removed to achieve the next target condition. Having this sense of the ideal to define the direction of progress focuses the team on removing the next barrier to higher performance. This keeps things on a path toward higher system performance. Contrast this to the classic “drive by kaizen” approach where we go on waste safari and then look for opportunities where waste we can remove the most easily. This results in a patchwork of improvements that rarely find their way to the bottom line.

Cost justification would say leave the waste there. The cost justification for reducing lot sizes comes primarily from the reduction of inventory holding costs. Unfortunately, unless the inventory is insanely expensive (like jet engines), that alone rarely justifies the effort. But this thinking also stops any further opportunities for improvement in their tracks.

On the other hand, if the goal is to drive toward the ideal of one-by-one in a way that does not increase cost, then once this single-day lot size is achieved, they would be asking “What will it take to get to half a day?” Eventually they will be asking about every part every day. And then true mixed one-item-flow.

At each juncture an important thing happens. They must confront the next problem, and the next waste in the system. They must find a way to remove that wasteful activity without increasing cost. Eventually they will be making one cable each takt time, and following that, making the cables and installing them immediately.

To get there all of the inspections and traceability paperwork requirements will either be removed as no longer necessary or will be built in to the process itself. How will that be done? I don’t know. Nobody knows. That is the point. We can’t solve all of the problems ahead of time, nor can we solve them before they are discovered. The path to the ideal state is vague and unknowable when you begin. It is revealed step by step, as you take those steps.

The key is to have faith that, among all of the people in your operation, someone will find a way to crack that next problem.

This is how you harness people’s creativity.

In his classic JIT Implementation Handbook, Hirano says to force one piece flow to reveal the waste in the system. That was in 1988. Rother introduces the critical human element into the equation. One piece flow is not an abstract concept, it is a critical guide for management decision making.

Rother goes on to make other examples. In each case, the tool or technique – such as takt time or leveling – specifies how we want things to work. That provides a baseline for comparison so we can see the problems we need to work on next.

Here is another example. Ironically, while Rother uses it in his book, I have experienced it in real life. The factory is trying to introduce leveling. They set up a stock of finished goods. They set up a kanban leveling box, and they set up a fairly well thought out process of leveling the demand on the production stock, allowing the inventory to absorb the ups and downs. Their rule is that if the inventory hits a high or low limit, they will take action and assess what is happening.

Then the email arrives – “A big order arrived, and flushed out our inventory, we had to catch up, what do we do?”

After doing what is necessary to recover the system, this was a great opportunity to look at why orders arrive in big batches. In this case, I suspect it was an artifact of the company’s distribution network. The plant is at a critical crossroads.

Each of these examples leads me to the same thought.

The “Yes, but…” and the “Now what?” situations are going to happen. They prove the system is working to surface the next problem to be worked on. The reply that follows decides the fate of your improvement process.

You can reply the way the Toyota manager did in Rother’s example, and work hard to improve your process.

Or you can buy the Basic Story that is presented, and in effect agree that no further improvement is possible on this process, or that “lean doesn’t work for us because [put your “unique situation” here]”.

Which do you do?

An Exchange with Michael Ballé

Click image for Amazon.com listing

Background –
In my original comments on The Lean Manager, I compared The Lean Manager‘s story structure to that of Eli Goldratt’s classic The Goal.

This started a rather deep email exchange with Michael Ballé that goes far deeper into the book and the thoughts behind it than any review I could ever write.

With Michael’s permission, here is that exchange, with minor editing mostly for readability and flow.

My words are in blue.

Michael Ballé is in black.

Text [in brackets] are my additions to help context.



Here’s the acid test:
Would you agree that Jenkinson play a different role from Jonah [in “The Goal”] ?
(hint: he is the lean manager :))



Michael –

Actually, no, I don’t think Jenkinson plays a dramatically different role than “Jonah.”

Perhaps if the story had been written from Jenkinson’s viewpoint, with insight into his thoughts and worries about Andy, rather than a third-person view of his actions and words, I would agree. Then it would be about Jenkinson AS a lean manager.

But what we have is Andy Ward’s experience of Jenkinson. Thus, I don’t get any particular insight into what Jenkinson is actually thinking about how to get his message across to Andy except in the moments when he shares his thinking in conversation with Andy.

For example, Jenkinson (and Amy and Bob) are driving the concept of the problem solving culture from the very beginning. But Andy isn’t “getting it” until late in the story.

What was Jenkinson’s internal response to Andy’s misguided approach? What mental PDCA did Jenkinson apply when he saw the right results being gained at the expense of the social structure in the plant?

Thus, this comes across as a story about Andy Ward learning through his interactions with Jenkinson (and Amy and Bob Wood), and his experiences in trying to apply what they were telling him, rather than a story about Jenkinson’s approach to leading and teaching.

So the story is (to me) much more about Andy *becoming* the lean manager than Jenkinson “being one.”

The real difference between Andy Ward’s experience and that of Alex Rogo (his counterpart from The Goal) is that Andy’s boss is participating directly in Andy’s success vs. just issuing an ultimatum. Thus, Jenkinson embraces the role of the teacher as well as the boss.

Yes – that is exactly the message – that “leading” in the TPS is teaching. But I think [The Lean Manager] is much more about Andy learning it than Jenkinson teaching it.

The characters of Amy and Bob Woods seem to be there to add credibility since a CEO really doesn’t have this amount of time to spend with a single plant manager in a large global company. But they are so well aligned with Jenkinson’s approach that they are surrogates for him.

Thus, Jenkinson is the “teacher” in a story about Andy’s insights and development as a leader.

THANKS for asking the question.
It really made me think.



Good debate.

One of the writing issues we’ve had was that Freddy and one of his CEO friends felt Jenkinson was underdeveloped whereas Tom [the editor] and I felt he was already far too omnipresent compared to Andy Ward. The basic challenge for the book was to share the experience of what it feels like to be a plant manager stuck between the hammer (CEO) and the anvil (real life in the plant).

Jenkinson was conceived to be this Batman-like scary character. He is a teacher, but not a very good one. Basically, his one redeeming teaching feature is his patience, but, hey, the guy is a CEO. I’ve worked with several, and then I’ve spent most of my time working with the plant managers so its the latter’s pain I wanted to share. Having said that, all your points are correct, and indeed, Freddy would agree with you.

More seriously, and I hope I can convince you …that [Jenkinson’s character is not a “Jonah”] because it’s a fundamental point I’m trying to get across. As you say, the fact that Jenkinson is Andy’s boss makes it TOTALLY different from the Jonah situation. Obviously I didn’t manage to get this across well enough, but having to learn from someone who holds the sword over your head is a vastly different issue than having found a great teacher (I’d agree with Woods/Jonah), no matter how cantankerous.

This learning-from-boss issue has to be my top of the list reason why lean is spreading so slowly. So I’d argue that beyond literary devices (how many lean novel plots can there be?) this is indeed a core point of the book.

Where I’ve obviously not written this well enough is that Jenkinson IS teaching, but in a boss kind of way, which is a very different position. In particular, I’ve been very mindful (maybe even heavy handed) of the fundamental asymmetry between roles, and the whole issue of how to deal with a boss’ comments.

By the way, Jenkinson is also doing what he can with the people he’s got (can’t replace them all, right?) For instance, you’ll notice that he gets very different responses from each of his plant managers. Jenkinson’s modus operandi is to show a lean problem to the plant manager, draw a line in the sand about where he wants him next, and push him/support him to get there; As people are different, each plant takes a very different path to lean its operations and requires a different mix or arm-twisting and lecturing.

The reason we never get any direct “look” into what Jenkinson really thinks (although we do many other characters) is that I wanted to reproduce this “boss” aura – no one ever actually knows what the boss thinks. We’ve discussed this quite a bit at the time of the writing, and your comments are spot on so I’m really interested in your opinion.

[a follow-on note]

Jenkinson was actually built on what I saw my dad do when he was CEO (I was helping him at the time with expliciting the “System” – I’m a sociologist). So Jenkinson does five [six, actually] things:

1) He forces. At several points in the book, he tells people: that’s the way it’s going to be. In the German plant, in the French plant with the impromptu kaizen, with the strike, etc. Basically, he forces his managers to commit and/or do something right away IN FRONT OF THEIR TROOPS. This is a specific technique – and not an easy one.

2) He gets them to go further in their thinking. At several points, Jenkinson works with Andy to push his questioning further (not always explicitly “why?”, but it does happen. Freddy, who used to be feared because of 1), was surprisingly in the HOURS he spent doing just that. It’s equally terrifying when you’re on the receiving end because, at first, subordinates are fishing for the answer they think the CEO wants to hear, and not thinking – which makes for a lot of frustration both ways.

3) He forces people to work together, particularly when they don’t want to. Actually, Amy does this in Andy’s plant at first with the production plan issue, but Phil forces the Neville/Andy link, and later the Engineering teamwork.

4) Phil encourages “problems first” at several occasions, which is trying to tell his guys that they come to him with problems rather than let them fester, and that if he learns of the problem from someone else first, that’s bad.

5) He lectures – although this is against his own expressed principles – as he states in the car at the beginning of the book. Phil is not so enamored with the sound of his own voice as the author, but we’re still all human, right?

One more thing Jenkinson does on several occasion:

6) “Stay on target, stay on target” – Andy keeps being distracted by all sorts of things, internal politics, problems in his plant, etc. Jenkinson realigns him at almost every conversation 🙂

The two insights we have in Phil’s thinking are:
– when do I pull the plug (close the plant, fire the plant manager/regional manager/sales VP, etc.)
– dealing with the politics of senior management

In writing the [business novel] genre You’re stuck between expliciting the thinking (the lecturettes, love the word), and sharing the experience through an action scene. Then there are the limits of the author’s writing talent – I had to really sweat it before trying work within the plant as opposed to out of it (The Gold Mine), because trying to describe a working plant environment is something of a writing challenge.



Michael –

A couple of questions –
Who is the “ideal reader” – the target audience – for “The Lean Manager?”

What are the explicit teaching points the story is intended to present to the reader? What does this ideal reader take away?

What should the target reader do differently after reading the story?

What aspect of the story gives him that insight?

Did you have those things in mind as you wrote it? Or did the emerge with the story development?

I see Andy as the central character of the story. It is he who undergoes the personal transformation, and the storyline revolves around his interaction with the other characters. As you intended, is a sympathetic character that many people the in the same position will identify with.

Thus the learning from the book is transmitted through Andy, based on his experiences.

I see Jenkinson as a (primary) supporting character, who in combination with the others, shapes Andy’s experience, and through that, shapes the reader’s experience. But in the end, he is mainly a teaching character.

Yes, he is also the boss and needs the results. He leads by example. He teaches “forcing teamwork” by doing it. He makes his intentions crystal clear, does not do hollow posturing, and can play the political resistance against itself. But to Andy, he is sensei.

A good student will be motivated by wanting to please the teacher. In this case, it is also an economic / career imperative, but in the end, it is about a motivated student.

The key points of what to teach certainly come out in the process, including the fact that Andy learns a few things the hard way in spite of being told (like the teamwork thing).

But overall, it seems to be about “How to be taught” by a true lean manager more than it is “how to teach like one.”

If the key point is to teach a senior executive HOW to be a “lean manager” then I guess I’d have written it from the teacher’s perspective rather than the student’s.

If I were a CEO or senior executive, I’d like to know what Jenkinson was thinking when Andy was getting bogged down in distractions. If the target audience for the story is a senior executive or CEO, then I would think the CEO character has to be the sympathetic character, with the frustrations and problems that these guys can relate to. Then they can see he isn’t “Batman” in a comic-book city, but he is dealing with the same problems they are.

John Shook made an attempt at that in “Managing to Learn” but the scenario was too limited to really create any dramatic “ah-ha” moments.

I think Dr. Bahri’s self-experience (Follow the Learner) was a unique perspective of learning-by-doing, but, again, the scenario is too limited for most people to see beyond a medical or dental practice.

So – after re-reading my own note above, and going back to your earlier note regarding your debate about Jenkinson’s character development vs. his “omnipresent” relationship with Andy
– I guess I’d say that:

With Andy as the point-of-view character, then Jenkinson’s development is appropriate.

But if Jenkinson is actually the title character, then I can see where Freddy and his CEO friend felt that he should be more developed. The difference is that, to get that development, the perspective of the story has to shift from Andy to Jenkinson as well. Then the “omnipresence” drops away as an issue because it is about Jenkinson teaching rather than Andy being taught.

One possible follow-on story could be this shift to the teacher’s perspective. Perhaps there is a new acquisition and Jenkinson assigns Andy to mentor the manager there through a turn-around as Andy’s next development assignment. Now Andy is the teacher, (with Amy’s help, or through the A3 process with Jenkinson), and we see the teacher’s perspective as he is trying to keep the student focused on the right things in spite of the noise and chaos that, perhaps, Jenkinson is throwing at it with his demands for performance.

Andy must simultaneously understand “the main problem” in the plant, and get his student to understand it without just telling him the answers. Maybe he sees the guy as a hopeless concrete head, and Jenkinson has to force him to be patient and stick with it.

What does a competent operations manager need to learn to be able to teach someone else? How does he learn it? What is the development process for that?

Then we would have a story of not only how to BE a lean manager, but how to teach one to teach another.




The books are about 1) teaching and 2) sharing an experience. It all flows from here – I never had a target audience in mind.

The Gold Mine was all about describing TPS from the point of view of a smart guy, who’s got the power to affect changes, but has got to learn all this stuff – that was Jenkinson then. The experience I tried to share then was “The Curse Of Knowledge”.

To Jenkinson most of TPS is new and counterintuitive and every time he’s picked something up, there’s more to it (and I still experience this fifteen years later), because you don’t know what you don’t know.

And for Bob Woods, the impossibility of expressing what you’ve figured out over years to someone, hence the annoyance and grumpiness (not “Jonah” 😉 ). Add Amy, who thinks she’s getting it because the tools make sense to her, but she doesn’t understand the wider business picture nor why older people have trouble thinking that way and you’ve got The Gold Mine. Now, the trick is in

1) sharing an experience and
2) conveying the concepts, so sometimes I get it right sometimes not.

Pat Lancaster of Lantech fame, made the same type of comment [about The Gold Mine] you did: “Why didn’t you write it from the plant manager’s perspective?” To convey the absolute panic of the moment you’re about to pull the plug on the MRP. The comment stuck, and eventually that became The Lean Manager.

The gimmick in [The Lean Manager] is that BOTH Jenkinson and Andy are “the lean manager” – Jenkinson is the closest I can make it to a lean boss outside Toyota (those I’ve known anyway) and Andy is learning that stuff – with the added twist of the asymmetry of relationship that defines authority relationships.

The Gold Mine was about TPS, and this one is about Toyota Way.

My overriding problem as a consultant on the shop floor when I talk to senior execs is: “Are we on the RIGHT problems?” The problem with consultants (me included) is that they seldom understand enough of the business to focus on the right things (not a problem to Toyota consultants with suppliers, because, well, auto is auto).

So I like the idea of Amy consulting with some company and getting them to fix the shop floor and yet having no results on the business because the real problem is in engineering – where she’s got everything to learn (enter Woods & Jenkinson). If I do that, definitely “teaching the stuff” becomes an issue (since this is my specific expertise, I’ve resisted going there so far not to pollute the message too much with my socio-techno stuff)

Will have to let this one simmer for a while.

In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.

I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest (more for the next book).

The only way I know how to fight on the field of ideas is by writing books and then getting them into people’s hands. So now that it’s out, I’d like to get it in the hands as as many people as I can to try and change the zeitgeist… Not my favourite activity!


I really wanted to share this exchange with you because it highlights a couple of the main problems that are encountered in any attempt to implement real change.

To quote again from Michael’s note:

“In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.

I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest.”

And, in the end, there it is.
Ironically, if you are even reading this, you already know it.

The Lean Manager is a success story, driven by the people who are actually responsible to deliver the results. While Michael and I may quibble about whether or not Phil Jenkinson is a “Jonah” character in the sense of The Goal is a discussion about literary structure rather than the core message here. What all of these books have in common is that it is the leaders who drive successful change.

The “slow progress of lean” comes in situations where the implementation is delegated to staff with the charter to “do it to someone else.” And, in my experience (having spent a painful amount of time as that staff), that situation is far more common out there.

I have more to go on this, but I am going to leave it for another day.

The Lean Manager: Part 2 – The Basics

Click image for Amazon.com listing

This is Part 2 of a multi-part review. Part 1 is here.

In my review of Kaizen Express back in May, I took LEI to task for two things – First, I didn’t feel Kaizen Express contributed anything really new to the body of knowledge. I would have been satisfied if it had more clearly explained what had been said before, but it didn’t do that either. Second, and more importantly, I felt that Kaizen Express, and the LEI in general, were propagating the conception that the tools were what defined “lean” and that “the tools” were “the basics.” I disagreed on both points, and still do.

I am now about halfway through The Lean Manager, and I believe this book is addressing those issues – and hopefully challenging some of the thinking within the publishers. In other words, in its content, this book is everything that Kaizen Express isn’t. Get it. Read it. Do what it says, and you will actually be implementing the basics.

What makes this different? Instead of revolving around technical descriptions of the tools, this book clearly shows the proper relationship between the tools and the two most important aspects of what makes the Toyota Production System work:

  • Leaders (and how they lead and what they lead – and it isn’t implementing the tools)
  • People (yes, other books pay lip service by mentioning shop floor engagement, but The Lean Manager is all about shop floor engagement)

The authors start to hammer home the point in Chapter 2, Everybody, Every Day. In one of the many lecturettes they use to convey the key points via their characters, Amy, a corporate consultant, sums it up:

Everybody, everyday solving problems, that’s the only answer to the Pareto dilemma. You’ve got to visualize two flows in the plant. One: the product flow[. . .].  Two: the problem flow to the person who finally solves the problem. [. . .] you shouldn’t funnel all problems to your key technical people. You should protect them to work on the really difficult issues. What you have to organize is the problem solving in the line!”

And with that, the rest of the story follows – this fictitious plant manager under fire in this fictitious company sets out to do that.

The subsequent chapters (so far – remember, I haven’t finished the book yet) are Go and See, which hammers home the importance of the leaders – all of the leaders being present, not just to witness problems, but to ensure they are being solved by the right people, in the right way. Further, they must break down any barriers which impede that flow. And it’s not just the leaders. Ultimately, the entire shop floor is organized so that everyone is immersed in genchi genbutsu every time a task is carried out or work is performed. This becomes the check in PDCA.

Chapter 3 is titled Managing is Improving and begins the confront the psychological and organizational aspects of the changes that are now coming to a head in the story. This part requires the most creativity on the part of the authors, as it is an entirely human process. Because it is a human process, not a technical one, it is impossible to write a technical manual on how to do it. It requires knowledgeable, dedicated leadership that is humble enough to stake out a position that might be wrong, knowing that doing so improves the chance of learning something.

And that has been the issue in our industry. It is far, far easier to describe the tools in excruciating detail than it is to confront the leadership and organizational change issues. And because the technical descriptions predominate the literature (including, and especially what has come out of LEI for the last 10+ years), it is far easier to believe that “implementing the tools” is something that leaders can delegate to specialized technical staff.

This book, so far, is (rightly) turning that thinking on its ear.

Continued at Part 3.

The Lean Manager: Part 1 – Customers First

Click image for Amazon.com listing

I just started reading this book, and my initial feeling is that it is a winner. Rather than producing a batch review of the whole thing at the end, I thought I would employ “one chapter flow” and share my impressions with you as they are formed. As I write this, I honestly do not know where it is ultimately going.

I am excited about this book because it is challenging the decades-old paradigm of kaizen events run by specialists (while simultaneously trying to justify the change activity to the people who hired them in the first place). In its place is a leader who knows what he is doing, and appears to be starting to lead by asking tough questions.

Even with that initial endorsement, this book appears to be following the standard formula established by Eli Goldratt in The Goal.

  • Manager finds out factory is being closed. News is devastating to his personal life.
  • The Jonah character emerges and teaches him how to save the operation.
  • He applies what he learns and saves the day.

While there is nothing wrong with this structure, it is wearing a bit thin, at least to me. So I hope that the authors are going to find an interesting twist that surprises me. Still, because this is a novel with a point, vs. an attempt at classic literature, I’m not going to spend much time on the literary style.

The two main characters (so far) are Andrew Ward, the manager who finds out his plant is being closed, and Phil Jenkinson, the new CEO, with the double role of bringing the bad news (closing the plant) as well as filling the role of the Jonah (or sensei in this case, I suppose).

In the opening chapter, Jenkinson’s style is authoritative, bordering on confrontational. Without knowing the culture of this fictitious company, I can’t say whether his blunt, direct approach is from necessity or because he simply doesn’t have the skills to ask tough questions without pushing people back. I’ll hold judgment on that part. My hope is that the book doesn’t teach this approach as how it has to be done, because in my experience, it doesn’t have to work that way.

The message, though, is crystal clear. The old way isn’t cutting it. Leaders, not staff, are responsible for results (safety, quality, delivery, cost). Leaders are expected to know the hot spots in their operations. Leaders are expected to be involved in the details – not to micro manage, but to develop the capabilities of others. (That last one is a bit of an extrapolation on my part.) “Lean” is not a program, not projects run by a staff of specialists, it is how we will manage the company.

The notable quote from this chapter comes in a shop floor lecture given by Jenkensin and nicely sums up the relationship between process and results.

Results… are the outcome of a process. What we want are good results from a controlled process because they will be repeatable. Bad results from an uncontrolled process simply mean that we’re not doing our job. Good results from an uncontrolled process…only mean we’re lucky. Today, bad results from a controlled process just says that we’re stupid: We expect different results from doing the same thing over again.”

Based on that, I sketched out this little matrix that captured my response and the key points.

process vs results

But the technical nuances aside, this story is clearly developing into one about leadership. The key issues, so far, are:

  • Safety, quality, delivery, cost, are line leaders’ responsiblity, with assistance from technical staff – who are also experts.
  • Though it is certainly a culture shock, the leader is teaching by asking questions.
  • The various character’s reaction to the confrontive authoritative style is predictable. I am uneasy, at this point, with that approach being held up as an example of the best way to get this done. But it is only Chapter 1.


Jim Collins: How the Mighty Fall – Business Week

I am a big fan of Jim Collins. His book Good to Great outlines attributes that I have seen in every successful organizational transformation.

Now he has a new book out. I haven’t read it yet, so I am not going to offer a review, just tell you about it. But the title and premise is intriguing:
How The Mighty Fall: And Why Some Companies Never Give In

There is a great article and excerpt of the book on Business Week online, including  a video of Jim Collins describing the stages (preceded by a short advertisement).

In short, Collins’ research shows that a great company can fall, and when it happens, there are five stages of decline. According to Collins, Stages One through Three are invisible from outside. The company looks great, but it is rotting from within. It is only at Stage Four that things visibly go south, and they do so very quickly. But there is also good news: The company can recover and return to greatness from any of the stages one through four, but not five.

While this whole story is fascinating, it is the nature of Stage Four that brings things into pretty sharp focus for me.

The stages are:

Stage 1: The Hubris of Success. Things are going great, and the company acquires a sense of entitlement for that success. “We deserve this success because we are so good!” In Collins’ words:

When the rhetoric of success (“We’re successful because we do these specific things”) replaces penetrating understanding and insight (“We’re successful because we understand why we do these specific things and under what conditions they would no longer work”), decline will very likely follow.

I think this idea of “penetrating understanding and insight” is what characterizes the idealized Toyota Production System. It is also seen in every example that Steven Spear covers in Chasing the Rabbit.

When an organization shifts away from questioning its own success as thoroughly as its failures, and begins to assume that its continued success is simply a matter of continuing to do what they have been doing, the seeds of decline are sown.

This ship is unsinkable.

Stage 2: Undisciplined Pursuit of More.

Companies in Stage 2 stray from the disciplined creativity that led them to greatness in the first place, making undisciplined leaps into areas where they cannot be great or growing faster than they can achieve with excellence—or both.

This one really struck me. Is this the what Toyota went through in the last 5-7 years in their pursuit of #1? Clearly they overreached, even they say so. Even as early as 2003 they were seeing eroding of the TPS discipline in their North American and European plants. They shored that up, and continued their aggressive expansion of production capacity, got into big trucks, and in general seemed to bypass their traditional patient-and-relentless growth strategy.

Other industries suffered this as well. The last few years saw unprecedented (and it turned out, artificially generated) growth in sales across sectors. As one of my friends put it “When times are this good, everybody’s a genius.” Put another way, when there is more demand than supply, even a “supplier of last resort” gets great business, and it is easy to fall into the trap of thinking it is because “our products are great, and customers like us.” It is possible to carry that belief in the face of overwhelming evidence to the contrary – like customers telling you to your face that they bought your stuff because they couldn’t get it from your competitors.

Inventories start to grow, quickly, as nobody wants to miss a sale; factories are expanded, quickly, for the same reason. There is almost a fear of failure here, but it is fear of failure to get more rather than failure to succeed. If success is taken for granted (see Stage One), this one follows pretty directly.

We are going to set an Atlantic crossing speed record.

Here is a question: Who didn’t experience this to some degree over the last 5 years?

Things get interesting next.

Stage 3: Denial of Risk and Peril. There are warning signs of over-reaching, that things are not going to go this way forever. But what struck me more was the cultural aspect: Shutting out the truth.

In Stage 3, leaders discount negative data, amplify positive data, and put a positive spin on ambiguous data. Those in power start to blame external factors for setbacks rather than accept responsibility. The vigorous, fact-based dialogue that characterizes high-performance teams dwindles or disappears altogether.

When leaders start suppressing dissenting views, when they equate disagreement with disrespect or unhealthy conflict, they start insulating themselves in a cocoon of denial.

If the organization is pre-disposed to avoid conflict to begin with, then this stage is really easy to slide into. Vigorous debate is part of sound decision making. When that stops, or is never allowed to surface in the first place, the organization is self-centered and vulnerable.

When leaders start attributing the warning signs to anomalous, one-time, temporary factors – and believing they are exercising that penetrating understanding and insight when, in reality, the “analysis” is no more than the Highest Paid Person’s Opinion they have shifted from rationality to internal belief-based decision making. (also called “wishcraft.”)

Reports of ice ahead.

Stage 4: Grasping for Salvation.

The cumulative peril and/or risks gone bad of Stage 3 assert themselves, throwing the enterprise into a sharp decline visible to all. The critical question is: How does its leadership respond? By lurching for a quick salvation or by getting back to the disciplines that brought about greatness in the first place?

So things have gone to hell in a handcart, and the leadership starts looking around for how to get out of the spin. They have ignored all of the warning signs up to this point, but now they are undeniably in trouble. What to do?

As I said, this is where it gets really interesting from a personal / professional level.

There is no doubt that, at this moment, the proverbial “burning platform” exists. There is clearly a sense of urgency… Pick your clichés from “change management” literature here.

“Hey – I just read this book about lean. Let’s bring in this hot-shot consultant to lean us out.” And so it begins. The Search for the Silver Bullet – the magic that will fix everything. And it doesn’t have to be “lean.” It might be x-Sigma (put your favorite buzzword in place of the ‘x’). Maybe everybody reads The Goal and starts looking for constraints. Or the leaders leap from “program” to “program” looking for the solution. While each “initiative” is kicked off with great deliberate fanfare, in reality the leaders are panicing.

They fail to see that leaders atop companies in the late stages of decline need to get back to a calm, clear-headed, and focused approach. If you want to reverse decline, be rigorous about what not to do.

Here is my take on this. These leaders who leap from “solution” to “solution” are still in hubris and denial. They are still looking outside of themselves for the problem, and the solution.

My last post, How the Sensei Teaches, describes leaders who teach by being students. This requires humility, something totally incompatible with hubris. If they want to bring in that hot-shot consultant, they need to tell her “We really need help up here, please teach us” rather than “Go teach our people how to be lean.” They need that consultant to be a true sensei, not just a technician.

Oh – what is Stage Five? Collins calls it Capitulation to Irrelevance or Death.

My words are “The boat sinks.”

Kaizen Express – and the Lean Enterprise Institute

The Lean Enterprise Institute has recently published Kaizen Express, an overview of the classic characteristics of “lean manufacturing” and, by implication, the Toyota Production System. As I set out to review the book, I found myself heading in two directions.

One is the content of the book itself.

Over the years, there have been a slew of books with similar tables of contents that describe the various mechanics and mechanisms observed in the Toyota Production System.

The first really comprehensive reference in English was Productivity Press’s translation of Hirano’s JIT Implementation Manual. (Originally a two volume set priced at $900, it appears it is about to be published in a second edition for around $200. I have not seen the second edition.) Back in the early and mid 1980’s, Hirano was about the only comprehensive reference out there. At Boeing we had internal-use reproduction rights, and many of us poured over those volumes, parsing every word.

Kiyoshi Suzuki’s New Manufacturing Challenge (1987) was the book we gave out to all of our suppliers. It, too, provides a pretty good overview of most of the tools and techniques. It is a good basic reference, and I still believe it really takes about three years for a practitioner to outgrow it.

At a more technical level, we have had Toyota Production System: An Integrated Approach to Just-In-Time by Yusuhiro Monden. This book goes into more depth from a system engineering standpoint, and focuses mostly on “Toyota’s production system” vs. a more generic approach.

These three titles are by no means the only ones. A couple of feet of my own bookshelf is occupied with books covering the same basic topics. I only mention these three only because they have been my workhorse references, especially in the days when I was still putting together my own mental models.

Kaizen Express is well at home with this family. It is a solid overview of the tools and techniques that generally characterize “lean manufacturing” and I can quibble with nothing that is in the book.

The presentation itself harks back to the days when all of the decent references came out of Japan. It is a bilingual book, written in Japanese language and graphic style with English translation along side.

On a sidebar note: As a practitioner, dealing with shop floor people and their sensibilities and values, I would rather use a reference that didn’t come across as so foreign. While I fully appreciate that the Japanese vocabulary is a solidly embedded part of Toyota’s culture, that is not the case elsewhere, and some Toyota-trained practitioners would do well to keep that in mind. The concepts are difficult enough to get across without having to overcome language resistance. Add to that the unfortunate truth that many countries, especially in Asia, still have vivid cultural memories of a far more malevolent Japan, and the resistance just increases. I would not give a copy of this book out in China or Korea, for example. There are others which serve the same purpose without bringing up unresolved issues. Memories and emotions run much longer and deeper in Asia than they do in the West.

All of those reservations aside, this book is a welcome review of familiar material.

Now, the second part. I want to go beyond the book itself, and look at its context. This becomes not so much a review of the book, but one person’s opinion (mine, to be sure) of the state of our communities understanding of the Toyota Production System itself.

The TPS is somewhat unique among all of the various “management systems” in the popular business press today in that it grew organically rather than being explicitly designed. Thus, rather than consult standard documents to learn about it, knowledge comes from research.

In the early days, through the late 1980’s, the topic of “JIT” or “Japanese manufacturing techniques” was a quiet, esoteric backwater of consultants and a few committed practitioners. We knew about Harley Davidson, and some of the other early adopters. Danaher was just getting started, and some of the household name early leaders were starting to gain meaningful experience and reputations. The knowledge base came from practitioners trying to make it work, rather than professional academics who are in the business of developing and testing rigorous theory.

In late 1990, everything changed. The Machine That Changed the World by Womack, Jones and Roos published the results of good, solid research from MIT and became a hot seller. It broke out of the practitioner’s technical corral, got the attention of mainline executives and managers, and introduced the buzzwords “lean production” (which later morphed into “lean manufacturing”) into the lexicon of everyday business.

This was followed by Lean Thinking which profiled a number of these companies and put Shingijutsu on everyone’s radar.

The Lean Enterprise Institute was founded shortly thereafter, and in the late 1990’s published Learning to See and introduced everyone to value stream mapping. This was the first of a series of workbooks designed to take the practitioner through the mechanics of implementing various aspects of the basic elements of modern manufacturing techniques.

These workbooks were something new. Rather than the encyclopedic approach of a single book devoting short chapters to descriptions of the various tools, these workbooks went into much more depth on a single topic, such as materials distribution, creating a work cell, the basics of heijunka or mentoring someone through solving a problem.

In the background of all of this, “lean manufacturing” became the hot topic. Writers, consultants, managers were all talking about how to “get lean” and to “lean out” a business. Hundreds of books were published on the topic, a few of them good, many of them re-hashing old stuff in new ways, a few just using the buzzwords to sell bad information.

This explosion resulted in a lot of noise pollution. What had started as peer-reviewed academic research of the automobile industry turned into the “lean industry” – a crowded, bustling bazaar with everyone hawking and touting their “solutions.” This, by the way, included a mountain of junk academic research.

But there was also some really exceptional academic research, especially out of Harvard. While everyone was busy implementing the tools of lean – the things in the tables of contents of all of those books, the success rate was a far cry from the promise. I have experienced this myself a couple of times. But Steven Spear made it the topic of his 1999 groundbreaking PhD thesis at Harvard. Let me quote, and offer my interpretation, of a few key sentences from the abstract of his dissertation.

Researchers have established that Toyota enjoys advantages in cost, quality, lead-time, and flexibility when compared to its competitors in automotive assembly.

There is no doubt here. It’s why we are all reading this stuff in the first place! And while there was considerable anecdotal evidence before that, The Machine That Changed the World offered up a solid base of good research to confirm what everybody was thinking.

Differences in generating value have been attributed to differences between the Toyota Production System (“TPS”) and alternative management systems. Distinctive tools and practices have been associated with TPS.

Those “tools and practices” are what are covered in the classic books I cited earlier. They are also what is covered in Kaizen Express if not by industry in general, certainly by the community of experts.

However, evidence suggests that merely copying these [tools and practices] does not generate the performance advantages enjoyed by Toyota. This has prompted several questions … [including] … why is it so difficult to imitate?

So we (the community of experts) were happily out the there doing the stuff that was in the books, teaching the basics, trying to implement them, and finding it generally difficult to get a lot of traction once the initial novelty wears off.

Meanwhile, the noisy bazaar continued to churn out more and more “solutions” aimed at the “gaps in lean manufacturing.”

“Lean looks at waste, but doesn’t address variation…” so “Sigma” was spliced in. Yet Toyota obsesses on stability and eliminating variation at levels we cannot even fathom.

“We need someone to implement quality in our lean company.” Hello? How can you leave out quality? Yet in our efforts to implement flow and reduce inventory, we did it all of the time!

We try to bring kaizen into administrative and creative process flows – well enough, but upon finding that the “tools and techniques” need to be adjusted somewhat, people draw the conclusion that there is more to it.

All of these things, over the last ten or fifteen years seemed to make things very complex indeed.

So we go back to the basics.

I agree with the principle. But we need to discuss exactly what the basics are.

The second paragraph of Steven Spear’s abstract is pretty clear:

… the tools and practices that have received attention are not fundamental to TPS.

(emphasis added)

Then he brings up things that the rest of us never talk about:

… the … Rules-In-Use promote distinctive organizational features. These are nested, modular [organizational] structure; frequent, finely grained self-diagnostics; and frequent, structured, directed problem solving that is the primary mechanism for training and process improvement.

(emphasis added) (For explanation of what Spear means by “Rules-In-Use” read the dissertation itself, or Decoding the DNA of the Toyota Production System, which is the HBR summary of his conclusions. Personally, I “got it” a lot better from the dissertation, but then he has 465 pages to make his points vs. 10 pages in the article.)

What has all of this got to do with the little green book, Kaizen Express?

I think it is a great book, for 1991.

But this is 2009. So while Kaizen Express is a welcome refresher of the mechanics, those mechanics are, according to the current standing theory, built upon a foundation of something that Kaizen Express, and for that matter, the LEI has not, to date, addressed. What is missing, in my view, is how the tools and practices outlined in Kaizen Express and its predecessors actually drive daily continuous improvement that engages every team member in the process.

Anyone out there is perfectly welcome to refute Spear’s research and make a compelling case that “the fundamentals” are, indeed, the things addressed in Kaizen Express. But to do so means bringing credible peer-reviewed, published research to the table. It means building a compelling case of documented observations that contradict Spear’s theory. Anything else is simply conjecture.

My challenge to the Lean Enterprise Institute: Your organization is unique. It emerged from the world of academia with very solid credentials, with a great mission to carry this message to the non-academic world. Because of its academic origins, LEI has a real opportunity to be the bridge between the cutting-edge understanding coming out of these top-flight research institutions and translate it into practical things the rest of us can put to use. Extend your charter to taking PhD words like “nested modular structure” and “frequent finely grained self-diagnostics” and giving the daily practitioners some workbooks that lay out how to do it.

Kaizen Express is a great little book.

LEI can do better, though, than to re-publish material that has been out there since 1988.

TPS Failure Modes – Part 1

Following on from the buzz created by the last couple of posts, I would like to go back in time a bit.

In 2005 Steven Spear wrote a working paper called “Why General Motors Lost and Toyota Won.” A reader can clearly the see emerging themes that were developed into his book Chasing the Rabbit .

Spear talks about the leverage of “operationally outstanding” in changing the game, the capabilities he sees in “operationally outstanding” organizations, then “Failure Modes at Becoming Toyota Like.”

I would like to dwell a bit on these failure modes, and reflect a little on what they look like.

Failure Mode 1: Copy Lean Tools Without Making Work Self Diagnostic

So what does “self diagnostic” mean?

For something to be “self diagnostic” you need two pieces of information:

  • What is supposed to happen.
  • What actually happens.

Then you need some mechanism that compares the two and flags any difference between them. This sounds complicated, but in reality, it isn’t.

Let’s look at a common example: At the most basic level, this is the purpose of 5S.

5S as a Self Diagnostic Tool

In 5S, you first examine the process and seek to understand it. Then, applying your best understanding, you decide what is necessary to perform the process, and remove everything else. Applying your best understanding again, you seek to locate the items where they would be used if the process goes the way you expect it to.

You improve the self-diagnostic effect by marking where things go, so it immediately clear if something is missing, out of place, or excess.

Then you watch. As the process is carried out, your “best understanding” is going to be tested.

Can it be done with the things you believed are necessary? If something else is required, then you have an opportunity to improve your understanding. Get that item determine where it is used, and carry out the operation. But go a little deeper. Ask why you didn’t realize this was needed when you examined the process. Challenge your process of getting that initial understanding and you improve your own observation skills.

Is everything you believed is necessary actually used? If not, then you have another opportunity to improve your understanding. Is that item only used sometimes? When? Why? Is it for rework or exceptions? (see failure mode #2!) Why did you believe it was necessary when you did your initial observation?

Does something end up out of place? Is it routinely used in a place other than where you put it? This is valuable information if you now seek to understand how the process is different from what you expected.

Now think about the failure mode: What does fake-5S look like? What is 5S without this thinking applied?

How do you “do” 5S?

Look long and hard if you are trying to audit your way into compliance rather than using it as a diagnostic for your understanding of your process.

Though the jargon “self diagnostic” sounds academic, we have all talked about visual controls “distinguishing the normal from the abnormal” or other similar terms. It is nothing new. What makes this a failure mode is that people normally don’t think it is that important when Spear cites a mountain of evidence (and I agree) that this is critical to success. You can only solve the problems you can see.

Another Example: Takt Time

What is takt time? Before you whip out your calculators and show me the math, step back and ask the core question of “What it is” rather than “how to calculate it.” What is it?

Takt time is part of a specification for a process – it defines what should be happening. By setting takt time you are saying “IF our process can routinely cycle at this interval, then we can meet our customer’s demand. Takt time defines both part of a “defect free” outcome of your work cycle as well as a specification for process design.

Then you apply your very best knowledge of the process steps and sequence and set out a work cycle which you believe can be accomplished within the takt. It becomes self-diagnostic when you check, every time if the actual work cycle was the same as the intended work cycle. An easy way to check is to compare the actual time with the designed time.

In Decoding the DNA of the Toyota Production System, Spear cites an example of seat installation.

At Toyota’s plants, […] it is instantly clear when they deviate from the specifications. Consider how workers at Toyota’s Georgetown, Kentucky, plant install the right-front seat into a Camry. The work is designed as a sequence of seven tasks, all of which are expected to be completed in 55 seconds as the car moves at a fixed speed through a worker’s zone. If the production worker finds himself doing task 6 (installing the rear seat-bolts) before task 4 (installing the front seat-bolts), then the job is actually being done differently than it was designed to be done, indicating that something must be wrong. Similarly, if after 40 seconds the worker is still on task 4, which should have been completed after 31 seconds, then something, too, is amiss. To make problem detection even simpler, the length of the floor for each work area is marked in tenths. So if the worker is passing the sixth of the ten floor marks (that is, if he is 33 seconds into the cycle) and is still on task 4, then he and his team leader know that he has fallen behind.


On this assembly line, time is used, not so much to pace the work, but as a diagnostic tool to call out instances when the work departs from what is intended – or in simpler terms, when there is a problem.

All of this has been about checking that the process is being carried out as expected. But, bluntly, the customer really doesn’t give a hoot about the process. The customer is interested in the output. How do you know that the output of your process is actually helping your customer?

To know that you first have to be really clear on a couple of things:

  • Who your customer actually is.
  • What value do you provide to that customer?

Put another way, can you establish a clear, unambiguous specification of what a defect free outcome is for each supplier-customer interface in your process? Can you follow that trap line of supplier-customer interfaces down to the process of delivering value to your paying customers?

To make this self-diagnostic, though, you have to not only specify (what should be happening), you have to check (what is actually happening), and you have to do it every time.

So poka-yoke (mistake proofing) is a way to verify process steps. Other mistake proofing will detect problems with the outputs. All are (or should be) designed to diagnose any problems and immediately halt the process or, at the very least, alert someone.

The theme that is emerging here is the concept of PLAN-DO and CHECK, with the CHECK being thoroughly integrated into the process itself, rather than a separate function. (Not that it can’t be, but it is better if CHECK is continuous.)

The Supply Chain

I was walking through the shop one afternoon and spotted an open bundle of steel tube – about half of them remaining. They used kanban to trigger re-order. The rule of kanban is that the kanban card is pulled and placed in the post when the first part is consumed. To make this clear, they literally attached the kanban to the bands with a cable tie. Thus, breaking the band would literally release the kanban. Simple, effective.

But, though this bundle had been opened, there was the kanban card still attached to the (now broken) banding. It was lurking at the base of the pallet, but visible.

I went and got the supervisor, and told him that “You are going to have a shortage of 4×5 tube on Wednesday, and it is your fault. Would you like to know why?” I guess I should point out that I had a pretty good relationship with this guy, so he knew I was playing him a little. Then I just said “Look, and tell me what you see.”

It took a few seconds, but he saw the kanban, said “Argh” and started to pick it up to put into the post. I stopped him and asked if it was his responsibility to do that. No, it was the welder’s responsibility. “Then you should take a minute with him, and do what I just did with you.”

Then I asked him how often the kanban cards were collected. (I knew, I wanted to check that he knew.) “Daily, about 1 pm.”

“How often do you walk by here every day?” He said at least twice, in the morning and right after lunch. “So all you need to do is take a quick glance as you walk by, twice a day, and you will always get that kanban into the post before 1pm.”

He did, and their periodic shortages dropped pretty much to zero.


First, the system was set up JIT. We knew the expected rate of use of that part. We knew the supplier’s lead time and delivery frequency. We knew the bundle size. MATH told us the minimum number of kanban cards that would need to circulate in this loop to ensure the weld cell never ran out… unless one of the inputs was wrong or unless the process operated differently than we expected.

We also knew that, given the rate of consumption, how many bundles should be in the shop at any given time, and we had space market out for just that amount. Thus, we could tell immediately if something was received early, or if our rate of consumption fluctuated downward. (Because a pallet would arrive, but there would be no place to put it.)

We could have just had a Team Member come by once a day and check if a bundle had been opened, and send an order to replenish it. We could have been even more sophisticated and just set up a barcode scan that would trigger a computer order.

But if we had set up the process that way, how could the Supervisor distinguish between “Ordered” or “Not Ordered?” It was that stray out-of-place kanban card that told him.

Bin with kanban cardThus, physical kanban cards, physically attached to the materials, represent a self-diagnostic check. If the card is there, then that container should be full. Quick to check. If the container is not full, there should be no card. Quick to check. If a container arrives with no card, it was not properly ordered and is likely excess (or at least calls for investigation). Quick to check. The physical card, the seeming crude manual operation, provides cross-checks…self-diagnosis… simply and cheaply in ways that few automated systems replicate.

So far these have all been manufacturing examples. But Spear is clear that all work is self-diagnostic, not just manufacturing.

What non-manufacturing work fits into this model?

(Hint: All of it.)

What about a project plan? Though in reality, most project plans don’t. Read Critical Chain by Goldratt to understand the difference – and produce and manage project plans that are much more likely to finish on time.

What about a sales plan? Do you predict your monthly sales? Do you check to see if week 1 actual sales deviated from what was expected? Do you plan on activities that you believe will hit your sales targets? Which customers are you calling on? What do you predict they will do? (Which tests how well you really know them.) Do you actually call on those customers? Do they need what you thought they would? Or do you learn something else about them? (Or do you make a best guess “forecast” and wait for the phone to ring?)

Once you have a sales plan, do you put together a manufacturing and operations plan which you believe will match production to sales? How much variation do you expect to accumulate between production and sales over the course of that plan? Do you put alarm thresholds on your finished goods or your backlog levels that would tell you when that predicted variation has been exceeded?

How do you (and how often do you) compare actual sales (volume, models, and revenue) against the plan? Do you know right away if you are off plan? How long will you tolerate being off plan before you decide that something unexpected is happening? Is there a hard trigger point already set out for that? Or do you let the pain accumulate for a while?

A lot of companies were caught totally by surprise a few months ago when their sales seemed to fall off a cliff. Question: Did you have rising inventory levels before that? Was there a threshold that forced attention to something unexpected? Or did you increasingly tolerate and normalize deviance from your intended business plan?

At the next levels up – you have a business plan of some kind. You have financial targets. Do you have specific actions you plan to take at specific times? Do you check if those actions were actually taken? Do those actions have some kind of predicted outcome associated with them? Do you check if the actual outcome matches what you predicted? If you just “try something to see what happens” you might learn, but you might not. If you predict, then try to see IF it happens, you are more likely to gain more understanding from that experience.

When you design a product, do you have performance specifications? Do you test your design(s) against those performance specifications? Do you do that at every stage, or just at the end?

When you say “We need training” have you first specified what the work process is? Have you studied the situation and determined that people do not have the skills or knowledge to do the job? Have you specified what those skills are?

Have you developed the training to specifically develop those skills? Do you have a way to verify that people got the skills required? Do you check if, now, they can perform the work that they could not perform before? If you didn’t do the last, why did you “train” them at all? How do you know it was not just entertainment?

“Management Is Prediction”


This quote, attributed to W. Edwards Deming, really sums up what this is about. By specifying an outcome – “defect free” (which implies you know that is), within a certain time; and by specifying the process steps; you are predicting the outcome.

“If we do these things, in this sequence, it should require this amount of time, and produce this result.”

Then do it, and check:

Does what you really had to do reflect the tasks you thought would be required?

Does the order you really did them in reflect what was in the plan?

Does the time required reflect the time you planned on?

Did it produce the intended result?

Building those checks into the process itself makes it self-diagnostic.

Try This

Go study a process, any process. Just watch. Constantly ask yourself:

How does this person know what to do?

How does this person know if s/he is doing it right?

What alerts this person if s/he makes a mistake?

How does this person know s/he succeeded?

If there are clear, unambiguous answers right in front of you – without research, without requiring vigilance or luck on the part of the Team Member, then you probably have something approaching self-diagnostic work. Likely, you don’t. If that is the case, don’t say you are “doing lean.” You are only going through the motions.

Profitable Value Streams

Lean Product and Process Development by the late Allan Ward is an interesting view into his extensive research into Toyota’s product development system. I am still reading it (along with Product Development for the Lean Enterprise
by Michael Kennedy. The books present the same basic model in different ways, though I should point out that it Kennedy is obviously a protégé of Dr. Ward.

One key point really jumped out at me, and challenges the traditional mindset of the design engineering community.

The output of product development is a profitable value stream.

Think about that for a minute. How does this mindset alter the focus of the design engineering subtask of product development?

Is Your Lean Implementation Sticky or Slick?

My posts about “Made to Stick” and visual controls created some interesting responses on Jon Miller’s Gemba Panta Rei blog, so I want to continue the great dialog. Jon asks the great question “Is your lean deployment made to stick?” and extends the context from just visual controls to the entire concept.

Of course this level of thinking is the author’s intent in the book. I’d like to ask you, the reader and change agent, some questions that might help you see if you are obscuring your own message.

What is core message of your implementation?

The words “vision” and “mission” are so worn out today that people are cynical. And with good reason. By the time the board rooms are done with wordsmithing, there is no content left.

When I was growing up, current events in the USA were dominated by two stories:

  • The war in Vietnam.
  • Sending people to the moon.

Both were major undertakings and consumed a lot of talent and resources. Consider the core message for each.

Vietnam: Bad things will happen if we leave.

The Moon: “…achieving the goal, before this decade is out, of landing a man on the Moon, and returning him safely to the Earth.”

Which is those is “sticky?” Which one captures the essence of True North so that everyone just knows not only what we are trying to do, but how they can contribute?

Take JFK’s commitment and put it in the language of a typical corporate mission statement: “We will be a world leader in space exploration.” Yawn. How will we know when we get there? Exactly. It is a very safe goal since it allows redefining success at any point.

Kennedy’s commitment is simple, concrete, credible, emotionally appealing, and made a hell of a story. How does yours stand up?

But we so-called “lean professionals” are by no means off the hook.

What is the core message of the TPS?

That is a little tougher to get to. Why? My theory is that we “professionals” are all cursed with what Heath and Heath call “the curse of knowledge.” We understand the nuances and details of how all of the pieces fit together. The question is: How much of that wealth of knowledge passes the “So What?” test. What is the lead story?

When you start talking about takt time, work sequences, cycle times, kanban loops, andon signals, painting lines on the floor, all of the so-called “tools” of the TPS, do people’s eyes glaze over? What ties it all together? What is the central theme, the core message?

I’ve re-written this paragraph about a dozen times. How can we get it down to Herb Kelleher’s “Southwest is the low-fare airline” (p 29 in the book) and not lose anything?

I think, at its fundamental core, the Toyota Production System is “A structured work environment which captures people’s creativity and focuses it solving problems every day.”

The next line in the story: “All of the tools, techniques, principles that people associate with the Toyota Production System are simply the best currently known mechanisms to surface problems, or they are the best currently known countermeasures to common problems.”

Nope, that is still to complicated.

The Toyota Production System structures the organization and the work so that people can solve problems to save time.

That comes closer. I think a test question: “Does that save time?” (without compromising safety, quality or the customer in any way) would usually discriminate between a good idea and a bad one.

Readers – there is no way on Earth (or the moon) that I have got this right, or even close, sitting here in a Beijing apartment at 11pm on a muggy Saturday night. My challenge is: in one sentence, as direct as “The low-fare airline,” capture the core message of the TPS in a way that guides decisions toward True North.

Next – your training.

Most of us use some kind of training materials. Question: Does each topic have a lead? Does it build the story? Does it tie to the top story? As you go into more depth, are the interconnections more and more apparent? Do you tie everything back to the TPS Lead Story? Failure to do these things decomposes the system. It gives people the impression they can pick and choose the tools vs. understanding that they all are doing the same thing in different contexts. It implies there is some kind of set-piece sequence of implementation.

Are your examples concrete? Are they things people can go do?

Do you build a shared experience base by telling stories? Or do you deliver abstract, cold, analytical bullet lists of “the three elements of standard work?” Who cares? Obviously they are important, but how well do you communicate exactly why balance to the takt time contributes to the effort of surfacing and solving problems?

OK – it is late, and I am rambling. I hope I have provoked a little thought.

I originally titled this piece “Is Your Lean Implementation Velcro or Teflon?” But Velcro Industries has enough challenges protecting their trademark without me making it worse.

Made To Stick

Why Some Ideas Survive and Others Die
In Made to Stick, Chip and Dan Heath have addressed head-on one of the biggest problems with implementing change in people’s thinking and behavior — crafting the concept in a way that makes it compelling.. “sticky” in their words.

The book is an extension of the concept described in Gladwell’s The Tipping Point which outlines “stickiness” as one of the things required for an idea to catch on and spread.

Read this book, then take a look at your presentations and training materials, and compare the messages with the examples in the book. Make an honest assessment:

Is your message:

Simple? Is the core concept immediately apparent?

Unexpected? Does it come across in a way that compels retention?

Concrete? Do analogies and examples make the concept something people can see, touch, feel in their minds (or even better, physically)?

Credible? Does it just make sense?

Emotional? Does it appeal to people’s feelings, or is it “just the facts” with cold analytical presentation.

Have stories? Does the presentation include experiences people can visualize?

Other books on organizational transformation, like John Kotter’s Leading Change talk about the critical importance of creating a sense of urgency, creating a vision, communicating that vision, but Made to Stick goes further and gives you tools to actually make sure your message gets across in a way that compels people to act differently.