Tag: People Development

Posted on

Where Is “Culture” Created?

The idea of a continuous improvement culture, a problem solving culture, a kaizen culture, has been with us for decades. Ultimately it is what everyone says they want to create. Yet creating that culture remains elusive for all but a few.

I have noticed that, generally, when people describe the culture they are trying to create they do so in terms of what people do.

  • Leaders support the changes.
  • Team members take initiative.
  • People “see waste and eliminate it.”
  • People engage in problem solving.
  • Team members are fully engaged in improving their own work.

All of these things are true, but they miss the mark.

They are all the actions of individuals, sometimes interacting with a process.

But what is “culture?”

I would contend that “culture” is composed of the norms and rituals of how people interact with each other.

For example, prolonged direct eye contact (“staring”) is rude in some cultures, but not in others. Cultural norms define how subordinates interact with their bosses, where people sit, whether they bow or shake hands when they meet. Cultural norms define how problems are brought up – by whom and to whom – or if they are brought up at all. In some cultures, “losing face” is a disaster, in others, openly blunt honesty is highly prized.

Within a company, of course, there are additional layers. In addition to the social norms of the society at large, there are rituals and norms about how people interact at work.

Therefore, I would contend that “culture” is something which emerges from the pattern of interactions between people.

Why is it important to understand this?

Because if we are trying to change the culture, we should not be focusing so much on individual behaviors as we are coaching those interactions.

In “Toyota Kata,” Mike Rother describes structured, practiced behaviors that are the building blocks of a culture of continuous improvement. Like kata in martial arts, more sophisticated moves are built up from these fundamentals. But if you really look at it, the behaviors he describes are actually interactions.

What this means is that if we are trying to coach toward change, we need to be simultaneously coaching at least two people at once. In each of these interactions there is a request or stimulus, and there is a response. Each has a specifically defined “way to do it.”

Stepping back a bit, if I look at Steve Spear’s “rules-in-use” from “Decoding the DNA of the Toyota Production System” I see the same patterns. The rules actually define structure for how people and processes are interacting with one another in a way that drives continuous improvement.

Just a thought for the day.

Posted on

Toyota Kata: Avoid Pareto Paralysis

A great key point comes out on page 124 of Toyota Kata by Mike Rother.

…a Toyota person once told me to focus on the biggest problem. However, when I tried to do this I noticed a negative effect: We got lost in hunting for and discussing what was the biggest problem. When we tried gathering data and making Pareto charts, it took a lot of time and the biggest problem in the Pareto chart was usually “other” which put us back into debating options. By the time we decided what the biggest problem was, the situation at the process had changed. This effect is called Pareto paralysis, and I encourage you to avoid it. Pareto paralysis delays your progress as people try to determine the “right” first step to take.

[…] it matters more that you take the first step than what the first step is.

I have seen this many times with my own eyes. It is a common problem when “problem solving” is taught as “application of the seven tools” and “correct” use of the tools becomes more important than understanding the problem or making actual progress.

Hirano, I believe, has been quoted as saying:

Waste often comes disguised as useful work.

That is what is happening here. The team thinks they are working to solve the problem when, in reality, they are still trying to decide what problem to work on. The gridlock may be driven by fear of working on the wrong problem. But in reality, there is no wrong problem, there is only the one that is in your way.

Here is something else I commonly see. When they discover “problem solving” many organizations want to immediately undertake large projects that involve “stretch goals” and breaking down complex issues. They look at operational metrics that are actually aggregated – total inventory, total lead time, productivity of the entire factory, total defect rates, total lead time through the system. While those metrics are nice to gage progress, they do not give you any actionable information.

Even worse is using averages. Averages aggregate even more, and “bad” tends to be countered by “good” in many average calculations. What is important is to look at each instance vs. an external, discrete, and objective standard or specification. Average defect rates tell you nothing at all about what to work on. But this unit had this defect, or this part dimension was this amount out of specification DOES.

Put another way, there are very few big problems. Big “problems” are the aggregated symptoms of many small problems.

This is good news and bad news.

The good news is that small problems can usually be understood, cleared and sometimes solved fairly quickly. The bad news is that it takes work to do this. The other bad news is that there isn’t any other way that actually works.

Doing a good job working on large complex issues requires engaging across the organization, time, and a high level of skill at understanding the situation, framing the problem, getting to causes, working on solutions, testing understanding, etc. Doing it well requires a mentor who is intimately familiar with the thinking behind problem solving.

This skill can not be gained in a “problem solving” or “A3” class, at least not one that simply walks the team members through the process once or twice. Skill comes from practice, and effective practice comes from starting simple, working in an environment where it is safe to experiment and to be wrong. This means working on shop floor issues that can be isolated from one another, the effect of a test or simulation can be seen immediately. The factory and production organization that Steven Spear describes in his research about Toyota is actually designed deliberately to facilitate this kind of work.

Another common mistake is setting up performance targets too early. If the processes are inherently unstable – if there is no sense of takt time, you are having problems with consistent quality or delivery, the first goal is simply to get to the point where you actually know how things are performing against an indicator of stability. Again, this is usually much simpler than setting a high level target and then trying to break down and stratify all of the issues out there. Set that stability target, study the process, and take on the disruptions as you see them. If there is a debate about which one to start with, then start with the simplest one so you can improve your capabilities.

In the end, it is about taking on problems as they come up, where they come up. That thinking is facilitated by the way you structure the flow, the work, and the organization itself. Get to the shop floor, stand in the chalk circle, and ask “What is stopping this team member from being successful right now.”

Posted on

WSJ: Yes, Everybody Hates Performance Reviews

This article, carried by Yahoo News from the Wall Street Journal succinctly  says something that usually goes unsaid. It goes unsaid for the same reason that “Only Nixon could go to China” – only someone who is heavily invested in the performance review system can dare to criticize it. This, in itself, is an indictment of a process built built around control and fear.

Deming called out the same message decades ago. And even managers who purport to agree immediately start making excuses and justifications for why performance reviews are necessary.

If the question to be answered was “How does this Team Member know he is succeeding each day?” rather than “How do we rank and compare the Team Members against one another?” what would be different about this process?

 

Posted on

I.E. and Kaizen

There is an interesting thread developing on the NWLEAN discussion group. Kris Hallan, a regular reader here, asked a great question about the contributions of the industrial engineering pioneers to what, today, we regard as “lean production.”

This, in turn, sparked some debate about whether Taylor, the Glibreths, and others were actually following lean methods; about whether traditional industrial engineering is bogged down in over analysis, and a host of other issues.

Because not all you are following NWLEAN, I wanted to share my thoughts here as well.

The pioneers all did very good work advancing the field of knowledge.

The Gilbreths, for example, are credited with the realization that “time is the shadow of motion.”

Ohno and Toyoda were both adamant that everything they applied to build cars was simply an extension of what they saw at the Rouge plant.

The neat thing about knowledge and technology is that each generation has an opportunity to build on the last. Sometimes this is incremental, sometimes it is a profound shift. But in either case, it is the previous work that establishes the foundation – either something to extend, or a refutable hypothesis to test and reject.

If I really look at the shift that separates traditional I.E. from the more modern approach, it is in who holds the knowledge of the process AND how to improve it.

Taylor separated thinking about the process from determining the best way to perform it. He (and the Gilbreths) learned to observe with a keen eye, and optimize the motions he saw. Great stuff. Nobody did that before. Everything we do today is built on that foundation.

Today I see two levels of lean practice.

The first, and far more common, is the “outside expert” – the kaizen workshop leader, for example. In this model, this expert comes from outside the actual process. He acknowledges that the people doing the work probably know the best way to do it. But the work of exactly HOW to improve things – the magic of kaizen if you were, belongs to the expert. He is the one who facilitates improvements. While “process improvement” is the domain of the people doing the work, the “process of improvement” is owned by the outside expert.

So the skill of “improvement” is separate from the skill of “doing the work.”

I see this all of the time. Its dark side is manifested in “How do I make them follow standard work?” as if that is even possible through coercion or some punishment/reward system.

This is really an extension of the Taylor model of separating “thinking” and “doing.” In this case, however, it is “thinking about how improvement should be done” and “doing the improvements” vs. the work itself.

But something slightly different is happening in the organizations I see pulling ahead.

In those, the “skill of how to improve” is also manifested in the people doing the work. “Improvement” is part of that work itself, not something separate. There is time and resource specifically allocated to it, just as there is for production. EVERYBODY is focused on not only making improvements, but also improving how they do improvements themselves.

To the outside observer, the difference in the teaching and implementation processes are very subtle. But the difference in the culture and results that emerge can be profound.

The key difference is in letting go, finally, of the Taylor model and working to incorporate the knowledge and skill of process improvement into the entire organization – everybody – rather than keeping it in a small cadre.

I think this is one of the distinctions between a practitioner and a true sensei.

Posted on

Grassroots Innovation: The 3rd Way

Grassroots Innovation: The 3rd Way.

Greg captures a concept in 183 words that entire books have utterly failed to explain.

When we are trying to solve a problem, there are always people involved. And people have positions, feelings, and are always emotionally tied to this-or-that outcome.

It is critically important to find “The 3rd Way” when working on a solution.

There is a great example of what Greg describes as “flight” starting in page 73 of John Shook’s book “Managing to Learn.”

Shook summarizes “The 3rd Way”:

. . . making good decisions required everyone’s complete commitment to dealing with harsh reality.

This produced yet another counter-intuitive aspect of A3 management: respect through conflict.

Organizations that confuse “nice-nice” with teamwork end up paralyzed and frozen in place the moment there is disagreement. No further intellectual growth appears, and they had better hope they are far enough ahead that their competitors won’t catch on.

I have already used more words talking about Greg’s post than he spent making it.

Posted on

A “Problems First” Culture

I will be the first to tell you that this is probably repetition of a fairly narrow theme you have seen here before. But I think of different ways to frame it, or get different thoughts, so I share them.

“Problems first” is one of the mantras used by Phil Jenkinson, the CEO character in The Lean Manager by Michael and Freddy Ballé. Now that I have had a few weeks to let it sink in and synthesize with my mental models, I am seeing a concept that is so fundamental I would think it would be hammered into students in every management and leadership course taught in the world.

Of course, though, it isn’t.

Instead it seems alien in most company cultures.

Yet without a “problems first” culture, the leaders really have no idea – none at all – what they should be focusing their attention on. How could they? They don’t know what their people are struggling with until it is too late. By that point, a small unresolved problem has grown to the point where it cannot possibly be ignored, and now it must be dealt with. Task teams are formed, initiatives are launched. Action item lists are made and presented every week, and after enormous expense and effort, the illusion of control is returned. And so many companies are run just like this.

I am pretty sure that anyone reading this knows exactly what this feels like. Let me call it a “hidden problems” culture for now. Maybe I will think of a better term later.

Enough about what it isn’t.

Ironically, a lot of companies in the pursuit of “being lean” actually go blindly through the motions of “problems first,” but so in a way that raises questions about their understanding of this concept.

Let’s look at a simple action item review at a staff meeting.

Typically it looks like this:

For each action, the responsible person reports on the status, whether or not it is “on time” (usually against an arbitrarily assigned due date), and any “problems.” The manager asks if any help is needed, and perhaps assigns more actions to someone else to assist.

One common management tool for these things is a “Stoplight Chart” where actions are assigned color codes of Green, Yellow, or Red, usually depending on progress against the deadline (how late they are).

Red items get the most attention in the meeting (as they should, more about that in a minute), but that attention is usually in the framework of review and reporting.

At the end of the meeting, the senior leader has a good feel for what is happening (or what is not happening).

Contrast this with a world-class automobile assembly line.

Just like the actions items, every task has a deadline. Only in this case, the timing is much tighter – measured in seconds, not days. The assembler knows that if he gets more than 3-4 seconds behind, for any reason at all, he cannot possibly catch up and complete the work cycle on time. He is going to be late.

He pulls the andon cord, to let the team leader know there is a problem.

Key Point: This is not a report of a problem. This is transfer of the problem. The assembler is responsible for carrying out the work as it is designed. If he can’t, for any reason, then exceptions are transferred to the team leader.

The team leader can deviate from the standard work sequence to complete the job, but not the timing. If he cannot clear the problem by the end of the takt cycle, that section of the line will stop, and the andon will go red.

This is not a report of a problem, this is transfer of the problem. The team leader is responsible for assuring the work can be completed within the takt time. If he can’t, for any reason, then exceptions are transferred to the supervisor.

The supervisor is now responsible for clearing the problem and getting things moving again. If he can’t, then within a few minutes, another section of the line will be stopped and the responsibility for clearing the problem transfers to the next level in the chain.

And so it continues.

Of course this increasing level of responsibility does not mean that the others walk away. They are clearly working very hard to get the problem cleared. But each level of escalation brings more resources to bear on the issue.

Note that I haven’t talked about root cause and problem solving yet. Although the escalation procedures are designed to help gain better understanding of the underlying cause, the first priority is to get the problem cleared so that production can resume without compromising safety or quality in any way.

There may be a temporary countermeasure put into place to do this – some short term action that, while it might introduce some extra resources into the process, allows safe, quality production to proceed long enough to get to the underlying cause. One test of understanding that cause can be to remove this temporary crutch and see what happens.

OK, back to the staff meeting.

What is different about that?

The main thing is that typically the problems are being reported, but not escalated. The responsible person may have to come with an action plan to clear the issue, but it is still Management by PowerPoint, and the senior leader’s role is approval vs. involvement. If the senior leader does become involved, it is often driven by a perception that the responsible person is incapable rather than a process of professional development.

What would this look like if it were managed exactly the same way as the assembly line?

What if that monthly review were treated the same as the fixed stop position?

A couple of ideas come to mind.

“Green” means “on track, as originally scheduled.”

“Yellow” means “behind, but we have a plan to get back to green.”

“Red” means behind, and we don’t know how we are going to recover.”

How would those meanings change the tenor of these meetings?

“Problems first” is more than just a discussion about problems. It is a culture that is focused on finding them, clearing them, and solving them, and doing so with the same priority that comes with production.

Posted on

Are You Ready for the Upturn?

Many pundits out there think the economy has hit bottom. If the last couple of cycles are any indication, when things start picking up again, it is going to happen fast. As people scramble to retain or gain market share they are going to want more and want it now.

And, if the last couple of times are any indication, many businesses are going to be caught totally flat footed and struggling to increase their output. I would also imagine that the “never again” vows that they made as things were going down will, once again, go out the window.

So, short of building up a lot of inventory and/or investing in excess capacity, what can you do to be more prepared?

Continue to work toward the ideal of one-piece-flow.

This does a few things for you. If you do it right, you will progressively collapse the throughput time of your process. This will make you more responsive to changes and make you less vulnerable to forecast errors.

More importantly, though, is the understanding you gain as you do this work. You want to know the cycle time constraint of each and every process in the value chain. With that information, you can predict what will constrain you from reaching any given level of production, and start to work on those constraints. That does not mean you increase production, nor does it mean that you add capital equipment. It means you know exactly what you are capable of doing, and exactly what you must do to get to the next level. In other words, you have a plan that you can put into motion at any time.

Work to standardize and stabilize your processes.

This effort helps make your work more ready for people. Many operations today are running well below their capacity, and they have lost their performance edge. Problems are going unnoticed and unaddressed because they aren’t really affecting production right now. That will change, and change fast, in a ramp-up situation.

Worse, unstable and poorly understood processes translate to long, error-prone learning cycles for new people, or current people in doing different work.

Re-energize your daily kaizen and problem solving and start seeking out the things that are disrupting the work. That investment will not only develop your ability to respond quickly and robustly to growth, it will develop people’s skills as well.

Develop your people and organization.

This will help your people become more ready for the work.

Things may be slow today, but do you know who you would put into your next leadership positions as they open up? Have you developed those potential leaders? Have you thought through how you will organize and support the work as business expands?

The more preparation you can make now, the easier it will be when you get into a fast-moving dynamic growth period. You will already have a baseline plan, so you will only need to assess the situation, modify as appropriate, and carry it out. The more of this planning you can do now, the more thinking you will be able to put into execution.

Even people who are already in leadership positions can probably use skills development. There are a few easy things you can do that will pay great dividends in a fast-flux environment.

Look into the TWI programs. These address crucial skills that line leaders need to succeed. Ideally, people would demonstrate those skills before being put into leadership positions.

The side benefit is that these programs give people skills they can use today to make the workplace safer, more consistent, and more stable. In a growth situation, Job Instruction gives you a standard method to bring new people on board, or to flex people quickly into different work and get them up to speed.

Free up as much capacity as possible.

The bottom line results of kaizen are seen primarily in the form of additional capacity – you are able to produce more with the same resources. You might not need that additional capacity right now, but if you are living within your means today, you can put that additional capacity in your hip pocket. Then, the first round of sales growth can be met without any additional resources. The better you are at kaizen, the longer you can hold your resource levels the same while growing output. The only way to get better is to practice, and just like learning to play the piano, this means practice every day.

Understand your supply base.

How well do you know your suppliers? How quickly can they respond if your needs change dramatically? Do you know which supplier controls how quickly you can increase output? Do you know at what point that bottleneck shifts to a different supplier?

The other thing to consider here is the length of that supply chain. If you are bringing in things from overseas, there is one fundamental that many people try to wish away:

No matter how hard you try, you can’t change what is on the boat.

That might seem obvious in saying it, but it is amazing how many times that four or five week transportation time ends up negating any “cost savings” in lower prices.

I am not saying this is good or bad. I am saying to look beyond invoice and transportation prices and understand your enterprise value chain as a dynamic, moving thing with a response time to change. That response time becomes critical when things are changing. Know what that response time is, and manage to it. If you don’t like the answers, you have to alter the system somehow.

Bottom line: The time to get good is now.

When you are scrambling to meet demand, “there won’t be time” for kaizen, and there will be even less time to learn how to do it. The time to get good at it is now. Your alternative is growing your cost structure at least as fast as sales are growing. Experience has shown that your cost structure likely grows faster than sales, and additional earnings come only with non-linear growth – relying on volume to make up for ever thinner margins. That might look OK in the short-term, but it is a strategy of becoming ever less efficient.

The better prepared you are for the upside, the stronger you will be the the inevitable next cycle.

Posted on

Problems Hidden In The Open

We were down on the shop floor watching an assembly operation. The takt time was on the order of three hours. The assembler was new to the task, and the team leader periodically came by and asked if he was “doing OK.” The reply was always in the affirmative.

As the takt time wound down to under five minutes to completion, this operation was the only one not reporting “Done.”

The count down hit zero, things went red, the main line stopped, and the line stop time started ticking up.

The team leader, other assemblers, the supervisor began pitching in to assist. Between them, the job was completed in about 10 minutes, and the line restarted.

So, again, my favorite question:

What’s the problem?

Lets try breaking it down to four key questions.

  1. “What should be happening?”
  2. “What is actually happening?”

    3. The above two questions define the gap.

  3. “Why does the gap exist?”
  4. “What are we doing about it?”

These questions simply re-frame PDCA, but without so much abstraction.

So, in this situation:

What should be happening?
Two things come to mind immediately.

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

For this to work, though, the team member needs a clear and unambiguous way to answer a key question of his own: Am I on track to finish on time? Ideally the answer to this question is a clear “Yes” or a clear “No,” with no ambiguity or judgment involved. (Like any “Check” it should produce a binary result.)

On an automobile line with a takt time on the order of 55 seconds, the assembler can get a good sense of this. If he loses more than three or four seconds, he isn’t going to make it. But “a good sense” isn’t good enough.

Even in this fast-moving situation, you will see visual indicators that help the team member answer this question. Take a look at this photo.

toyota-assy

See the white hash marks along line at the bottom of the picture? Those mark off the moving line work zone into ten increments of about 5 ½ seconds. The assembler knows where he should be as he performs each task. If he is a hash mark behind, he isn’t going to finish on time. Pull the andon. We can safely say that, in this example, we have accomplished (1) and (2) above.

With longer takt times, it is much tougher for a human to have a good sense of how much time will be required to complete the remaining work. That makes it that much more critical that some kind of intermediate milestones are clearly established and linked to time.

What would be a reasonable increment for these checks? –> How far behind are you willing to let your worker get before someone else finds out? I’d say a good starting point is at the point when he can’t recover the time himself, the problem is no longer his. Following the standard work is the responsibility of the team member. Recovering to takt time is the team leader’s domain. At the very least, he is the one who pitches in and helps, or gets someone else to do so. But he can’t do this if he doesn’t know there is a problem.

So – what should be happening?

The team member must have continuous positive confirmation that he is on track to complete the work on time. With the failure of that positive confirmation, he should pull the andon and get assistance.

The team member must call for assistance (“pull the andon”) if his work falls behind the expected progress for any reason whatsoever.

What is actually happening?

In our example, the team member didn’t get help until it was too late. In fact, he verbally assured the team leader he was “OK” on a couple of occasions. The line stop was irrefutable evidence of a problem. That was a good thing. This company has a takt time, and runs to it. Think of what would have happened if they didn’t. It might take hours, or days, before this problem surfaced. (We are nowhere near the root cause yet. The line stop is just evidence of a problem, not the problem itself.)

Why does the gap exist?

It is a hell of a lot harder to answer this question than the other two. In this case, you are going to have to peel back a lot of layers before you get to the actual, systemic, root cause. But in the immediate sense, with a takt time bordering on three hours, there is really no realistic way a worker can judge if he has fallen too far behind to catch up. The fact that, in this case, the assembler was still learning the job, and that just compounds the situation.

From casual observation – when the team leader visited, he asked if things were OK and accepted the reply – I would start to investigate whether the team leader had a good sense himself of where the work should be at his regular check points… if he has regular check points at all.

But all of this is speculation, because after 10 minutes of watching the initial response to the line stop, our little group had moved on. I am mentioning these things as possibilities because you likely have the same issues in your shop. (And if you don’t have a rigorous sense of takt time, it is equally likely you don’t know about those issues even at the level we saw here. At least THIS company can see the evidence of the problem. That is a credit to their visual controls.)

What are we going to do about it?

Obviously there are a couple of immediate things that can be addressed to at least contain the problem. (That is, convert a hard line stop into multiple andon calls so the actual problems are seen earlier.)

I would want to establish a regular routine for the team leader’s checks. His leader standard work. At regular intervals, he should be checking progress of the work. How often? How far behind do you want the assembly to get before you are certain someone finds out about the problem? In this case, even every 20 minutes is less rigorous than the hash marks on the auto assembly line. But it would be a start.

So we have the team leader coming by every 20 minutes.

But he can’t just ask “How is it going?” We clearly saw that didn’t work. It isn’t that the assembler lied to him, it is that the assembler didn’t know because there was no standard.

What work should be complete 20 minutes into the work cycle? At 40 minutes? At 60? What verifiable facts can the team leader check by observation? There are a lot of ways to do this, most of them very simple and non-intrusive. Think it through.

But wait – now the team leader himself has standard work. What cues him to do it? Is he supposed to notice that 20 minutes has elapsed? In this case, the company already has a pretty sophisticated andon and sound system. It would be a pretty simple matter to put in an audible signal that told the team leader to make his checks. But, again, that is just one solution. I can think of a couple of others. Can you?

What is the team leader checking for? This is a critical question.

Think about it.

What was the original answer to “What should be happening?” (which is “the standard”)

We said:

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

We want the assembler himself to be checking #1.

So why do we have the team leader check?

So he can verify that the assembler is pulling the andon when he should. This is important because it is human nature not to ask for help until it is too late. This isn’t limited to factory floors. How many cardiac patients die because they ignored the warning symptoms for fear that it isn’t serious enough to get help?

It isn’t enough to ask the team member to call for help. You have to expect it, encourage it and require it.

Interestingly enough, as I was writing this post, John Shook posted his story about converting the culture at NUMMI.

A cornerstone of Respect for People is the conviction that all employees have the right to be successful every time they do their job. Part of doing their job is finding problems and making improvements. If we as management want people to be successful, to find problems, and make improvements, we have the obligation to provide the means to do so.

But, some of our GM colleagues questioned the wisdom of trying to install andon at NUMMI. “You intend to give these workers the right to stop the line?” they asked. Toyota’s answer: “No, we intend to give them the obligation to stop whenever they find a problem.” [emphasis added]

What was the problem in our example? We don’t know yet. We certainly can’t start looking for causes.

But the evidence of a problem was that the team member could not complete the work in the time expected. That is, he was not successful doing the job. And the line stopped because the support system failed to pick up the fact that he was falling behind until it was too late to recover.

It really does come down to respect for people.

Posted on

leanblog.org: Measuring for Improvement

Mark Grabon’s latest post hits the key difference between metrics that help improvement, vs. management-by-measurement that destroys trust and possibly drives unethical behavior. He quotes a U.K. hospital administrator as saying:

“We’re trying to shift from collecting data for judgment to data for improvement.”

I agree with Mark’s assessment: “Brilliant.”

Metrics are a “Check” in Plan-Do-Check-Act.

The purpose is not to determine if people are “doing their jobs” but to assess if the plan is working as predicted.

“As predicted” means that not only is there an objective, but there are discrete actions which everyone agrees will cause the objective to be reached.

Note the words “everyone agrees.”

For that to happen, not only are objectives handed down, but the plan to reach them is discussed. The boss is keenly interested in exactly how his people plan to accomplish their objectives, and he has bought in after he is satisfied they have done thorough work. Think about that for a second. The boss now has his own “skin in the game” on not only the objective, but the way to get there.

There isn’t any space, at this point, for judging people based solely on hitting the numbers, because the boss has already agreed that the plan should work. The question now comes down to how well the team did putting together a plan and gaining consensus, and how well they executed. If the numbers aren’t hit, everybody has to reflect on why the plan didn’t work, what they didn’t foresee, and what they need to do better next time.

Management-by-measurement, on the other hand, is an abdication of leadership. It becomes an adversiaral rather than collaborative exercise and becomes a contest of politics and blame-shifting. This is why, I think, Deming finds the merit system and individual performance bonuses so destructive.

Posted on

How The Sensei Teaches

In a previous post, I talked about Steven Spear’s observation about how a sensei saw a process and the problems. Jeffery Liker, Mike Hoseus and David Meier have done a good job capturing how a sensei teaches and summed it up in a diagram in the book Toyota Culture. (for those of you following at home, the diagram is figure 18.9 on page 541).

I want to dissect this model a bit and share some of the thoughts I had.

This is the whole diagram:

How a sensei teaches

This diagram strikes me in a couple of ways.

Let’s zoom in to the left hand side.

sensei-do-loop1

I’m calling the part I’ve highlighted in red the “sensei do-it-loop.” That is, the sensei says “Do this,” the students do it, then the sensei says “Now, do this.” Repeat.

While this first loop is the starting point, all too often, it is also the ending point.

And in this loop, process improvement actually happens, everybody applauds at the Friday report-out. The participants may even prepare a summary of key learning points. And perhaps, as follow up, they will apply the same tools in a similar situation. (As much as I hope for this outcome, though, it doesn’t happen as often as I would like.)

A lot of consulting engagements go on this way for many years. Some go decades. I am sure processes improve, and I am equally sure it is very lucrative for those consultants. But even if they are extraordinarily skilled at seeing improvement opportunities and pointing them out, these consultants are not sensei in the meaning of this diagram. That distinction is made clear in the next section.

This is where the learning happens.

Sensei Learning

I have highlighted the learning loop in red.

The sensei is primarily interested in developing people so that they can see the opportunities and improve the processes themselves. He wants to move them along the continuum from “Do” to “Think” so that they understand, not only this process, but learn how to think about processes in general. When the sensei asks the questions, he is forcing people to articulate their understanding to him. He is really saying “teach me.” In this way he pushes people to deepen their own understanding from “think it through” to “understand it well enough to explain to someone else.”

Think about Taiichi Ohno’s famous “chalk circle.” The “DO THIS” was “stand here and watch the process.” He had seen some problem, and wanted the (hapless) manager to learn to see it as well. Ohno didn’t point it out, he just directed their eyes. His “test” was “What do you see?,” essentially repeated until the student “got it.”

The second leap here is from “Think” to “Self Learning.” At this point, people have learned to ask the questions of themselves, and of each other.  So when he asks his questions, the sensei is not merely interested in the answers as a CHECK of learning, he is also teaching people the questions.

These questions are also a form of “reflection.” They are a CHECK of what was planned vs. what was done; and what was intended vs. what was accomplished. The ACT in this case is to think through the process of improvement itself, not simply what was improved.

Until people learn to do this, “Self Learning” does not occur, and the team is forever dependent on external resources (the sensei, consultants) to push themselves.

But the sensei is not through. Once people have a sense of self-learning, the next level is capability to teach others. “All leaders as teachers.”

Learning to Teaching

Someone, I don’t know who, once said that teaching is the best learning. I can certainly say that my own experiences back this up. My greatest ah-ha moments have come when I was trying to explain a concept, not when it was being explained to me.

I would contend, therefore, that a true sensei is not so much one who has mastered the subject, but rather one who has mastered the role of the eternal student. It is mastery in learning that sets apart the very best in a field.

Thus the sensei‘s work is not done until he has imparted this skill to the organization.

As the leaders challenge their people to thoroughly understand the process, the problems, to explore the solutions, so do the leaders challenge themselves to understand as well.

They test their people’s knowledge by asking questions. They test the process knowledge of their people by expecting their people to teach them, the leaders, about the process. Thus, by making people teach, they drive their people to learn in ways they never would have otherwise. The leader teaches by being the student. The student learns by teaching. And the depth of skill and knowledge in the entire organization grows quickly, and without bound.

So Here Is Your Question:

If your organization is typical of most who are treating “lean” as something to “implement” you have the following:

You have a cadre of technical specialists. Their job, primarily, is to seek out opportunities for kaizen, assemble the team of people, teach them the mechanics, then guide them through making process improvements that hit the targets. This is often done over the course of 5 days, but there are variations on this. The key point is that the staff specialists are delegated the job of evangalizing “lean” and teaching it to the people on the shop floor.

Again, if it is typical, there is some kind of reporting structure up to management. How many kaizens have you run? What results have you delivered? How many people have been trained? Managers show their commitment and support by participating in these events periodically, by attending the report-outs, and by paying attention to these reports and follow-up of action items.

Now take what you have just read, and ask yourselves – “Are we getting beyond the first loop, or are we forever just implementing what is in the books?”

How are you reinforcing the learning?

Who is responsible to learn by teaching?

I’ll share a secret with you about a recent post. When Paul and I took Earl through his own warehouse that Friday night, neither of us had been in there before. While I can’t speak for Paul, everything I knew about warehouse operations and crossdocks, I learned from Earl. I didn’t teach him anything that night. Paul and I did, however, push him to teach us, and in doing so, he learned a great deal.