Lean Leadership: Kaizen is Management

Chapter 4 of The Toyota Way to Lean Leadership lays out the picture of a company where continuous improvement of operations is the primary focus of the management system.

Note here that I said “focus of the management system” rather than “focus of the managers.” I believe there is a crucial difference which I will explain in a bit.

Liker and Convis start out by explaining what “kaizen” isn’t. Sad that they have to do this, but the problem is summed up nicely:

Too often [kaizen] has come to mean assembling a special team for a project using lean of Six Sigma methods, or perhaps organizing a kaizen “event” for a week to make a burst of changes. We sometimes hear the phrase “doing a kaizen” as if it were a one-off activity. At Toyota, kaizen […] is how the company operates at the most fundamental level.

One of the persistent mysteries (to me) is why, after decades of knowing otherwise, so many businesses still consider “kaizen” or “improvement” to be a separate activity from “management.”

A few weeks ago I expanded on a great presentation by Bill Costantino that explained the relationship between challenges, targets, kaizen and the knowledge space of the company.

In that post, I created an animation of Bill’s graphic that illustrates progressive targets pushing the threshold of knowledge relentlessly toward the objective.

In this model, although we have a decent idea where we are, and what we want to end up with, the details of the path to get there are not known in advance.

Lean Leadership illustrates the same point quite well with the story of a factory kaizen team at TMMK (Toyota’s Georgetown, Kentucky facility). Of note is that this team is made up largely of production workers. It isn’t “the improvement team.” It isn’t an engineering department team. It is the people who have to live with the solution.

The team’s challenge was to improve a wasteful process for handling and moving sheet metal parts through the plant to the point of use on the assembly line.

They started by studying another company’s solution to the problem.

Did I mention that this team of factory workers from Kentucky spent two weeks in Japan studying this supplier’s system? Why make this kind of investment? Ponder that a bit, we’ll get back to this too.

Once back in Kentucky, the team had a clear sense of the challenge, and set out to progressively develop their own solution by experimentation, observation, and learning.

First they tried copying the benchmarked system on a small-scale test to deepen their understanding of what they had studied. Trying it on their parts surfaced differences that weren’t obvious at first, and they learned copying definitely wouldn’t work.

Key: The reason they tried to copy was to learn more about it. This was a small-scale concept test, not an attempt at wholesale implementation.

Even if it had worked, copying develops no skill other than reverse-engineering someone else’s solution that was developed for a different problem in different conditions. When people then say “See, it won’t work here” this is likely how they got to that conclusion. Too many companies “benchmark” and then try to do this. This team took a completely different approach.

“OK, cool, it didn’t work. Try something else.” And that is how learning happens.

They go back to grasping the original problem – damage from forklift handling. This is crucial. So many teams get bogged down on defining the “problem” as “making the fixed solution work” and end up expending a lot of effort in a tunnel with a dead-end. This is about exploring possible solutions to the actual problem.

They end up developing something quite different from what they benchmarked, that delivered the right parts, in the right orientation to the assembly operator. They knew this because they were their own customers – these were people who did this job.

Once they had it working on a sub-set of easier parts, they expanded the concept step by step (a few parts at a time) to handle the larger ones.

Key: Get the simple version working before trying to add complexity. Control your experiments. This is how learning happens vs. “just fiddling with it until it works.”

They proceed step by step – now sharing back and forth with the benchmark company who is seeing their solutions and building on them, until they have an AGV pulling a sequenced line of part carts that were loaded by robots, everything moving at takt.

Still, there was a lot of human interaction and they kept working to better synchronize everything.

Step by step, they worked their way back into parts that came from outside suppliers, dealing with one issue at a time.

Then a remarkable thing happened:

…at some point an hourly team member asked why the company was spending so much money to buy AGVs from external suppliers. Toyota manufactures vehicles, after all. Team members found they could buy the little robotic device that pulls the carts and custom-make the carts themselves.

But they didn’t stop there.

Later they discovered they could buy inexpensive, generic circuit boards of the type used in the AGV and program the boards themselves so that the AGVs would stop and wait at certain points along the line. Programming the AGVs themselves was a breakthrough, since it cut out licensing fees and added the flexibility to reprogram them. The original AGVs cost about $25,000 each; the ones built in-house cost under $4,000. With more than 100 AGVs in use, the team members kaizen initiative saved TMMK more than $2 million.

Let’s take a step back from this and look at what was really happening here.

What did these team members know at the end of this process that the didn’t know at the beginning?

What knowledge did they add to the company’s capability? Beyond the simple technical solution, what else did they learn? What confidence did they gain?

In other words, how did participating in this process improve the capability of the team members to improve other processes?

What would it be worth to your company to have team members who could think like this? (Hint – you already have them)

I promised to address a couple of points later. Here they are:

The role of managers vs. the management system.

The management system in any company is rightly focused on ensuring that operations are delivering the most customer value for the least cost. This is true of any value-creating operation, be it organized for profit or non-profit.

But the picture being painted by Liker and Convis is one where this management system works by ensuring the managers (that is, the individual people who are responsible for the operation) are focused on developing people’s capability.

To do this, Toyota has a specific process for developing leaders to embrace this responsibility.

This isn’t a new message. But it is emerging more clearly and more consistently in the popular literature in the last few years.

Which brings us to who made the improvements.

In this example, the improvements were made by production team members.

The company probably could have achieved similar (or at least similar looking) results with a project plan and a team of engineers. It might have even been faster.

But the production workers would have learned nothing other than to accept whatever the engineers gave them.

It is unlikely it would have occurred to anyone to build their own AGVs and save another couple of megabucks.

And the capacity of the company for improvements would have remained the same rather than increasing. At some point, the rate of improvement is constrained by the resources that can be dedicated to the task.

So, while an individual improvement task might take longer as people learn, in the end there is a multiplier effect as more and more people get better and better at making improvements. Sadly, it is really impossible to assign an ROI to that, so traditional management doesn’t allow for it.

This post is long enough. There is more in Chapter 4 to talk about, but I want to get this out there.

Comments 8

  1. Marc Rouppe vd Voort wrote:

    Great post again, thank you.

    We are learning from these lessons, but it sure is hard. One of the struggles is finding the right balance between building on our own DNA and introducing new DNA. The best path is probably in your post: experiment and learn what works in your own environment. But what if people do not want to experiment? How do you create a learning environment?

    I wonder whether we can learn this by looking towards Toyota, because they already have this environment. Which companies have great examples how they created a learning environment to experiment with the Toyota principles and methods to find their own path?

    Any thoughts on this?

    Posted 04 Jan 2012 at 11:28 pm
  2. Adi Gaskell wrote:

    This is probably true with any recent management innovation, be it knowledge management, social business or of course lean.

    I don’t think it’s particularly useful to look at other companies as, like you said, you often end up merely trying to reverse engineer what they have done rather than take the philosophy as a start to decide how this can benefit you in your circumstances.

    After all, even if Toyota have achieved great success they have done so in a completely different environment, with different people, different circumstances and different priorities to you and your company.

    So by all means use continuous improvement as a base philosophy but to really get it working well you have to start from the ground up and build something that fits your organisation.

    Posted 05 Jan 2012 at 1:56 am
  3. Jaap van Ede wrote:

    Hello Mark, good post, with a nice practical example.
    The same concept is explained in the book Toyota Kata.

    The main message in this book: Behavior routines, the so-called Improvement Kata and Coaching Kata, determine how everyone within Toyota strives iteratively to reach a Target Condition. This brings the company a step closer to a Vision, but along a route that is a priori unclear and full of hidden obstacles. This is something different then management by quantitative and financial targets, in which not only what but also how things should be done is determined beforehand.

    More about this subject on:


    Posted 05 Jan 2012 at 4:52 am
  4. Kris Hallan wrote:

    I like what you said about a project led by engineers likely being able to complete all of this faster but no one would learn anything. In the traditional project focused plan and execute, this manifests itself in the Gantt chart with a week in the end for “Training Operators”. A very good project will even put together a “training plan”. If you have a sufficiently progressive company that still doesn’t understand kaizen, you might actually get a weeks “training” off-site where your contract engineering firm is developing the new processes. In most projects, the “training operators” ends up getting cut out when budgets get tight and deadlines start slipping. The operators end up being thrown in the deep end.

    All of it is fundamentally skewed from the idea of kaizen. You don’t need “training” on a process you developed.

    Posted 05 Jan 2012 at 8:33 am
  5. John Hunter wrote:

    Very well put post. Thanks.

    Posted 06 Jan 2012 at 2:22 pm
  6. Tom Warda wrote:

    The other important point that may not exactly jump right out of Mark’s post is the total time frame involved and the magnitude of each change / PDCA cycle.

    The total time frame was quite long – not just a one week Kaizen. This was a significant undertaking that required lots of management support as well as a lot of faith in the team. Yes, management had to let go here.

    The time frame was also significantly long. Too many companies are hooked on the “5 day Kaizen with instant / huge results” drug. This story does a great job of showing how the true masters do it.

    Posted 11 Jan 2012 at 9:18 am
  7. Mark Rosenthal wrote:

    At the same time, this project was structured with many small cycles of PDCA every day. As others in the field have also pointed out, this process is fractal – as you zoom in to a large pattern, you see it is made up of smaller versions of the same pattern.

    Posted 11 Jan 2012 at 9:42 am
  8. Wesley Connell wrote:

    The idea of employee driven solutions believe is the key to all Kaizen activities. As a Lean consultant I notice that the piece missing from many organizations who hire me is that they want the best answer, now! But as your post discusses, specifically with Bill C’s graphic, the right solution path for each company will be completely unique and will ultimately be determined by the ideas and engagement of the people on the floor that utilize the system everyday. While I do believe that we, as consultants, add value by driving the process of idea generation and implementation while setting up processes to sustain the efforts, if companies want the solution that best fits their needs, then we need to be facilitating the discussion between the floor and management. And as you discuss, this is a hard sell in terms of ROI…

    Thanks for all the great posts!

    Posted 11 Jan 2012 at 12:10 pm

Trackbacks & Pingbacks 1

  1. From Return on Investment: Continuous Improvement Killer? | LearnSigma on 18 Mar 2012 at 11:03 pm

    [...] Lean Leadership: Kaizen is Management(theleanthinker.com) [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

%d bloggers like this: