The target condition at this point is simply to establish some degree of transparency of the current condition on a status board without having to resort to probing questions to elicit what is working, and what is not.

The observation was:

“We’ll know we are succeeding when we see a failure.”

In other words, “no problem is a big problem” but I think this says it just as well.

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

Failure as Success

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

I have a couple of teams working to develop pull systems through their respective work areas.

The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.

An alternative approach is to have a small group of experts design the system.

Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.

What I am watching this week is more organic.

First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.

The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.

They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.

Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.

Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.

They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.

They are figuring out how to make it more robust, without making it cumbersome or too complicated.

They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.

The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.

What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.

This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.

It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.

Oh – and I’m really glad this process works because that saves me from having to know the answers.

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

Learning vs Teaching

• The PDCA cycle – small experiments that the “learner” develops to advance toward the target condition.
• The coaching cycle (or kata) – an introduction to the role of the coach, and how coaching is structured in practice.
• A fairly brief discussion on the current experience with the implementation path for an organization.

Roles

Even though the book and course material are quite explicit, a couple of people in the room weren’t readily grasping this until today.

Who Is Being Coached?

In the Kata model, the first level of “learner” is the first line leader who has direct responsibility for the process, and the people who work in it.

On a production floor, this would be the area supervisor.

The core material of the course is how to plan and execute continuous improvement in your work group. This is called the “Improvement Kata”

The “Coaching Kata” is covered and demonstrated (quite well), but it is not the prime topic this week.

Who is doing the coaching?

The coach is nominally the direct supervisor of the person being coached.

To learn how to coach, one must first learn the game. Thus, no matter your role in the organization chart, you come to this seminar gain awareness of the role of your first line leaders.

Then you go home and practice the role some more. Once you have lived in their shoes, then you can turn around and expect them to do the same.

What is absolutely critical to understand here is that this is not a “kaizen event” model. This is a daily improvement model. The coaching cycle happens for a few minutes every day between front line supervisor and the immediate manager. It is a process for developing better supervisors. It cannot (or at least should not) be delegated.

Here is the crucial difference: In many kaizen events, the specialist staff workshop leader is the one directing the actions of the team. The area supervisor may be a member of the team, but she is often not the one actually guiding the effort. In this model, there is no “learner” because there is no deliberate process to improve the problem solving and leadership skills of the supervisor.

If the course has a weak point it is that we “learners” are organized in a way that LOOKS more like a traditional kaizen team, which shifts the instructor / coach more into a role that LOOKS like that of the traditional kaizen workshop leader. Thus, it is easy for a participant to slip into a well-engrained mindset about kaizen events. We have all “practiced” the kaizen event pattern many times. The “kata” pattern is new.

This is the nature of the instructor coaching a group of “learners” rather than the 1:1 that is designed to happen in reality.

So, advice if you decide to attend: Be explicitly conscious that the structural limitations of the course, and deliberately work to overcome them in your mindset. This will help you grasp the material that you are there to learn.

That being said, I have a very explicit picture now of how I want shop floor supervisors to behave and lead. I have a pretty good idea of how to help them get there.

I’ve got an early flight, more later.

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

Toyota Kata Seminar, Day3

• A one-day classroom overview of the concepts in Toyota Kata.
• The one-day classroom overview followed by two days of practice on a shop floor, for a total of three days.

I am taking the three day version.

Impressions of Day 1

There are about (quick count) 36 participants, a big bigger group than I expected considering the premise. I don’t know how many are not going to be attending the shop floor part, but most people are.

I suppose the ultimate irony is the slide that makes the point that classroom training doesn’t work very well for this.

Realistically, I can see it as necessary to level-up everyone on the concepts. The audience runs the gamut of people who have read, studied, written about, made training material from, and applied the concepts in the book; to people who seem to have gone to the class with quite a bit less initial information.

That being said, everyone had some kind of exposure to lean principles, though there was a lot of “look for waste” and “apply the tools” mindset present. Since one of the purposes of the class is to challenge that mindset, this is to be expected.

You can get a good feel for the flow and content of the material itself on Mike Rother’s web site. He has a lot of presentations up there (via Slide Share).

Like any course like this, the more you know when you arrive, the more nuance you can pull out of the discussion.

Since I have been trying to apply the concepts already, my personal struggles really helped me to get a couple of “ah-ha” moments from the instruction.I arrived with a clear idea of what I wanted to learn, and what I thought I already knew. Both pre-disposed me to get insight, affirmation, and surprise learning from the material.

I would not suggest this for anyone who was looking to be convinced. Classroom training in any case doesn’t do that very well, and this material isn’t going to win over a skeptic. You have to be disposed to want to learn to do it.

At the end of the day, the overall quality, etc. of the presentation was pretty typical of “corporate training” stuff – not especially riveting, but certainly interesting. But we don’t do this for the entertainment value, and the learner has a responsibility to pull out what they need in any case.

Insights from Day 2

Day 1 is intended, and sold, as a stand-alone. The next two days are available as follow-on, but not separately.

The intended purpose was to practice the “improvement kata” cycle in a live shop floor environment. Today was spent:

• Developing our “grasp of the current condition.” There is actually a quite well structured process for doing this fairly quickly, while still getting the information absolutely necessary to decide what the next appropriate target is.
• Developing a target condition. Based on what we learned, where can this process be in terms its key characteristics and how it performs, in a short-term time frame. (A week in this case)

Key Points that are becoming more tangible for me:

The “Threshold of Knowledge” concept.

I elaborated on Bill Costantino’s (spelled it right this time) presentation on this concept a while ago. In the seminar, I am “ groking” the concept of threshold of knowledge a bit better. Here is my current interpretation.

There are really three thresholds of knowledge in play, maybe more. First is the overall organization. I would define the organizations’ threshold of knowledge as the things they “just do” without giving it any thought at all.

For example – one company I know well has embedded 3P into their product design process to deeply that the two are indistinguishable from one another. It is just how they do it.

They still push the boundaries of what they accomplish with the process, but the process itself is familiar territory to them.

Likewise, this company has a signature way to lay out an assembly line, and that way is increasingly reflected in their product designs as 3P drives both.

It wasn’t always like that. It started with a handful of people who had experience with the process. They guided teams through applying it, in small steps, on successively more complex applications until they hijacked a design project and essentially redid it, and came out with something much better.

Another level of knowledge threshold is that held by the experienced practitioner.

Today I walked into a work cell in the host company for the first time, and within a few minutes of observation had a very clear picture in my own mind of what the next step was, and how to get there. My personal struggle today was not in understanding this, but in methodically applying the process being taught to get there. I knew what the answer would be, but I wasn’t here to learn that.

An extended threshold of knowledge in one person, or even in a handful of people, is not that useful to the company.

But that is exactly the model most kaizen leaders apply. They use their expert knowledge to see the target themselves, and then direct the team to apply the “lean tools” to get there.

They tell the team to “look for waste” but, in reality, they are pushing the mechanics. You can see this in their targets when they describe the mechanics as the target condition.

The team learns the mechanics of the tools, but the knowledge of why that target was set remains locked up in the head of the staff person who created it.

So his job is to set another target condition: Expanding the threshold of knowledge of the team.

He succeeds when the team develops a viable target themselves. It might be the same one he had, but it might not. If he framed the challenge correctly, and coached them correctly, they will arrive at something he believes is a good solution. If they don’t he needs to look in the mirror.

So the next level of knowledge threshold is that held by the team itself.

If enough teams develop the same depth, then they start to interconnect and work together, and we begin to advance the organization’s threshold. Now what was previously required a major “improvement event” to develop is just the starting baseline, and the ratchet goes up a bit.

None of the above was explicitly covered today, but it is what I learned. I am sure I’ll get an email from a certain .edu domain if I am off base here.

There is no Dogma in Tools

This is the third explicit approach I have been taught to do this.

The first was called a “Scan and Plan” that I learned back in the mid/late 1990’s. It was more of a consultant’s tool for selecting a high-potential area for that first “Look what this can do” improvement event.

Though I don’t use any of those forms and tools explicitly, I do carry some of the concepts along and apply them when appropriate.

Then I was exposed to Shingijutsu’s approach. This is heavily focused on the standard work forms and tools. Within the culture of Shingijutsu clients, it would be heresy not to use these forms.

The “Kata” approach targets pretty much the same information, but collects and organizes it differently. I can see, for myself, a of better focus on the structure of establishing a good target. I can also see a hybrid between this method and what I have used in the past. Each form or analytical tool has a place where it provides insight for the team.

One thing I do like about the “Kata” data collection is the emphasis on (and therefore acknowledgement of) variation in work cycles. (All of this is in the book by the way. Read it, then get in touch with me if you want some explanation.)

Now, I want to be clear – in spite of the title of this section, when I am coaching beginners, I will be dogmatic about the tools they use. In fact, I plan to be a lot more dogmatic than I have been.

I am seeing the benefit of providing structure so that is off the table. They don’t have to think about how to collect and organize the data, just getting it and understanding it.

What I can do, as someone with a bit more experience, is give them a specific tool that will give them the insight they need. That is where I say “no dogma.” That only applies when the principles are well within your threshold of knowledge.

The real ah-ha is that, unlike the Shingijutsu approach, we weren’t collecting cycle times at the detailed work breakdown level. Why not? Because, at this stage of improvement, at this stage of knowledge threshold for the team, the work cell, that level of detail is not yet necessary to see the next step.

I will become necessary, it just isn’t necessary now.

Target Conditions and PDCA Cycles

One place where my work team bogged down a bit this afternoon was mixing up the target condition that we are setting for a week from now, and what we are going to try first thing in the morning.

The target condition ultimately requires setting up a fairly rigid standard-work-in-process (SWIP) (sometimes called “standard in-process stock) level in the work cell.

There was some concern that trying that would break things. And it will. For sure. We have to stabilize the downstream operation first, get it working to one-by-one, and make sure it is capable of doing so.

The last thing we want to do while messing with them is to starve them of material.

So – key learning point – be explicitly clear, more than once, that the Target Condition is not what you are trying right away. It is the predicted, attainable, result of a series of PDCA steps – single factor experiments. You don’t have the answers of how to do it yet. So don’t worry about the SWIP level right now. That will become easier… when it is easier.

More tomorrow…

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

From The Toyota Kata Seminar

A key theme woven throughout Spear’s work is the world today is orders of magnitude more complex than it was even 10 or 15 years ago. Where, in the past, it was feasible for a single person or small group to oversee every aspect of a system, today that simply isn’t possible except in trivial cases. Where, in 1965 it was possible for one person to understand every detail of how an automobile worked, today it is not.

My interpretation goes something like this:

Systems are composed of nodes, each acting on inputs and triggering outputs. In the past, most systems were largely linear. The output of upstream nodes was the input of those immediately downstream. You can see this in the Ford Mustang example that Spear discusses in the webinar.

Today nodes are far more interconnected. Cause and effect is not clear. There are feed-back and feed-forward connections and loop-backs. Interactions between processes impact the results as much as the processes themselves.

Traditional management still tries to manage what is inside the nodes. Performance, and problems, come from the interconnections between nodes more than from within them.

The other key point is that traditional management seeks to first define, then develop a system with the goal of eventually reaching a steady state. Today, though, the steady state simply does not exist.

Product development cycles are quickening. Before one product is stable, the next one is launched. There is no plateau anymore in most industries.

From my notes – “The right answer is not the answer for very long. It changes continuously.”

Therefore, it is vital that organizations be able to handle rapid shifts quickly.

With that, here is the recorded webinar.

A couple of things struck me as I participated in this.

Acknowledging that Spear has a bias here (as do I), the fact that Toyota’s inherent structure and management system is set up to deal with the world this way is probably one of the greatest advantages ever created by happenstance.

I say that because I don’t believe Toyota ever set out to design a system to manage complexity. It just emerged from necessity.

We have an advantage of being able to study it and try to grasp how it works, but we won’t be able to replicate it by decomposing its pieces and putting it back together.

Like all complex systems, this one works because of the connections, and those connections are ever changing and adapting. You can’t take a snapshot and say “this is it” any more than you can create a static neural net and say you have a brain.

Local Capability

One thing that emerges as critical is developing a local capability for this creative experimentation.

I think, what Spear calls “creative experimentation” is not that different from what Rother calls the “ improvement kata.” Rother brings more structure to the process, but they are describing essentially the same thing.

Why is local capability critical? Processes today are too complex to have a single point of influence. One small team cannot see the entire picture. Neither can that small team go from node to node and fix everything. (This is the model that is used in operations that have dedicated staff improvement specialists, and this is why improvements plateau.)

The only way to respond as quickly as change is happening is to have the response system embedded throughout the network.

How do you develop local capability? That is the crux of the problem in most organizations. I was in an online coaching session on Tuesday discussing a similar problem. But, in reality, you develop the capability the way you develop any skill: practice. And this brings us back to the key point in Kata.

Practice goes no good unless you are striving against an ideal standard. It is, therefore, crucial to have a standardized problem solving approach that people are trying to master.

To be clear, after they have mastered it, they earn a license to push the boundaries a bit. But I am referring to true mastery here, not simple proficiency. My advice is  to focus on establishing the standard. That is difficult enough.

An Example: Decoding Mary – Find the Bright Spots

Spear’s story of “Decoding Mary” where the re-admission rate of patients to a hospital directly correlated with the particular nurse handled their transfer reminded me of Heath & Heath’s stories from Switch. One of the nine levers for change that they cite is “ find the bright spots.”

In this case the creative experimentation was the process of trying to figure out exactly what Mary did differently so it could be codified and replicated for a more consistent result independent of who did it.

The key, in both of these cases, is to find success and study it, trying to capture what is different – and capture it in a way that can be easily replicated. That is exactly what happened here.

A lot of organizations do this backwards. They study what (or who) is not performing to determine what is wrong.

Sometimes it is far easier to try to extract the essence what works. Where are your bright spots for superb quality? Does one shift, or one crew, perform better than the others? Do you even know? It took some real digging to reveal that “Mary” was even the correlating factor here.

Continuous Improvement Means Continuous Change

Since “continuous improvement” really means “continuously improving the capability of your people,” now perhaps we have “to do what.” I have said (and still say) that the “what” is problem solving.

What you get for that, though, is a deep capability to deal with accelerating change at an accelerating rate without losing your orientation or balance.

It is the means to allow the pieces of the organization to continue to operate in harmony while everything is changing. That brings us back to another dilemma: What is the ROI on learning to become very, very good? You don’t know what the future is going to throw at you, only that you need the capability to deal with it at an ever quicker pace.

But none of this works unless you make a concerted effort to get good at it.

Here is the original link to the MIT page with the video, and a download link for PDFs of the slides:

http://sdm.mit.edu/news/news_articles/webinar_010912/webinar-spear-complex-operating-systems.html

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

Steve Spear on Creative Experimentation

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

It was the concept of the “current knowledge threshold” illustrated here:

As I interpret it, the red line depicts the “we know how to do this” area. It is the domain where the team is comfortable working, they have a good grasp of cause and effect.

For problems which are outside the red line, the organization needs to engage in deliberate activity to gain understanding, to push the boundary of knowledge until the problem is enclosed by it. I tried to illustrate that process at the end of the original post.

Sadly, this doesn’t happen often enough.

Instead what happens is the organization develops a comfort zone inside the red line. Things that are outside the red line come labeled with “That doesn’t work here” and “We have reached the limit of what we can improve.”

Organizations, even sub-organizations within the same company that out-perform the baseline knowledge – who have cracked problems outside the red line – get dismissed as “no different” or “nothing special” or are attributed with special, unrepeatable, circumstances to account for their different performance. (I have seen this up close.)

If you are serious about kaizen, it is important to be operating right at the edge of the red line.

“What have we done today that, yesterday, we didn’t know how to do?”

“What will we try tomorrow that, today, we don’t know how to do?”

Those are questions that push learning.

By the way – if you are spending all of your time inside the red line, and solving the same problems again and again, your performance is likely flat lined. This is the “improvement plateau.” That is another topic for later.

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

The Boundary of “We Don’t Know”

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