It must be that time of the year. I see traffic in the online forums asking about how to set key performance indicators for lean staff people so their performance incentives can be set.
If anyone were to ask my advice here, it comes down to one word:
Don’t.
Two reasons.
First, we have overwhelming evidence that these incentives not only don’t work, but they actually make performance worse in the kinds of work you are asking these people to do.
All of this is consistent with what Deming told us decades ago, yet we keep doing it.
The second reason is inconsistency and misalignment.
Having the continuous improvement staff operating to separate metrics disconnects their efforts from line management’s. They become responsible for improving the operation while the line management processes are… what?
The message to the shop floor team is pretty clear here. They can read an organization chart. Do what the boss says, then, if we have time, and if the improvement guys can make the case, then maybe listen to what they have to say.
If you must have management-by-KPI, then the performance measurement for continuous improvement must be exactly the same as the line manager being supported. Why?
The question I would ask is “Who is responsible for the performance of the organization?” If it isn’t the line leader, then why does that position exist?
It makes no sense whatsoever to have the lean implementer working to a different agenda.
Our management traditions of de-aggregating and delegating are not serving us well. We need to take a systems view and realize that everything is inter-related. Further, we need to grasp that B.F. Skinner’s (dubious) research on rewards-based-behavior simply does not apply to management. Never has. Wishing otherwise isn’t going to change it.
How many “If-Then” steps do your team members have to deal with in the course of their routine work?
Every one of those branch points is a decision. It is a point where the team member must memorize decision criteria and the correct choice(s).
Each “If-Then” in the process flow potentially doubles the number of possible paths the process can take.
Each decision is an opportunity to make a mistake.
The more complex a process, the more time and experience the team member requires to master it.
Mental bandwidth is limited.
The more attention they must expend to do it right, the less they can devote to thinking about how it could be done better.
How complicated a world do you create for people trying to do the work?
The more “flexible” your human interface with the process, the more complicated it is for the person who has to use it.
Do they have to enter ad-hoc query criteria into computers to pull information they routinely need every day?
How many decision criteria are things that people “just know?”
How often does someone encounter a problem or new situation and get a verbal instruction from the supervisor on how to handle it? What happens then? Maybe a general announcement at the next team meeting, if you’re lucky?
Go down to your work area.
Watch how people interact with the routine work.
Each of those decision points is an opportunity to simplify your process flow and make life a little less stressful for all of you.
Today’s Dilbert strip highlights a situation that is only funny because it happens so often:
The idea that a company can focus on 25 key areas, or 125 key performance indicators (yes, I said 125 because I have seen it myself) is obviously ludicrous.
Of course a manager has a legitimate concern to ensure people don’t take their eyes off things that are important to focus on something else.
But the leader’s role here is to ensure there are processes and systems in place that anchor the routine things. Further, those processes and systems need to be designed to alert the appropriate people when something goes out of control, or past a boundary.
Without having any routines the manager has no choice but to make everything something to focus on.
Because there is no standard process, everything must be managed as an exception.
This stresses the organization because in reality they can only micro-manage a few things at a time. It is left up to the people to decide what isn’t going to get done. The bosses response at that point is going to be negative no matter what they accomplish. “Respect for people” does not play here.
Leader’s toughest job is deciding what we are not going to work on right now. It isn’t as tough as it seems because if a focus or challenge is selected well, it actually organizes the problem solving effort to pull just about everything else in behind it.
Let’s take an example from a previous post: On time delivery.
If we say “We are going to emphasize “on time delivery” as a theme or challenge this year, what kind of things might people end up working on?
Having every operation start on time.
Sources of delay.
Quality issues (which cause delays)
Safety issues (also cause delays)
Visual controls and good response to problems (to get on top of problems quickly)
Equipment reliability.
Setting a good operational takt time.
The list goes on. But by having a decent challenge, the local area can focus on the things that are impacting their ability to deliver on time. It isn’t necessary to make a laundry list of everything that could cause a delay and measure it from the top of the organization. If you do, everyone’s energy is dissipated working on problems that they don’t necessarily have.
Of course this is all based on having a leadership process that gets down to the work area, grasps what people are actually working on, and coaches them through the process of aligning their efforts and solving the right problems in the right way.
Hmmmm… so does that mean that the #1 thing to focus on if you want consistent on-time delivery might be leadership development?
I guess I need to get back to the Liker and Convis book.
It seeks to draw a sharp contrast between Toyota’s leadership model and the model that is taught and practiced in a more “traditional” Western company.
Where the “teaching” process in a traditional company tends to be tacit – reinforcing some behaviors and discouraging others, in the Toyota described by Liker and Convis, the process is far more deliberate.
It is a process of aligning to explicitly stated core values that have been in practice since the inception of the company, but only written down in 2001 as The Toyota Way 2001.
Then, because the word “leadership” often carries one of those “I know it when I see it” kinds of definitions, the authors use examples and construct a model to describe what they have observed. That model then structures the next few chapters (Yes, I peeked ahead).
Across the chapter they are describing leadership, not as something practiced by individuals, but as an interdependent ecosystem that links tightly to every aspect of the company. Certainly individuals each have their own style, but it is expressed within a context defined by commonly held beliefs and norms of behavior that combine to form what we call a “culture.”
Someone from outside that culture (such as Gary Convis coming from Ford, and other Toyota managers I have known personally), has to work hard to assimilate into it.
Outside the context of the book, I have also seen the opposite: Take someone who knows nothing but the Toyota culture and put them into a “traditional” company and many of them have a hard time adapting to a completely alien environment. The support structures they are used to are simply not there, and it can be psychologically very isolating.
One example of this contrast is in how these two systems see “Challenge.”
In a traditional company, a “challenge” is issued as a “stretch goal” and it is up to the individual to figure out on their own how to meet it. In the most extreme case of an “only results matter” environment, they may disregard their fellow team members, rules, ethics, even the law to get there. While we have spectacular examples such as Enron, there are lots of companies where “inventory targets” are met by starving off production at the end of the quarter and pulling in orders from the next.
“Challenge” is one of the explicit values in The Toyota Way 2001 but it looks quite different. Yes, there are challenges issued. But behind that challenge is a support structure. The leaders, at all levels are expected to stretch their own personal development, but to do so within the context of kaizen, deep understanding gained by genchi genbutsu, team work and most important of all, respect.
The leader’s development level is gauged by how the challenge is met even more than whether it is met. Just “get-r-done” doesn’t work here.
Needs to be covered again, because most people act as though we don’t know it.
Simply put, Liker and Convis (legitimately) feel the need, once again, to let us know the things which reliably fail when trying to build a sustaining culture of continuous improvement.
“So let’s train some Lean Six Sigma experts to grab the tools and start hacking away at the variability and waste that stretch out lead time; this will make us more successful, both for our customers and for our business. What could be simpler?”
What indeed.
I am, once again, reminded of a saying that “People will exhaust every easy thing that doesn’t work before they try something difficult that will.”
The authors cite some of the same things that we have heard before:
Trying to determine ROI for each individual process step, or each individual improvement, doesn’t work.
Trying to motivate the right behavior with metrics and rewards doesn’t work.
Trying to copy the mechanics doesn’t work.
Trying to benchmark, and copy, a “lean company” in your business doesn’t work.
Yet, even though we have been hearing these messages for at least a decade, actually longer, I continue to encounter managers who try to work this way.
The authors assert, and I agree, that this is the result of people trying to fit Toyota’s system into a traditionally taught management paradigm that is so strong people aren’t even aware that there is a paradigm, or can’t conceive there is anything else.
This reminds me of the Edwin Abbot’s 1884 story of Flatland, a two-dimensional world populated by creatures who cannot conceive of “above” and “below” their planer existence.
Although his story is often read by students struggling to grasp models with four, five and more dimensions to them, it is really a story of social change and paradigms.
Our management systems are a “flatland” with Toyota’s system existing in a space that we have to work hard to grasp. We can see pieces of it where it touches ours, but like the creatures in Flatland who only see two dimensions of three dimensional objects, we only see the pieces of TPS that we can recognize.
One of the graphics in Bill Costantino’s presentation really struck me, but my thought was out of context so I wanted to make a separate post about it.
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.
I am starting to read a review copy (courtesy of McGraw-Hill) of Jeff Liker and Gary Convis’ new book, The Toyota Way to Lean Leadership. (The hot link goes to my Amazon page.)
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.
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.
Jim Collins uses different words to make the same point in Good to Greatwith the “Hedgehog Concept.”
The Path to the Target Condition
One place where I think we can still use some more clarity is in the illustration of the path to the target condition.
This is the illustration from Slide 20 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?
Of course each of these objectives, in turn, had lots of smaller challenges. NASA’s effort between 1962 and 1966 was focused on answering these three questions.
In doing so, the threshold of knowledge expanded well beyond the immediate issues.
Yup, I’d say this thinking works, and it scales up.
Why did I go through this little exercise? Because if this thinking can put people on the moon, it is probably powerful enough to move your organization into new territory.
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.
“Experience by itself teaches nothing… Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.”
–W. Edwards Deming, The New Economics for Industry, Government, Education – 2nd Edition
The field of psychology, it seems, shares an issue with the field of operations management.
This is fairly heavy reading since it is likely from outside your field, but the core message is here (paragraph breaks added for readability):
Theory in Science As I try to teach my students, the role of theory in science is to provide structure to your data. A good theory rules explanations in and out, and if it rules out the wrong explanation that will become clear over time as you pursue your theory guided research.
Good science means a) restricting your explanatory mechanisms to include things your theory allows, and b) keeping an eye on how well that’s working out for you, while c) allowing yourself to rest on your well supported theory to resist breaking the rules as long as you can.
As Deming points out in the quote at the top of this post, having a theory – a solid statement of what you believe is true is a prerequisite for learning to take place. Without that theory, events and information simply get filed away as “interesting.”
With a theory, each is compared against the prevailing thought and forces us to reflect on our understanding.
Sure, we run into confirmation bias (where we unconsciously exclude things that contradict our beliefs) and other logical flaws, but honestly – if scientific thinking were easy, we wouldn’t have to discuss it.
This is pertinent to us at a couple of levels.
At the macro-level we have the proliferation of “solutions” out there for management. We all talk about “flavors of the month” and “alphabet soup” as we see companies cycle through the various structures for “world class performance.”
Wilson and Golonka’s message, and our problem, is that in attempting to embrace everything, we embrace nothing.
Of course part of the problem is that book authors and management consultants are not, by and large, researchers who are interested in unifying the theory. Quite the contrary. They are interested in differentiation. This causes problems for people who see these various “solutions” as competing somehow. (In reality, they are mostly re-packaging of subsets of the same overall stuff.)
OK, we can’t do much about that in the larger sense, but within your company, you can.
I have yet to encounter a situation that is outside of my baseline theory of “what TPS is.”
As I said in a talk I gave last week, the only faith-based position I am asking you to embrace is that if your results seem incompatible with TPS, look at your understanding and deployment before rejecting it as unworkable.
While we wait for the MBA programs and influential institutions in our field to catch up, we can continue to identify in forums like this one which authors and researchers we think are largely congruent with one another and some kind of common baseline.
The other area where this message is applicable is in our daily approach to process design and problem solving.
Almost all of the “tools of lean” (and many techniques not especially associated with TPS) are really designed to develop and test a working theory of how the process should be working.
Takt time is a great example, though far from the only one.
I set up a process to operate at a certain speed. I say, in effect, “if the process has no unexpected problems, this is how long it should take.”
That is a theory.
I test the theory each and every time I run the process.
When (not if) something unexpected happens – when the team member can’t meet the standard work for some reason, then we have data that is not congruent with our baseline theory.
Now we can get into understanding why – what happened that we didn’t count on. Likely (in this example) something uncontrolled tripped him up. In experimental terms, we didn’t have the baseline conditions.
In our process terms, we now have a problem to solve – how do we keep that issue from coming up again, so that our team member can do the work in the time expected?
As we cycle through this thinking again and again, each iteration either cleans up some issue in the operation (which is continuous improvement), or we realize that we should have included this factor in the original plan (we modify the working theory).
Either way, our knowledge of the process is improved.
In reality, these two cases – micro and macro – point to the same thing. We need the macro (the theory of management) to reflect that we need to incorporate this thinking into the way we manage everything.
I spent last week teaching three sessions of Job Instruction. One session at the end of night shift starting at 5am, the second session catching the start of day shift at 7am, then the third session for swing shift at 1:30.
What is cool, though, is there is a senior member of the site leadership team in every session. They are not just observing, they are active participants.
Next week those leaders, with input from the team members in the class, are going to caucus and discuss the ramifications and how to deploy this method across their operations.
This is critically important because just teaching a few dozen people a skill and expecting them to each apply it independently doesn’t work. The company has to also develop the ecosystem that it can flourish in.
But this has been the pattern from this company from the beginning.
The Operations Manager has been leading the operations kaizen teams, working hard along side the team members to develop disciplined, effective pull systems. This is a high-variety product mix, with lots of different routings, so there were some real challenges to overcome. I was really impressed with their application of what would normally be very advanced thinking.
Results? Over the last six months, their metrics have taken a clear turn upward. You can see the inflection point on the graphs. Their company sister operation is starting to take notice. Good things all around.
A plant manager once shared a conversation he had with his CEO. The teaching is important, but what makes it work is willingness to be taught.
When we talk about management involvement, this is the crux. This team has been curious, willing to try and explore things – in front of their team members – and willing to keep at it until they figure out how to make it work.
