I believe this is a significant event for the lean community as a whole, as well as for the LEI.

As many of my regular readers know, I have maintained the view that the LEI had not kept up with the current state of knowledge about what makes “lean” work.

Back to Basics

An Open Letter to John Shook

When the LEI published Kaizen Express in 2009, I wrote a review that addressed this topic. The review had two parts. One part about the book itself, and the other about the context of the community’s knowledge at the time.

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. [bolding added for emphasis here]

When Toyota Kata was published, I believe it closed that gap for the community at large. But I felt a bit of irony that while Mike Rother had co-authored the LEI’s flagship workbook Learning to See, Toyota Kata was not only outside the LEI’s community at the time, it was hardly acknowledged to exist.

The purpose of this post is to acknowledge that a significant step has been taken: For the first time in many years, the LEI is embracing material that they did not originally publish.

From my perspective, this looks like a turning point away from the path of irrelevance.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Toyota Kata at lean.org

The Power of Habit

A habit is based on an urge to do something that triggers a reward (dopamine shot) in your brain. Every time it happens, the connection between the action and the reward gets stronger.

The urge itself is usually triggered by some outside condition or stimulus.

Take a look at the video, and then the flowchart beneath it (click on the flowchart for the full size version), then we will discuss what this has to do with lean thinking.

Here is the flowchart – click for the full size version:

Why this is important to lean practitioners:

When we talk about “change” we are talking about replacing one set of habitual responses with a different set of responses. Thus, it is important to understand that simply applying willpower is not enough for anyone (no matter how well intentioned) to change their fundamental behaviors.

As you may recall, I am a big fan of the book Switch by Chip and Dan Heath. One of their key points is “Build Habits” and they discuss linking the desired response to a specific trigger.

What we have to keep in mind is that the old responses also have triggers, and many of those triggers are subtle and below the level of awareness.

Duhigg’s model is replacing one habit that does not get the results you want with a different habit that does get the results you want.

The less dramatic this change, the better. That is why it is critical to “find the bright spots” (also from Switch), and even if they are not working perfectly, to structure your future state behaviors around them. For that matter, if you can find even a hint of the behavior you want, it is far easier to shape existing actions than to try to tell people they are “doing it wrong” and getting them to pick up something else.

One of the elements of Deming’s model of “profound knowledge” is “knowledge of psychology.” Take a look at these tools and see if they help you be a more effective change agent.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Changing Routines

Tom Wujec makes the same point in the Marshmallow Challenge. In that video, Tom talks about how 5 year old kids out perform most adult groups in a problem solving / learning game. While the adults engage in a single cycle of “know-build-fail” the kids engage in multiple cycles of “try-fail-learn-try again.” In the improvement world, we call this process PDCA.

Harford’s key point is that learning only happens through a process of trial of large numbers of ideas, followed by the selection and further trials on the best ones.

Hmmm… that sounds a lot like the 3P process of “Seven Ideas” as well as “Set Based Design.”

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Learning vs. Knowing (or not)

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.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Lean Leadership: Kaizen is Management

Where in Chapter 2 the authors were outlining the individual leader’s responsibility for self-development, now they are describing the environment and the process of supporting and focusing that drive.

Rather than just outline the chapter, I want to dig into some key elements of the context that Toyota creates for their leaders.

First is the expectation that leaders lead.

Leading vs. Delegating

Chapter 3 has a great story that exemplifies the key differences in management styles that I alluded to in the post about Chapter 2.

In that story, NUMMI has equipment reliability problems in the body shop. Mr. Ito, the President has instructed Convis to have each engineer prepare and present a one page report for every breakdown lasting over 30 minutes. The telling moment is Convis behavior in the presentations:

While Ito was critiquing the [A3] presentations and reports, Gary [Convis] simply stood to one side, marveling at Ito’s insight and amused at the struggles of the engineers’ efforts to learn this way of thinking.

This quote nails the core issue we have to deal with in any company that wants to succeed with lean production.

Convis was newly hired from the U.S. automobile industry, and was acting exactly as he was trained as a manager. He was acting as every manager in the USA is trained.

He has delegated the process of training the engineers to Ito, who he sees as the technical expert. Convis viewed his presence here as overseeing how well his engineers are responding to that training.

Ito, though, had other ideas.

After a few sessions, Ito asked Gary how he was coaching the engineers through the process before the presentations. Ito pointed out that there was still a lot of red on the reports, and if Gary had been teaching the engineers properly, there would be less red ink. […] problems with the reports were a reflection of Gary’s leadership, and he was more responsible for any failures than the engineers were.

Zing.

You can’t even cite “If the student hasn’t learned, the teacher hasn’t taught” here because the delegation paradigm was so strong that Convis didn’t realize he had responsibility for being the teacher.

Convis, of course, “got it” and began seeing the red ink as his failure, rather than the engineers’. The drive for self-development kicked in and worked. And of course, in the process of struggling to coach the problem solving process, he had to struggle to learn it well enough to do so.

Personally, I see the idea of delegating and then passively overseeing improvement and people development is a cancer that is difficult to excise from even the most well intentioned organization.

I have seen this with my own eyes – senior executives struggling with how to “implement lean.” What was their concern? What metrics they could use to gage everyone’s progress through reports to corporate headquarters. They simply saw no need to get personally involved in learning, much less going to see, and certainly not teaching, the messy details. Not surprisingly, that company still struggles with the concepts.

Of course it cascades down from there. The various sites’ leaders follow the example, and delegate to their professional staff people. The staff’s job? To come up with “the lean plan” and “drive improvement” while the leaders watch. At some point, someone in charge of the operation actually has to do something different, but that, it seems, is always the next level down.

I am not going to get into what stops leaders from stepping up to this responsibility or what do to about it because that would be a book in itself.

It doesn’t help that, with the revolving-door of leadership we often encounter, each new leader comes in with the old mindset. OK </rant> and back to the book.

The Technical Support

This expectation of leaders leading does not operate in a vacuum. Toyota processes are deliberately set up to remove any ambiguity about what the next challenge is by surfacing problems immediately

In the words of Lean Leadership, these problems are framed as challenges for leader development.

In a much earlier post, I objected to our western euphemism of “opportunity” when we meant “problem.” My objection was treating this “opportunity” as an something that could be taken on, or not.

A challenge, especially in the context of leader development, isn’t optional. A top level athlete grasps the meaning of a challenge. He is driven to take it on and push himself to meet it. He improves in the process. It isn’t about the record, per se, it is about what he must develop and pull from within himself to get there.

Just as the world-class athlete has a stopwatch on every lap, the assembly line is set up to verify the timing of every cycle. Any discrepancy is immediately apparent to both the team member and the leaders. If the work can’t be done, the line is stopped and things are made right. Then we figure out why. And everyone learns.

TPS […] creates a never-ending stream of opportunities for on-the-job development and increased challenges. Toyota sensei do not need to create artificial training situations […]. The daily process of producing cars generates all the development opportunities and challenges that are needed.

If your organization has trouble finding problems, it isn’t because they aren’t there. It is because your processes are blind to them. That is why “No problem is a big problem.”

The key is that when we talk about “implementing the tools of lean” we are doing nothing more than setting up the baseline process to present the challenges for leadership development. That’s it. It is the difference between playing a casual game and deciding to keep score.

You can’t improve without keeping score, to be sure. But keeping score alone doesn’t cause things to get better. If anything, it increases people’s frustration because they see they are coming up short, but don’t have the support or opportunity to do anything about it.

What happens then? They start seeing problems as “normal” and start blinding the system. They add padding to cycle times to “allow for variation.” They decouple processes and put in extra inventory. They start running two at a time, then four, and return to batching.

If a problem remains hidden below the surface long enough, it can stop being perceived as a problem and become part of normal operating procedure.

OK, so I’ve beaten that to death yet again. It is critical to structure the work so that we can see whether things are going as planned or not.

But it is just as critical to have the problem solving processes engaged immediately. If those processes don’t yet exist, you have no hope of your so-called improvements sustaining for long.

That’s not all. There is another standard that is just as critical – if not more: A standard for problem solving.

The A3

We just got done exploring how critical it is to have a process that is totally transparent. Why? So we can clearly see any difference between how it is and how it should be.

The purpose of the A3 is to provide that level of visual control to the problem solving process itself.

And yes, problem solving is a process. It follows standard work. It is perhaps the most critical thing to standardize. The only way to gain skill at something is to practice against a clear standard. It really helps to have a coach watching your every move and calling out small adjustments, things you need to pay more attention to the next time you do it (which should be immediately).

The A3 is the game film, the slow motion camera, the visual control of how problem solving is being done. It is not sufficient to find the solution. It is more important to develop a consistent approach to problem solving across the entire organization.

But outside of Toyota and a few companies that are starting to grasp what this is about, the A3 is, sadly, one of the more recent fads in the lean community.

An A3 isn’t something you tell someone else to do. It is a visual control, just like the moving line, that works only in the context of direct observation and participation by all parties involved. In the above story, Ito was setting an example, and expecting Convis to follow it. Once that started happening, Ito’s participation shifted from coaching the engineers to coaching Convis as he coached them.

Just as the tools of takt time, standard work, pull systems, etc. do not stand alone and “make you lean,” neither does filling out A3 forms. Even if you have “the tools” and a problem solving process, it doesn’t help if they are not intimately linked together.

All of these things are designed for 1:1 interaction. They are messy testaments to the fact that problem solving often loops back to previous steps as more is learned.

The Big Picture

This chapter provoked a lot of thought for me, and I have tried to share some of that. When / if you choose to read the book, I hope you have your own thoughts, and even share them here or in the forum (that could use some life right now).

Fundamentally, Chapter 3 is about the phenomenal support Toyota provides those leaders who have the self-motivation to learn.

• Every operation is structured to provide challenges and opportunities for them to develop their skills. There is no shortage of things that obviously need improving.
• Every leader is positioned to teach and mentor those who are willing to step up to the challenges that are there.
• The problem solving process itself is structured as standard work so that a prospective leader can practice against a standard and improve skill through repetition and coaching.

Aside from a couple of case studies and examples, this chapter is a bit of a synopsis of Toyota Kata. I continue to bring Kata into this discussion because there is obvious overlap in topics, and I see these two books complimenting each other. Kata gets into the nitty-gritty of how problem solving and coaching happens. Lean Leadership is providing a context and case examples of the entire ecosystem.

More to follow.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

The Structure Behind Leader Development

On the other hand, this isn’t about the typical western “everyone fend for themselves” environment that develops unhealthy (and unethical) cutthroat competition.

They describe a nurturing environment that will allow and support anyone with the desire to take on ever increasing responsibility and challenges, and learn through a process of developing mastery.

The Role of Sensei

Not surprisingly, the role of the sensei described in Lean Leadership is quite consistent with the process that Jeff Liker and Mike Hoseus describe in Toyota Culture.

While the work environment itself is built around opportunities for learning, it is far different from out western ideas.

Lean Leadership sums it up quite well as they discuss the role of the sensei.

• In the west, the teacher’s role is to show you the shortcuts.
• At Toyota, his role is to make sure you don’t take shortcuts.

The teaching process is one of challenge and struggle – but not abandonment. It is guidance through discrete learning stages on the way to mastery.

Mastery

“Standard work” has always been regarded as a core element of the Toyota system. Liker and Convis build on the concept as far more pervasive than simple work procedures. We have known there is more to it for a long time, but like the list of what doesn’t work, authors, consultants and practitioners continue to emphasize the work procedure model.

In Lean Leadership, we see standard work as a path to mastery, and we see the reason behind the emphasis.

Liker and Convis describe a three stage process of learning and developing:

• Shu – being taught. In this stage, the teacher says “do this” and the struggle is to get it right.
• Ha – competent, but following by rote. In this stage, the teacher asks questions to cause reflection, and the struggle is to understand.
• Ri – mastery, the point where the team member has enough depth to improve upon and teach the task.

The point of standardizing and stabilizing a process is to allow the team member the chance to master it. Why is this important? Because then the team member can pay attention to solving problems to improve the work vs. solving problems to simply get it done.

Even this is fairly easy to grasp in the context of bolting a suspension together, or welding a scissor lift. But the same principles apply to leadership itself.

Mike Rother’s Toyota Kata is about application of this principle in the core processes of leadership: Problem solving and coaching. By standardizing problem solving, we give team members the opportunity to master it so they can focus on solving the problem rather than trying to figure out how to go about solving it. It sounds like subtle semantics, but it is a huge difference.

But, again, this is about demonstrated capability rather than classroom hours Compare this process with how we typically “certify” practitioners in the west.

At Toyota the learner’s capability is judged by direct observation, just like any other process. While there must be an internal drive to learn, the challenges and struggles are tailored for the learner’s next stage of development.

Self Development vs. Mandated Development

All of this brings us to one of the core differences in the Toyota described by Liker and Convis.

Throughout my career as an internal “lean guy” in companies large and small, our “lean skill development” (or whatever you want to call it) process for leaders was largely driven by establishing requirements.

We wanted to require leaders to participate in kaizen events. We wanted to require them to attend the Lean 101 class. At one company, managers and supervisors were required to teach the “World Class Competitiveness” course. We want to include classes and educational events on their performance goals. We wanted to make them learn it.

To get back to an earlier post it doesn’t work.

The Toyota process is reversed. There is no requirement for anyone to master anything other than their current job. But if you want to get more responsibility, it is incumbent on you to demonstrate the drive to develop your own capability.

One purpose for universal team member involvement in kaizen is for leaders to directly observe who has the right motivation to learn and take on more. That is the beginning of the leadership development process.

In our companies today, of course, we have the situation of an existing hierarchy. Leaders have gotten into senior positions without having any of these skills. Our western management process is one of detached decision making from summaries presented by staff on PowerPoint. If a new initiative comes along, the senior leaders delegate it and “support” it by not shutting it down.

That doesn’t work if you want to change the status-quo.

What does? A drive to master something new and a realization that personal development is a continuous life-long process. That is the key message I get from this chapter. More to follow.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Lean Leadership Begins With Self Development

Chapter 1 of The Toyota Way to Lean Leadership is titled “Leading in the Toyota Way: A Lifelong Journey.”

It seeks to draw a sharp contrast between Toyota’s leadership model and the model that is taught and practiced in a more “traditional” Western company.

Where the “teaching” process in a traditional company tends to be tacit – reinforcing some behaviors and discouraging others, in the Toyota described by Liker and Convis, the process is far more deliberate.

It is a process of aligning to explicitly stated core values that have been in practice since the inception of the company, but only written down in 2001 as The Toyota Way 2001.

Then, because the word “leadership” often carries one of those “I know it when I see it” kinds of definitions, the authors use examples and construct a model to describe what they have observed. That model then structures the next few chapters (Yes, I peeked ahead).

Across the chapter they are describing leadership, not as something practiced by individuals, but as an interdependent ecosystem that links tightly to every aspect of the company. Certainly individuals each have their own style, but it is expressed within a context defined by commonly held beliefs and norms of behavior that combine to form what we call a “culture.”

Someone from outside that culture (such as Gary Convis coming from Ford, and other Toyota managers I have known personally), has to work hard to assimilate into it.

Outside the context of the book, I have also seen the opposite: Take someone who knows nothing but the Toyota culture and put them into a “traditional” company and many of them have a hard time adapting to a completely alien environment. The support structures they are used to are simply not there, and it can be psychologically very isolating.

One example of this contrast is in how these two systems see “Challenge.”

In a traditional company, a “challenge” is issued as a “stretch goal” and it is up to the individual to figure out on their own how to meet it. In the most extreme case of an “only results matter” environment, they may disregard their fellow team members, rules, ethics, even the law to get there. While we have spectacular examples such as Enron, there are lots of companies where “inventory targets” are met by starving off production at the end of the quarter and pulling in orders from the next.

“Challenge” is one of the explicit values in The Toyota Way 2001 but it looks quite different. Yes, there are challenges issued. But behind that challenge is a support structure. The leaders, at all levels are expected to stretch their own personal development, but to do so within the context of kaizen, deep understanding gained by genchi genbutsu, team work and most important of all, respect.

The leader’s development level is gauged by how the challenge is met even more than whether it is met. Just “get-r-done” doesn’t work here.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Defining Leadership

1. Has been covered before – we know all of this.
2. Needs to be covered again, because most people act as though we don’t know it.

Simply put, Liker and Convis (legitimately) feel the need, once again, to let us know the things which reliably fail when trying to build a sustaining culture of continuous improvement.

“So let’s train some Lean Six Sigma experts to grab the tools and start hacking away at the variability and waste that stretch out lead time; this will make us more successful, both for our customers and for our business. What could be simpler?”

What indeed.

I am, once again, reminded of a saying that “People will exhaust every easy thing that doesn’t work before they try something difficult that will.”

The authors cite some of the same things that we have heard before:

• Trying to determine ROI for each individual process step, or each individual improvement, doesn’t work.
• Trying to motivate the right behavior with metrics and rewards doesn’t work.
• Trying to copy the mechanics doesn’t work.
• Trying to benchmark, and copy, a “lean company” in your business doesn’t work.

Yet, even though we have been hearing these messages for at least a decade, actually longer, I continue to encounter managers who try to work this way.

The authors assert, and I agree, that this is the result of people trying to fit Toyota’s system into a traditionally taught management paradigm that is so strong people aren’t even aware that there is a paradigm, or can’t conceive there is anything else.

They are stuck inside their threshold of knowledge when the answer is beyond it.

This reminds me of the Edwin Abbot’s 1884 story of Flatland, a two-dimensional world populated by creatures who cannot conceive of “above” and “below” their planer existence.

Although his story is often read by students struggling to grasp models with four, five and more dimensions to them, it is really a story of social change and paradigms.

Our management systems are a “flatland” with Toyota’s system existing in a space that we have to work hard to grasp. We can see pieces of it where it touches ours, but like the creatures in Flatland who only see two dimensions of three dimensional objects, we only see the pieces of TPS that we can recognize.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Once Again: What Doesn’t Work

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.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Leadership: Deal With The True Constraint

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 listen to the presentation. (Yes, it has a sound track, to be sure to hit the “Play” arrow rather than just flipping through the slides.)

Note: Some browsers (Firefox?) have had problems loading from the embedded link. If that happens to you, here is the direct URL:  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) has not been as clear in Rother’s work up to this point.

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.

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.

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

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Bill Costantino: Toyota Kata “Unified Field Theory”