Some of you have commented in back-channels that I have been pretty quiet for a while – both here as well as in regular correspondence. I’ve been in pretty heavy reflective mode for quite a while. I described it to someone as “I am learning faster than I can write it down right now – by the time I write something, I understand it in a different way and start over.”
A lot of that reflection has been around consolidating what I learned at from Rich Sheridan, James Goebel and all of the other Menlonians that I have the privilege to know now.
That work was punctuated, though not completed, by my keynote at KataCon last February (2018) where I followed Rich Sheridan and described my interpretation of the underlying meta-patterns that exist in pretty much any organization that we would call exceptionally good at what they do.
At the same time, another client (Thank you, Tomas!) introduced me to Ronald Heifetz and Martin Linsky’s body of work under the umbrella of “Adaptive Leadership.” From their model I think I picked out a fundamental failure mode of what we like to call “change initiatives” regardless of what tool set of operational models we are trying to deploy.
To learn more about this, I read (Note – these are Amazon affiliate links. If you choose to buy the book, I get a (very) small kickback at no cost to you.)
and every paper and article I could find on the topic or about people’s experience. While doing this, I have tried out many of the teaching and coaching processes as well as applying the observation, interpretation and intervention skills in the course of my work. Those of you who participated in the Experiential Workshop that Craig Stritar and I put on at KataCon early this year were seeing the outcomes of this work up to that point.
My latest step was taking a three day seminar Your Leadership Edge from the Kansas Leadership Center in Wichita the 2nd week of August. The KLC’s model and methods are built on the Adaptive Leadership model. My intended outcome was to consolidate some of my understanding by getting the external perspective and participating within their structure.
The number one frustration of “change agents” out there is some form of “How to I get buy-in?” I know I have experienced that myself. It is easy when all of the constituencies and factions within the organization are well aligned on purpose and values. Not so easy when there are conflicts. I think the Adaptive Leadership model gives us an approach we can learn by practicing. It also mirrors the steps of problem solving / continuous improvement that are outlined in Mike Rother’s Toyota Kata. The context for action is different, but the process is the same: Learning what works through experimentation. That is the “adaptive” part of Adaptive Leadership.
This post is just some background around why I am pursuing this line of thought. As always, I write about things like this to force myself to improve my own understanding by having to explain them in the simplest possible terms. I am happy to have any of you along the journey with me, so subscribe or check-in or whatever and let’s see what we can learn.
The LEI was kind enough to send a review copy of their new book, the second edition of Lean Process and Product Development. I have just started it, and am already finding gems. (note to the LEI – the Kaizen Institute is not my address. Thanks to Jon for getting the book to me.)
The original edition was a cleaned up manuscript that was published well after the death of Allan Ward, and bore only his name on the cover.
This edition adds Durward Sobek to the author line. Sobek was a student of Ward and today stands on his own as someone whose views should be respected.
I am not going to try to compare the two editions, rather look at this new book as it stands on its own.
Rather than wait and write a big long review, I am going to publish short posts as I come across key points of note – hence the subtitle of this post.
I am already seeing a tight link to the leadership model outlined in Toyota Kata.
In the 2nd chapter, as the authors discuss Value and Performance of development projects (as in how efficiently they create profitable value streams and create usable knowledge for future projects), I came across a compelling quote:
A general manager of Toyota’s Advanced Vehicle Development department was asked how he spent his time.
He replied he spent about 2 hours a week doing administrative work, and the rest of the time “on technical problems.” Before I remark about the “technical problems” consider the first bit. How much time do your department heads spend administering vs. contributing to the development of the organization?
And that leads to the second part. He says:
“But every technical problem is also a personnel problem, because the problems don’t get to me if my people know how to solve them. So all of the time I’m working on technical problems, I’m also teaching someone.
To paraphrase the next paragraph in the book, the solution to personnel problems is to teach.
So I’ll digress from this book a bit here, and read between the lines a bit. If we go back to David Marquet’s sketchcast video he talks about the necessity of creating an environment where your people need to discover the answer, or “you’re always the answer man, and you can never go home and eat dinner.” (This is really hard when you know the answer, by the way.)
So already, in the first couple of chapters, we are establishing an environment that doesn’t simply produce engineering designs. Those, I suspect, are an outcome of deliberate processes to build the organizational competence and clarity.
With the publication of Learning to See in 1999, Mike Rother and John Shook introduced a new genre of book to us – a mix of theory, example, and practical application. The story invites the readers to follow along and actually do for themselves.
This is one of those books that gives a bit more every time I read it. The more thorough my baseline understanding of TPS, the more I get from some of the nuances of Rother and Shook’s intent.
At the same time, I am beginning to formulate an idea that perhaps this book is often used out of its intended context – maybe a context that was assumed, but left unsaid.
I’d like to share some of the things I have learned over the years, especially as I have worked to integrate the concepts in Learning to See into other facets of the TPS – especially research by Steven Spear, Jeff Liker, and of course, Mike Rother’s follow-on work Toyota Katawith my own experience.
Learning to See introduced the term “value stream” to our everyday vernacular.
Although the term is mentioned in Lean Thinking by Womack and Jones, the concept of “map your value streams” was not rigorously explained until LTS was published.
To be clear, we had been mapping out process flows for a long time before Learning to See. But the book provided our community with a standard symbolic language and framework that enabled all of us to communicate and share our maps with others.
That, alone, made the book a breakthrough work because it enabled a shorthand for peer review and support within the community.
It also provided a simple and robust pattern to follow that breaks down and analyzes a large scale process. This enabled a much larger population to grasp these concepts and put them to practical use.
Learning to See and “Getting Lean”
In Chapter 11 of Lean Thinking, Womack and Jones set out a sequence of steps they postulate will transform a traditional business to a “lean one.”
The steps are summarized and paraphrased in the Forward (also by Womack and Jones) of Learning to See:
Find a change agent (how about you?).
Find a sensei (a teacher whose learning curve you can borrow)
Seize (or create) a crisis to motivate action across your firm.
Map the entire value stream for all of your product families.
Pick something important and get started removing waste quickly, to surprise yourself with how much you can accomplish in a very short period.
Learning to See focuses on Step 4, which implies establishing a future-state to guide you.
In the Forward, Womack and Jones commented that people skipped Step 4 (map your value streams). Today, I see people skipping straight to that step.
Let’s continue the context discussion from the Forward, then dig into common use of the value stream mapping tool..
“Find a change agent (how about you?)” is a really interesting statement. “How about you?” implies that the reader is the change agent. I suspect (based on the “change agents” discussed in Lean Thinking that the assumption was that the “change agent” is a responsible line leader. Pat Lancaster, Art Byrne, George Koenigsaecker were some of the early change agents, and were (along with their common thread of Shingijutsu) very influential in the tone and direction set in Lean Thinking.
Today, though, I see job postings like this one (real, but edited for – believe it or not- brevity):
Job Title: Lean Manager
Reports To: Vice President & General Manager of Operations
Lead highly collaborative action-based team efforts to clean out, simplify and mistake-proof our processes and our strategic suppliers’ processes.
This includes using proven methodological approaches, applying our culture and providing our team with technology, best cross-industry practices and all other resources needed to attain ever higher levels of productivity and customer delight.
Essential Duties and Responsibilities:
Endlessly define, prioritize and present opportunities for applying AWO’s, GB/BB projects and other LEAN principles to our supply chain and customer deliverables.
Develop, plan and execute the plans as selected by the business leaders.
Train all team members (and other selected individuals) in LEAN principles and mechanisms to be LEAN and preferred by customers.
Document procedures/routines, training, team results/best practices and the like.
Coaches business team members in the practical application of the Lean tools to drive significant business impact.
Leads and manages the current state value stream process.
Develops and implements future state value stream processes.
Responsible for planning and assisting in the execution of various Lean transformation events targeted towards improving the business’s performance on safety, quality, delivery, and cost.
Focuses on business performance that constantly strives to eliminate waste, improve customer satisfaction, on-time delivery, reduce operating costs and inventory via the use of Lean tools and continuous improvement methodologies.
Acts as change agent in challenging existing approaches and performance.
Whew. With all of that, here is my question: What is the line leadership expected to do? In other words, what is left for them to do? And what, exactly, are they supposed to be doing (and how) during all of this flurry of activity?
While all of the “change agent” examples outlined in Lean Thinking (which, in turn, provides context for Learning to See), are line leaders, all too often the role of “change agent” is delegated to a staff member such as the above.
I believe it is entirely possible for a line-leader change agent to also be the “sensei” – Michael Balle’s The Lean Manager shows a fictional scenario that does just that.
But if your “sensei” is a staff technical professional, or an external consultant, the “change agent” function is separate and distinct, or should be.
Which leads me to the first question that is never asked:
Why Are You Doing This At All?
That question can be a pretty confrontational. But it is a question that often goes unasked.
This is especially true where “getting lean” is an initiative delegated to staff specialists, and not directly connected to achieving the strategic objectives of the business. In these cases, “Lean” is expressed as a “set of tools” for reducing costs.
On the other hand, a narrow and specific challengethat is set as Step Zero helps focus people’s attention and gives them permission not to address every problem all at once (which avoids paralysis and gridlock).
So, if I were to edit that list of steps, I’d change “Create a crisis” to “Issue a challenge to focus the effort” and move it to #1 or maybe #2 on the list. The “Find a sensei” then becomes a countermeasure for the obstacle of “We need AND WANT to do this, but don’t have enough experience.” (That assumption, in turn, implies a driving need to learn doesn’t it?)
These are appropriate roles for the “change agent” – and they are things that can only be effectively done from a position of authority.
Which brings us to back to Learning to See.
Someone, a long time ago, proposed that we categorize activities as “value-added” or “non-value-added.”
We say that a “value-added step” is “something the customer is willing to pay for.” A “non-value-added step” is anything else. Some non-value-added steps are necessary to advance the work or support the business structure.
While this analysis is fundamentally correct at the operational level, and works to get a general sense of what it possible, this approach can start us off on a journey to “identify and eliminate waste” from the process. (Not to mention non-productive debates about whether a particular activity is “value added” or not.)
Right away we are limited. The only way to grow the business using this approach is to use the newly freed up capacity to do something you aren’t doing now. But what?
If that decision hasn’t been made as a core part of the challenge, the leaders are often left wondering when the “lean initiative” will actually begin to pay – because they didn’t answer the “Why must we do this?” question from the beginning.
Without that challenging business imperative, the way people typically try to justify the effort is to:
Analyze the process.
Try to quantify the waste that is seen. This would be things like inventory, walking distance, scrap, etc. that are easily measurable. More sophisticated models would try to assign value to things like floor space.
Add up the “proposed savings”
Determine a return on the investment, and proceed if it is worth it.
The idea, then, would be to deliver those savings quickly with some kind of rapid improvement process.
This fundamental approach can be (and is) taken at all levels of the organization. I have seen large-scale efforts run by a team of consultants doing a rapid implementation of an entire factory over a timespan of a few weeks.
I have also seen that same factory six months later, and aside from the lines that were painted on the floor and the general layout changes, there was no other sign the effort had ever been undertaken. In this case, no matter how compelling the ROI, they didn’t get anywhere near it.
One of the tools commonly (ab)used for this process is value stream mapping.
This approach is SO common that if you search for presentations and training materials for value stream mapping on the web, you will find that nearly all of them show describe this process:
Map your current state map.
Identify sources of waste and other opportunities on the current state map.
Depict those opportunities with “kaizen bursts” to show the effort you are going to make.
Based on what opportunities you have identified, and your proposed kaizen bursts, develop the future state map to show what it will look like.
Develop the new performance metrics for the future state.
Viola – make the case to go for it.
Now – to my readers – think for a minute. Where are the “kaizen bursts” in Learning to See? They are on the current state map, right?
Here is the current state map on page 32:
If, on the other hand, I were to ask “What value do we wish we could create for our customers that, today, we cannot?” I open myself up to a host of possibilities, including creating a new value stream that currently doesn’t exist at all – using freed up resources, at essentially zero net cost (or at least heavily subsidizing the new effort).
Now I ask “What must I do to make these resources available to me?”
In the “find and eliminate waste” model, the staff-change agents are often responsible for the “lean plan.” Like the job description above, they are charged with convincing the leaders (who hired them!) that this all makes business sense.
A Manual for How to Meet a Challenge
In “Part III: What Makes a Value Stream Lean” (the green tab) there is a strong hint of the original intent in the second paragraph:
To reduce that overly long lead time from raw material to finished goods, you need to do more than just try to eliminate obvious waste.
This statement implies that the value stream mapper is dissatisfied with the current lead time, and has a compelling need to change it.
What you are looking for in the Future State is how must the process operate to get to the lead time reduction you must achieve.
For example, given a target lead time and a takt time, I can calculate the maximum amount of work-in-process inventory I can have and still be able to hit that objective.
I can look at where I must put my pacemaker process to meet the customer’s expectations for delivery.
Based on that, I can look at the turns I must create in the pull system that feeds it.
Based on that, I can calculate the maximum lot sizes I can have; which in turn, drives my targets for changeovers.
As I iterate through future state designs, I am evaluating the performance I am achieving vs. the performance I must achieve.
What is stopping me from making it work?
What must I change?
If something is too hard to change, what can I adjust elsewhere to get the same effect?
In the end, I have a value stream architecture that, if I can solve a set of specific problems, will meet the business need I started with.
This is my view on the fundamental difference between creating a generic “crisis” vs. stating a compelling performance requirement.
The process outlined in the book is to develop the future state, and then identify what is stopping you from getting there.
Of the eight KEY QUESTIONS FOR THE FUTURE STATE that are outlined in page 58, “What process improvements will be necessaryfor the value stream to flow as your future state design specifies?” is question #8.
It is the last thing you consider.
The kaizen bursts are not “What can we do?”
They are “What must we do?”
The first thing you consider is “What is the requirement?”
“What is the takt time?”
In other words, how must this process perform?
Here is a clip of the future state map from page 78:
The “bursts” are not “opportunities” but rather, they represent the things we have to fix in order to achieve the future state.
In Toyota Kata terms, they represent the obstacles in the way of achieving the target condition, just at a higher level.
What this is saying is “To achieve the future state we need to rearrange the work flow AND:
Get the stamping changeovers down to 10 minutes or better.
Get the weld changeovers to where we can do them within the takt.
Get the welder uptime to 100%.
Get the work content for weld + assembly down to under 168 seconds.”
These are the obstacles to achieving the performance we want from the future state value steam.
Notice that the stamping press only has an uptime of 85% on the current state map. There isn’t a corresponding kaizen burst for that – because, right now, it isn’t in the way of getting where we need to go. It might be an issue in the future, but it isn’t right now.
But if we were just “looking for waste” we might not see it that way, and spend a ton of time and resources fixing a problem that is actually not a problem at the moment.
Putting This Together
Thus, I suspect that Learning to See, like many books in the continuous improvement category, was intended for value stream leaders – managers who are responsible for delivering business results.
In my experience, however, most of the actual users have been staff practitioners. Perhaps I should use the 2nd person here, because I suspect the vast majority of the people reading this are members of that group.
You are a staff practitioner if you are responsible for “driving improvement” (or a similar term) in processes you are not actually responsible for executing on a daily basis. You are “internal consultants” to line management.
Staff practitioners are members of kaizen promotion offices. They are “workshop leaders.” They are “continuous improvement managers.” The more senior ones operate at the VP and Director level of medium and large size companies.
No matter what level of the organization, you are kindred spirits, for most of my post-military / pre-consulting career has been in this role.
The people who actually read and study books like Learning to See are staff practitioners.
This creates a bit of a problem, because Learning to See is very clear that the responsible manager should be the one actually building the value stream map. But often, that task is delegated to the staff practitioner.
“Map this value stream, and please present your findings and recommendations.” If you have gotten a request or direction like that, you know what I am talking about. Been there, done that.
In my personal experience, although it gave me valuable experience studying process flows, I can honestly say that relatively few of those proposed “Future States” were actually put into practice.
The one that I vividly remember that was put into practice happened because, though I was a kaizen promotion office staffer, I had start-up direct responsibility for getting the process working, including de-facto direct reports. (That is a different story titled “How I got really good at operating a fork lift”)
Today we see Toyota Kata quickly gaining popularity. The Lean Bazaar is responding, and “coaching” topics are quickly being added to conference topics and consulting portfolios.
I welcome this because it is calling attention to the critical people development aspect that distinguishes the Toyota Management System from the vast majority of interpretations of “lean” out there.
But make no mistake, it is easy to fall into the tools trap, and the Lean Bazaar is making it easier by the way it positions its products.
Just as value stream mapping isn’t about the maps, establishing an improvement culture isn’t about the improvement boards, or the Kata Kwestions.
It is about establishing a pervasive drive to learn. In that “lean culture,” we use the actual process as a laboratory to develop people’s improvement skills. We know that if we do the right job teaching and practicing those skills, the right people will do the right things for the process to get better every day. Which is exactly what the title of Learning to See says.
This post rambles a bit, and wraps up a few concepts. It was, however, inspired by a recent interview of Mike Rother on Lean Nation. (See below)
One of the many good points that struck me was that you can’t rally around an ROI.
Yet companies try to do just that. They set something ROI or margin objectives, and wonder why everyone doesn’t pick them up and run with them.
Even companies that do issue a good challenge often come up wondering why the organization doesn’t align around it. Rother mentions one good reason: Nobody is there to coach them through meeting their part of the challenge.
A similar fallacy is trying to rally people around an abstract vision. I have experienced this a couple of times. A company tries to apply general education to people – lots of it – in the (vain) hope that once people “understand” then they will pick up the ball and run. But without consistent direction toward a limited objective that is easily articulated, people freeze up. “What do we work on?” There are too many choices.
Chip and Dan Heath discuss the importance of a rallying point in their book about culture change, Switch. They talk about “Pointing to the Destination” and “Scripting the Critical Moves.” When we talk about an aligning challenge, we are saying the same thing. Remember – in these initial stages you are trying to infuse a fundamental behavior and culture change. You can’t just tell people what it is and expect things to change tomorrow.
Classroom training may teach people the words, but it does little to accelerate the process of learning on the shop floor. That takes leadership.
More after the video:
One of the concepts that Rother discusses in Toyota Kata is the concept of “True North.” Spear also talks about it as striving toward the ideal process. Same thing, different words.
But at another level, when we are trying to shape a different management system, it is equally important for the leaders to have a “true north” for the ideal leadership process. I think this is different (or should be expressed differently) from the True North of the ideal value-adding process.
As I develop my own practice, I am honing in on those key elements of “leadership true north” and making it the cornerstone of my engagements. Mainly I try to describe specific behaviors and critical elements that need to be in place. This seems to play better than abstract concepts like “servant leadership” because it tells people what they need to do. (See “Script the Critical Moves.”)
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.
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.
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.
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.
In Chapter 2 of The Toyota Way to Lean Leadership, Jeff Liker and Gary Convis describe one of the most important, and least emphasized, aspect of developing leaders – the necessity for intrinsic motivation. In simple terms, the desire has to come from within. This theme ties together everything else in the chapter, and I suspect, through the rest of the book.
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.
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.
“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.
First of all, this presentation differentiates between a “challenge” and the target condition. That is important, and (in my opinion) had not been as clear in Rother’s original book.
I have been advocating setting a challenge, or campaign if you well, for some time. This is where we address a class of problems that are a major issue. Things like:
Too much cash tied up in working capital. (Which can be expressed a number of ways, such as improving inventory turns.)
Poor schedule performance – “on time delivery” becomes the theme.
Quality issues (too much rework, scrap, etc.)
Our nurses don’t have time to prepare rooms for the next patient.
Of course, safety can come into this arena as well, as can other issues that impact the organization’s health.
All of these things are not really problems in the sense that they can’t really be solved. These are the aggregated symptoms of lots of smaller underlying problems that accumulate into things on this list.
Setting a specific challenge doesn’t mean you ignore the other stuff. You have been coping with it and working around it for years. But you know you haven’t had time to fix everything, so stop believing that you do.
The point here is to galvanize the effort.
Chip and Dan Heath address the importance of setting the challenge in their book Switch (which I have reviewed here). They emphasize the importance of “scripting the critical moves” and “pointing to the destination” so that people have a good grasp of what is important.
Once the challenge is addressed, say “on time delivery,” it can be broken down into target objectives that are both local (large organizations need to have things broken down to what the local group is expected to work on) as well as those which cut cross-functionally. The scope of the effort is really defined by the depth of the organization’s skill at addressing the issues at this point.
Bill Costantino correctly points out that setting the vision, and deciding the theme or campaign, is a leadership function. This can’t be done by your “lean team” in a way that sticks. The discipline required here is for the leaders to maintain what Deming referred to as “consistency of purpose.”
Simply put, to say “this is the challenge” and then continuously ask about other stuff jerks people around and serves only to paralyze the organization until the leaders decide what people should spend their limited time on.
The good news is that it really doesn’t matter. If the organization can focus on One Big Thing long enough, their efforts will eventually touch on the other stuff anyway.
One place where I think we can still use some more clarity is in the illustration of the path to the target condition.
This is the illustration from Slide 20 in the Slideshare version of the presentation:
The presentation (and Rother’s coverage in Toyota Kata) is quite clear that navigation through “the grey zone” is a step-by-step process (kind of like driving off-road at night where you only see as far as your headlights).
But the “plan and execute” paradigm is very strong out there.
My experience is that people in the field see this illustration, and fully expect the green path to be set out, and the “dots” identified, along with a time line and resources required to get there. It becomes a “project.”
This is a strong symptom of the “delegate improvement” paradigm that we should all be actively refuting.
Let’s look at how I think this process actually plays out dynamically.
Initially we know where we are, we have target condition, so we know the direction we need to go to get there.
We are still inside the red line of the “current knowledge threshold.” Solving these problems is generally application of things we already know how to do, perhaps in new ways.
And having solved one problem, we now identify the next known barrier:
Once that one is cleared, we see a couple of choices. Which one?
All other things being equal, pick the easiest, and move on. (As we said when I was learning rapid maneuver tactics in the Army – “haul ass and bypass.”)
Up to this point, we have been operating inside the “current knowledge threshold.” Our efforts are better focused by pursuing a clear target objective, but we aren’t really learning anything new about the process. (Hopefully we are becoming better practiced at problem solving.)
Pretty soon, though, we reach the edge, and have to push out the red line. Why? Because we can’t solve a problem we don’t understand. As we approach the boundary, things get harder because we have to do a better job assessing, and extending the knowledge threshold around the problem.
This is the essence of the problem solving process – If you can’t see the solution, you need to better understand the problem.
The process becomes one of progressively solving problems, identifying the next, and expanding our understanding. Once there is sufficient understanding to anchor knowledge and take the next step, do so. Step and repeat.
Putting the whole thing in motion, it looks like this:
The key is that the “green path” isn’t set out as a predictable trajectory. It is hacked out of the jungle as you go. You know you are going, are confident you can get there, but aren’t sure of exactly what issues will be encountered along the way.
Let me apply my “Project Apollo Test” to this process.
Vision: “The USA will be the undisputed leader in space exploration.” Vague, a long way out there, but compelling.
Challenge, Theme: “…before this decade is out, […] landing a man on the moon and returning him safely to the Earth.” In 1961, a serious challenge, but considered do-able based on extrapolating what we knew.
At this point, though, space exploration was exploring a lot of different things. Building a space station, reusable launch vehicles, pretty much the whole gamut was being explored by someone, somewhere. The effort wasn’t focused. The “man on the moon” goal focused it. Every thing was pretty much dropped except solving the problems that were in the way of making Lunar Orbit Rendezvous work.
There were four target conditions that had to be cleared.
Build and test the Big Honkin’ Rocket called the Saturn V plus the infrastructure to launch them in rapid succession.
And they had to answer three questions:
Can people spend two weeks in space without serious physical or psychological problems?
Can we build a space suit that lets someone operate outside the protection of a space craft?
Can one space craft maneuver, rendezvous and dock with another?
In doing so, the threshold of knowledge expanded well beyond the immediate issues.
Yup, I’d say this thinking works, and it scales up.
Why did I go through this little exercise? Because if this thinking can put people on the moon, it is probably powerful enough to move your organization into new territory.
Back on Earth, a company undertaking “lean” needs to really grasp that they need to be committing to embracing this process. There are clear things that leaders need to do to make it work, and those things go beyond “supporting” or “sponsoring” the effort. We’ll get into some details on the next few posts as we continue to build on Rother’s and Costantino’s work.
I am in the process of (finally!) reading Mike Rother’s great book Toyota Kata. The book has already gotten great reviews out there, and I am not going to contribute a lot more to that dialog except to say I think it is the first substantial addition to community knowledge about TPS since Steven Spear published his dissertation in 1999.
As I go, I am taking notes of thoughts that are provoked, and I will share a few of them as they come up.
Early in the book, Rother makes a clear distinction between managerial systems that try to cost justify each and every activity, and those which have their focus on an ideal future state.
He cites a number of examples of how the dialog in these companies is shaped by this vision, or lack of it. This is one:
Almost immediately the assembly manager responded and said, “We can’t do that,” and went on to explain why. “Our cable product is a component of an automobile safety system and because of that each time we change over to assembling a different cable we have to fill out lot traceability paperwork. We also have to take to the quality department the first new piece produced and delay production until the quality department gives us an approval. If we were to reduce the assembly lot size from five days to one day we would increase that paperwork and those production delays by a factor of five. Those extra none-value added activities would be waste and would increase our cost. We know that lean means eliminate waste, so reducing the lot size is not a good idea.”
The plant manager concurred, and therein lies a significant difference from Toyota. A Toyota plant manager would likely say something like this to the assembly manager: “You are correct that the extra paperwork and first-piece inspection requirements are obstacles to achieving smaller lot size. Thank you for pointing that out. However, the fact that we want to reduce lot sizes is not optional nor open for discussion, because it moves us closer to our vision of one-by-one flow. Rather than losing time discussing whether or not we should reduce the lot size, please turn your attention to those two obstacles standing in the way of our progress. Please go observe the current paperwork and inspection process and report back what you learn. After that I will ask you to make a proposal for how we can move to a one day lot size without increasing our cost.” [emphasis added]
To this hypothetical Toyota manager, the ideal state is achieving one-by-one flow, on demand, in sequence, as requested, without waste. He sees the drive toward this ideal state as the method to drive the next problems to the surface which, when solved, will remove a round of waste from the process.
There are a number of key points to take away from this.
Avoiding waste vs. removing waste. The assembly manager is confusing the avoidance of wasteful activity from removing wasteful activity from the process. The large lot sizes are avoiding wasteful activity, but it is still there, lurking under the surface as a barrier to further improvement.
One-by-one flow as a crucial goal. In this example, the concept of one-by-one (or one piece) flow worked exactly as it should. The discussion, or attempt, to implement the next step in that direction revealed the next barrier that must be addressed on the way. Without the imperative to reduce lot size toward that ideal, these reasons, justifications, barriers, excuses prevail and the wasteful activity remains. Yes, its effect can be mitigated by larger batches, but applying that logic, why not make the batches even larger?
It isn’t about what waste you can remove.It is about what wastes must be removed to achieve the next target condition. Having this sense of the ideal to define the direction of progress focuses the team on removing the next barrier to higher performance. This keeps things on a path toward higher system performance. Contrast this to the classic “drive by kaizen” approach where we go on waste safari and then look for opportunities where waste we can remove the most easily. This results in a patchwork of improvements that rarely find their way to the bottom line.
Cost justification would say leave the waste there. The cost justification for reducing lot sizes comes primarily from the reduction of inventory holding costs. Unfortunately, unless the inventory is insanely expensive (like jet engines), that alone rarely justifies the effort. But this thinking also stops any further opportunities for improvement in their tracks.
On the other hand, if the goal is to drive toward the ideal of one-by-one in a way that does not increase cost, then once this single-day lot size is achieved, they would be asking “What will it take to get to half a day?” Eventually they will be asking about every part every day. And then true mixed one-item-flow.
At each juncture an important thing happens. They must confront the next problem, and the next waste in the system. They must find a way to remove that wasteful activity without increasing cost. Eventually they will be making one cable each takt time, and following that, making the cables and installing them immediately.
To get there all of the inspections and traceability paperwork requirements will either be removed as no longer necessary or will be built in to the process itself. How will that be done? I don’t know. Nobody knows. That is the point. We can’t solve all of the problems ahead of time, nor can we solve them before they are discovered. The path to the ideal state is vague and unknowable when you begin. It is revealed step by step, as you take those steps.
The key is to have faith that, among all of the people in your operation, someone will find a way to crack that next problem.
This is how you harness people’s creativity.
In his classic JIT Implementation Handbook, Hirano says to force one piece flow to reveal the waste in the system. That was in 1988. Rother introduces the critical human element into the equation. One piece flow is not an abstract concept, it is a critical guide for management decision making.
Rother goes on to make other examples. In each case, the tool or technique – such as takt time or leveling – specifies how we want things to work. That provides a baseline for comparison so we can see the problems we need to work on next.
Here is another example. Ironically, while Rother uses it in his book, I have experienced it in real life. The factory is trying to introduce leveling. They set up a stock of finished goods. They set up a kanban leveling box, and they set up a fairly well thought out process of leveling the demand on the production stock, allowing the inventory to absorb the ups and downs. Their rule is that if the inventory hits a high or low limit, they will take action and assess what is happening.
Then the email arrives – “A big order arrived, and flushed out our inventory, we had to catch up, what do we do?”
After doing what is necessary to recover the system, this was a great opportunity to look at why orders arrive in big batches. In this case, I suspect it was an artifact of the company’s distribution network. The plant is at a critical crossroads.
Each of these examples leads me to the same thought.
The “Yes, but…” and the “Now what?” situations are going to happen. They prove the system is working to surface the next problem to be worked on. The reply that follows decides the fate of your improvement process.
You can reply the way the Toyota manager did in Rother’s example, and work hard to improve your process.
Or you can buy the Basic Story that is presented, and in effect agree that no further improvement is possible on this process, or that “lean doesn’t work for us because [put your “unique situation” here]”.
This started a rather deep email exchange with Michael Ballé that goes far deeper into the book and the thoughts behind it than any review I could ever write.
With Michael’s permission, here is that exchange, with minor editing mostly for readability and flow.
My words are in blue.
Michael Ballé is in black.
Text [in brackets] are my additions to help context.
Here’s the acid test:
Would you agree that Jenkinson play a different role from Jonah [in “The Goal”] ?
(hint: he is the lean manager :))
Actually, no, I don’t think Jenkinson plays a dramatically different role than “Jonah.”
Perhaps if the story had been written from Jenkinson’s viewpoint, with insight into his thoughts and worries about Andy, rather than a third-person view of his actions and words, I would agree. Then it would be about Jenkinson AS a lean manager.
But what we have is Andy Ward’s experience of Jenkinson. Thus, I don’t get any particular insight into what Jenkinson is actually thinking about how to get his message across to Andy except in the moments when he shares his thinking in conversation with Andy.
For example, Jenkinson (and Amy and Bob) are driving the concept of the problem solving culture from the very beginning. But Andy isn’t “getting it” until late in the story.
What was Jenkinson’s internal response to Andy’s misguided approach? What mental PDCA did Jenkinson apply when he saw the right results being gained at the expense of the social structure in the plant?
Thus, this comes across as a story about Andy Ward learning through his interactions with Jenkinson (and Amy and Bob Wood), and his experiences in trying to apply what they were telling him, rather than a story about Jenkinson’s approach to leading and teaching.
So the story is (to me) much more about Andy *becoming* the lean manager than Jenkinson “being one.”
The real difference between Andy Ward’s experience and that of Alex Rogo (his counterpart from The Goal) is that Andy’s boss is participating directly in Andy’s success vs. just issuing an ultimatum. Thus, Jenkinson embraces the role of the teacher as well as the boss.
Yes – that is exactly the message – that “leading” in the TPS is teaching. But I think [The Lean Manager] is much more about Andy learning it than Jenkinson teaching it.
The characters of Amy and Bob Woods seem to be there to add credibility since a CEO really doesn’t have this amount of time to spend with a single plant manager in a large global company. But they are so well aligned with Jenkinson’s approach that they are surrogates for him.
Thus, Jenkinson is the “teacher” in a story about Andy’s insights and development as a leader.
THANKS for asking the question.
It really made me think.
One of the writing issues we’ve had was that Freddy and one of his CEO friends felt Jenkinson was underdeveloped whereas Tom [the editor] and I felt he was already far too omnipresent compared to Andy Ward. The basic challenge for the book was to share the experience of what it feels like to be a plant manager stuck between the hammer (CEO) and the anvil (real life in the plant).
Jenkinson was conceived to be this Batman-like scary character. He is a teacher, but not a very good one. Basically, his one redeeming teaching feature is his patience, but, hey, the guy is a CEO. I’ve worked with several, and then I’ve spent most of my time working with the plant managers so its the latter’s pain I wanted to share. Having said that, all your points are correct, and indeed, Freddy would agree with you.
More seriously, and I hope I can convince you …that [Jenkinson’s character is not a “Jonah”] because it’s a fundamental point I’m trying to get across. As you say, the fact that Jenkinson is Andy’s boss makes it TOTALLY different from the Jonah situation. Obviously I didn’t manage to get this across well enough, but having to learn from someone who holds the sword over your head is a vastly different issue than having found a great teacher (I’d agree with Woods/Jonah), no matter how cantankerous.
This learning-from-boss issue has to be my top of the list reason why lean is spreading so slowly. So I’d argue that beyond literary devices (how many lean novel plots can there be?) this is indeed a core point of the book.
Where I’ve obviously not written this well enough is that Jenkinson IS teaching, but in a boss kind of way, which is a very different position. In particular, I’ve been very mindful (maybe even heavy handed) of the fundamental asymmetry between roles, and the whole issue of how to deal with a boss’ comments.
By the way, Jenkinson is also doing what he can with the people he’s got (can’t replace them all, right?) For instance, you’ll notice that he gets very different responses from each of his plant managers. Jenkinson’s modus operandi is to show a lean problem to the plant manager, draw a line in the sand about where he wants him next, and push him/support him to get there; As people are different, each plant takes a very different path to lean its operations and requires a different mix or arm-twisting and lecturing.
The reason we never get any direct “look” into what Jenkinson really thinks (although we do many other characters) is that I wanted to reproduce this “boss” aura – no one ever actually knows what the boss thinks. We’ve discussed this quite a bit at the time of the writing, and your comments are spot on so I’m really interested in your opinion.
[a follow-on note]
Jenkinson was actually built on what I saw my dad do when he was CEO (I was helping him at the time with expliciting the “System” – I’m a sociologist). So Jenkinson does five [six, actually] things:
1) He forces. At several points in the book, he tells people: that’s the way it’s going to be. In the German plant, in the French plant with the impromptu kaizen, with the strike, etc. Basically, he forces his managers to commit and/or do something right away IN FRONT OF THEIR TROOPS. This is a specific technique – and not an easy one.
2) He gets them to go further in their thinking. At several points, Jenkinson works with Andy to push his questioning further (not always explicitly “why?”, but it does happen. Freddy, who used to be feared because of 1), was surprisingly in the HOURS he spent doing just that. It’s equally terrifying when you’re on the receiving end because, at first, subordinates are fishing for the answer they think the CEO wants to hear, and not thinking – which makes for a lot of frustration both ways.
3) He forces people to work together, particularly when they don’t want to. Actually, Amy does this in Andy’s plant at first with the production plan issue, but Phil forces the Neville/Andy link, and later the Engineering teamwork.
4) Phil encourages “problems first” at several occasions, which is trying to tell his guys that they come to him with problems rather than let them fester, and that if he learns of the problem from someone else first, that’s bad.
5) He lectures – although this is against his own expressed principles – as he states in the car at the beginning of the book. Phil is not so enamored with the sound of his own voice as the author, but we’re still all human, right?
One more thing Jenkinson does on several occasion:
6) “Stay on target, stay on target” – Andy keeps being distracted by all sorts of things, internal politics, problems in his plant, etc. Jenkinson realigns him at almost every conversation 🙂
The two insights we have in Phil’s thinking are:
– when do I pull the plug (close the plant, fire the plant manager/regional manager/sales VP, etc.)
– dealing with the politics of senior management
In writing the [business novel] genre You’re stuck between expliciting the thinking (the lecturettes, love the word), and sharing the experience through an action scene. Then there are the limits of the author’s writing talent – I had to really sweat it before trying work within the plant as opposed to out of it (The Gold Mine), because trying to describe a working plant environment is something of a writing challenge.
A couple of questions –
Who is the “ideal reader” – the target audience – for “The Lean Manager?”
What are the explicit teaching points the story is intended to present to the reader? What does this ideal reader take away?
What should the target reader do differently after reading the story?
What aspect of the story gives him that insight?
Did you have those things in mind as you wrote it? Or did the emerge with the story development?
I see Andy as the central character of the story. It is he who undergoes the personal transformation, and the storyline revolves around his interaction with the other characters. As you intended, is a sympathetic character that many people the in the same position will identify with.
Thus the learning from the book is transmitted through Andy, based on his experiences.
I see Jenkinson as a (primary) supporting character, who in combination with the others, shapes Andy’s experience, and through that, shapes the reader’s experience. But in the end, he is mainly a teaching character.
Yes, he is also the boss and needs the results. He leads by example. He teaches “forcing teamwork” by doing it. He makes his intentions crystal clear, does not do hollow posturing, and can play the political resistance against itself. But to Andy, he is sensei.
A good student will be motivated by wanting to please the teacher. In this case, it is also an economic / career imperative, but in the end, it is about a motivated student.
The key points of what to teach certainly come out in the process, including the fact that Andy learns a few things the hard way in spite of being told (like the teamwork thing).
But overall, it seems to be about “How to be taught” by a true lean manager more than it is “how to teach like one.”
If the key point is to teach a senior executive HOW to be a “lean manager” then I guess I’d have written it from the teacher’s perspective rather than the student’s.
If I were a CEO or senior executive, I’d like to know what Jenkinson was thinking when Andy was getting bogged down in distractions. If the target audience for the story is a senior executive or CEO, then I would think the CEO character has to be the sympathetic character, with the frustrations and problems that these guys can relate to. Then they can see he isn’t “Batman” in a comic-book city, but he is dealing with the same problems they are.
John Shook made an attempt at that in “Managing to Learn” but the scenario was too limited to really create any dramatic “ah-ha” moments.
I think Dr. Bahri’s self-experience (Follow the Learner) was a unique perspective of learning-by-doing, but, again, the scenario is too limited for most people to see beyond a medical or dental practice.
So – after re-reading my own note above, and going back to your earlier note regarding your debate about Jenkinson’s character development vs. his “omnipresent” relationship with Andy
– I guess I’d say that:
With Andy as the point-of-view character, then Jenkinson’s development is appropriate.
But if Jenkinson is actually the title character, then I can see where Freddy and his CEO friend felt that he should be more developed. The difference is that, to get that development, the perspective of the story has to shift from Andy to Jenkinson as well. Then the “omnipresence” drops away as an issue because it is about Jenkinson teaching rather than Andy being taught.
One possible follow-on story could be this shift to the teacher’s perspective. Perhaps there is a new acquisition and Jenkinson assigns Andy to mentor the manager there through a turn-around as Andy’s next development assignment. Now Andy is the teacher, (with Amy’s help, or through the A3 process with Jenkinson), and we see the teacher’s perspective as he is trying to keep the student focused on the right things in spite of the noise and chaos that, perhaps, Jenkinson is throwing at it with his demands for performance.
Andy must simultaneously understand “the main problem” in the plant, and get his student to understand it without just telling him the answers. Maybe he sees the guy as a hopeless concrete head, and Jenkinson has to force him to be patient and stick with it.
What does a competent operations manager need to learn to be able to teach someone else? How does he learn it? What is the development process for that?
Then we would have a story of not only how to BE a lean manager, but how to teach one to teach another.
The books are about 1) teaching and 2) sharing an experience. It all flows from here – I never had a target audience in mind.
The Gold Mine was all about describing TPS from the point of view of a smart guy, who’s got the power to affect changes, but has got to learn all this stuff – that was Jenkinson then. The experience I tried to share then was “The Curse Of Knowledge”.
To Jenkinson most of TPS is new and counterintuitive and every time he’s picked something up, there’s more to it (and I still experience this fifteen years later), because you don’t know what you don’t know.
And for Bob Woods, the impossibility of expressing what you’ve figured out over years to someone, hence the annoyance and grumpiness (not “Jonah” 😉 ). Add Amy, who thinks she’s getting it because the tools make sense to her, but she doesn’t understand the wider business picture nor why older people have trouble thinking that way and you’ve got The Gold Mine. Now, the trick is in
1) sharing an experience and
2) conveying the concepts, so sometimes I get it right sometimes not.
Pat Lancaster of Lantech fame, made the same type of comment [about The Gold Mine] you did: “Why didn’t you write it from the plant manager’s perspective?” To convey the absolute panic of the moment you’re about to pull the plug on the MRP. The comment stuck, and eventually that became The Lean Manager.
The gimmick in [The Lean Manager] is that BOTH Jenkinson and Andy are “the lean manager” – Jenkinson is the closest I can make it to a lean boss outside Toyota (those I’ve known anyway) and Andy is learning that stuff – with the added twist of the asymmetry of relationship that defines authority relationships.
The Gold Mine was about TPS, and this one is about Toyota Way.
My overriding problem as a consultant on the shop floor when I talk to senior execs is: “Are we on the RIGHT problems?” The problem with consultants (me included) is that they seldom understand enough of the business to focus on the right things (not a problem to Toyota consultants with suppliers, because, well, auto is auto).
So I like the idea of Amy consulting with some company and getting them to fix the shop floor and yet having no results on the business because the real problem is in engineering – where she’s got everything to learn (enter Woods & Jenkinson). If I do that, definitely “teaching the stuff” becomes an issue (since this is my specific expertise, I’ve resisted going there so far not to pollute the message too much with my socio-techno stuff)
Will have to let this one simmer for a while.
In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.
I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest (more for the next book).
The only way I know how to fight on the field of ideas is by writing books and then getting them into people’s hands. So now that it’s out, I’d like to get it in the hands as as many people as I can to try and change the zeitgeist… Not my favourite activity!
I really wanted to share this exchange with you because it highlights a couple of the main problems that are encountered in any attempt to implement real change.
To quote again from Michael’s note:
“In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.
I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest.”
And, in the end, there it is.
Ironically, if you are even reading this, you already know it.
The Lean Manager is a success story, driven by the people who are actually responsible to deliver the results. While Michael and I may quibble about whether or not Phil Jenkinson is a “Jonah” character in the sense of The Goal is a discussion about literary structure rather than the core message here. What all of these books have in common is that it is the leaders who drive successful change.
The “slow progress of lean” comes in situations where the implementation is delegated to staff with the charter to “do it to someone else.” And, in my experience (having spent a painful amount of time as that staff), that situation is far more common out there.
I have more to go on this, but I am going to leave it for another day.
In my review of Kaizen Express back in May, I took LEI to task for two things – First, I didn’t feel Kaizen Express contributed anything really new to the body of knowledge. I would have been satisfied if it had more clearly explained what had been said before, but it didn’t do that either. Second, and more importantly, I felt that Kaizen Express, and the LEI in general, were propagating the conception that the tools were what defined “lean” and that “the tools” were “the basics.” I disagreed on both points, and still do.
I am now about halfway through The Lean Manager, and I believe this book is addressing those issues – and hopefully challenging some of the thinking within the publishers. In other words, in its content, this book is everything that Kaizen Express isn’t. Get it. Read it. Do what it says, and you will actually be implementing the basics.
What makes this different? Instead of revolving around technical descriptions of the tools, this book clearly shows the proper relationship between the tools and the two most important aspects of what makes the Toyota Production System work:
Leaders (and how they lead and what they lead – and it isn’t implementing the tools)
People (yes, other books pay lip service by mentioning shop floor engagement, but The Lean Manager is all about shop floor engagement)
The authors start to hammer home the point in Chapter 2, Everybody, Every Day. In one of the many lecturettes they use to convey the key points via their characters, Amy, a corporate consultant, sums it up:
“Everybody, everyday solving problems, that’s the only answer to the Pareto dilemma. You’ve got to visualize two flows in the plant. One: the product flow[. . .]. Two: the problem flow to the person who finally solves the problem. [. . .] you shouldn’t funnel all problems to your key technical people. You should protect them to work on the really difficult issues. What you have to organize is the problem solving in the line!”
And with that, the rest of the story follows – this fictitious plant manager under fire in this fictitious company sets out to do that.
The subsequent chapters (so far – remember, I haven’t finished the book yet) are Go and See, which hammers home the importance of the leaders – all of the leaders being present, not just to witness problems, but to ensure they are being solved by the right people, in the right way. Further, they must break down any barriers which impede that flow. And it’s not just the leaders. Ultimately, the entire shop floor is organized so that everyone is immersed in genchi genbutsu every time a task is carried out or work is performed. This becomes the check in PDCA.
Chapter 3 is titled Managing is Improving and begins the confront the psychological and organizational aspects of the changes that are now coming to a head in the story. This part requires the most creativity on the part of the authors, as it is an entirely human process. Because it is a human process, not a technical one, it is impossible to write a technical manual on how to do it. It requires knowledgeable, dedicated leadership that is humble enough to stake out a position that might be wrong, knowing that doing so improves the chance of learning something.
And that has been the issue in our industry. It is far, far easier to describe the tools in excruciating detail than it is to confront the leadership and organizational change issues. And because the technical descriptions predominate the literature (including, and especially what has come out of LEI for the last 10+ years), it is far easier to believe that “implementing the tools” is something that leaders can delegate to specialized technical staff.
This book, so far, is (rightly) turning that thinking on its ear.