Values Checklists

I am in the process of going through a lot of old files and filling up recycle bins. Most of this stuff was collected back in first half of the 1990’s when the world wide web was just gaining critical mass, and a half day on Alta Vista, or the brand new search engine, Google, turned up new stuff all of the time. It disappeared just as fast, so the rule was “if you want it, copy it.”

A lot of this material comes from the TQM community. But what struck me enough to sit down for a minute and write about is checklists that include values like “respect for people,” “openness and honesty” and “teamwork.”

This was an era when companies were creating “values statements” and publishing them.

Many of them followed by trying to measure compliance with those values, putting them in performance management reviews, etc.

Of course since the mid 1990’s we know better. . . don’t we?

Values are tricky things. Certainly if a company is sincerely trying to change its culture, the values are going to have to shift. The question I have is not whether this is true, but whether writing them down and trying to enforce them is an effective way to go about it.

Consider how a company with a long, entrenched culture of conflict avoidance is going to transition itself into one which truly respects people?

In a conflict avoidance culture, the people who are truly open and honest tend to ruffle feathers and find themselves in the “out” crowd, isolated in the eddies, and often are never told why.

The people who have flourished in that culture now are saying they want to change it.

Let’s assume that the handful of people at the top – whose behavior has likely been rewarded by promotion throughout their careers and possibly even molded the rest of the organization, can even see that they have not been respectful of people.

If they truly want to change the values of the organization, the only way I can see for this to happen is if they, personally, are totally open and honest that (1) What they have been doing is holding the company back, and is disrespectful of people; (2) They intend to change it starting today; and (3) Ask for help and support from others around them to make a personal change.

If these things don’e happen, then it really doesn’t matter what they put on the wall or say they want everyone else to do.

This is a tough one. It is what Peter Senge calls “personal mastery” and what Jim Collins talks about in “Level 5 Leadership.”

Honestly, I don’t think it is a hard prerequisite for a fair degree of success. I know a few companies who have done pretty will without ever addressing this issue.

But I also know they are hitting the limits of what they can accomplish. As I am someone who sees things in terms of their potential I just wanted to take a couple of minutes and toss this one out there for everyone to think about while we (in the USA at least) stuff ourselves with turkey.

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.

Joe Friel’s Blog: Excellence

Joe Friel’s Blog: Excellence.

I’m a couple of months late picking this up (it was published in September, and reported by Greg Eisenbach with the observation that “nothing is listed about talent.” ). But I think it is relevant here because Joe Freil’s predictors of excellence in an athlete translate directly to business performance. Only the context is different.

Motivation – do you want it? The key words are:

This goes well beyond lip service to goals.

Yet, all too often in business, lip service goals are what we get. But organizations that are truly successful and it it for the long haul are motivated by something intrinsic, something more than the platitudes of “creating shareholder value” or other committee-created “vision statements.”

Discipline – a rare commodity in business. The discipline to understand the long-term vision and work incrementally to get there vs. chasing after the short-term gains is the first thing I think of. Even tougher is to demonstrate discipline when times are good. It is easy to hire like mad and sacrifice sustainable margins for short-term sales. It takes discipline to develop a long-term steady growth plan and stick to it.

Confidence – Although this is speculation on my part, I have developed a sense over the years that what we deem “management resistance to change” is actually a lack of confidence. Leaders, and the organization, are simply not capable of performing any better than they believe they can. When I really listen to the language of resistance, the things I hear most often are how “we are different” (or how the examples of excellence are different) in some way that justifies not doing any better than they are now. I have even seen this internally when one part of the company starts to out-perform the others. Even more incredible is the response to turn against the outlier and tear it down.

Focus – I am going to quote Joe Friel here, because I can’t think of a better way to say it.

This could also be called purpose; the athlete knows where he or she wants to go in the sport. Daily training is a purposeful activity that will lead to excellence. Each workout (and accompanying recovery) is a small building block that eventually results in excellence. But you have to take it one step at a time, which brings us to the last predictor, patience.

There are a number of analogies here. Purpose is the obvious one. “Daily training” to the athlete is the process of building, and sustaining, capability. At the pinnacle of “lean” are companies that look at everything they do as training to do it better the next time. They evaluate how they carry out their activities, and evaluate the results. They focus on excellence and, more importantly, they do it on purpose and with purpose.

When there are changes, there are recovery periods which are required for the organization to adjust. Unlike athletes, however, organizations are not limited by the physiology of the human body for adjustment. They can improve on it since their adjustment is mostly psychological and learning, not recovery of damaged tissue.

PatienceOur kaizen blitz culture has created an expectation of instant results. But the purpose of the kaizen event is practice – it is a workout so that people can get better at making improvements as part of their daily work. Impatience is a symptom of poor focus and lack of discipline.

Though this list is great, I want to add one more thing:

Accountability. This word, unfortunately, has a negative “blame and punishment” connotation today as in “hold them accountable.” But I don’t mean it in that way at all. When I say “accountability” I mean that people take personal, internal ownership of their own results. It is actually impossible to impose accountability on someone else. Rewards and punishments may influence behavior a little bit (though I think they just improve people’s skills at concealing things), but they have nothing at all to do with accountability.

You can see accountability when things have gone to hell in a handcart. One organization blames external forces beyond their control, and expects someone else to rescue them since “it wasn’t their fault.”

The accountable organization says “Obviously we need to improve more” and embraces their results, even if they were they were caused by events outside their control.

The difference is between an organization that chooses to be in control of its destiny vs. one which relies on luck, and entitlement to survive.

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.

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.

“The Origin” by Roger Slater

I remembered reading this years ago, and thought I had lost my copy. In the midst of my current file purge, I came across my photocopy of a photocopy of a photocopy that was passed around Boeing with the hand written notation “Hey team, this is a good read – enjoy!”

Even better, though, is that the article is included in its entirety in Google Book’s preview of the original book “Integrated Process Management: A Quality Model .”

I am not going to discuss the article much because I don’t want to play spoiler to the punch line.

Comments and discussion, however, are encouraged.

So, without further delay: Click here to read “The Origin

Continuous Erosion

“Sustaining the gains” is a frequent topic of discussion in the continuous improvement world. Often the discussion degenerates into a rant about “management commitment.”

But in the real world, people generally don’t sabotage improvements on purpose. (Though I have seen it happen, but only once.) The mechanism is far more subtle.

Before we get into what happens after improvements are made, let’s look at a common improvement process itself.

In many companies, the primary method for making improvements is through special events or projects. These are usually planned, organized and led by a staff specialist.

Although the exact methods and words vary, the general process usually looks something like this:

  • Identify an opportunity, select an area for improvement.
  • Analyze the current state.
  • Select an improvement team.
  • Teach the team members how to apply the improvement tools.
  • Facilitate the development of improvement ideas.
  • Work with the team members to implement them.
  • Wrap up with a report or presentation, including remaining action items for management.

A variation on this is where the team is chartered, and it is up to them to identify an opportunity. This approach was more common in the late 1980’s than it is today.

This process actually works. It is capable of making pretty dramatic changes over a short period of time, often only a few days.

So why do the results erode? Or put another way, what is the problem?

Take a look at the routine decisions that are made during normal work, especially the ones that result in some change to the process. Those decisions must be made, because people have to get something done. The question comes down to whether those decisions result in improving the new process, or eroding it somehow.

Once things are in operation, some kind of unforeseen event always happens. Guaranteed. It can be something that the improvement team didn’t think of. It can be a piece of malfunctioning equipment. Maybe there is a material shortage or a defective part is delivered. The same things happen in administrative processes, only the words are different. Incomplete information arrives.

It could even be a deliberate decision. A production rate change. A software upgrade. Making room for some other activity.

All of these things, no matter how small or inconsequential, force decisions to be made. “How do we deal with this this and get production going again?”

The person making that decision is either:

  1. Fully capable of applying kaizen principles, and applies them in a solution to the problem.
  2. Is not fully fully capable of applying kaizen principles, but knows that, and seeks assistance in finding a solution to the problem.
  3. Is not fully capable, may or may not know this, and does the best he can to get production back on track.

Both (1) and (2) result in making the system better, more robust and more responsive.

(3) usually results in a little bit of erosion. Variation is accommodated, things are made a bit more complex, the layout is now less than optimal, the old process does not work as designed anymore so the team member must improvise a bit. That, in turn, introduces more variation into the process, and usually drives a cascade of these little decisions.

If there is no mechanism for problem escalation (and if there was, we would likely be in (1) or (2) in the first place), then this becomes the new way, and things are steadily creeping closer to where they were before the event happened.

Given enough time (which can be amazingly brief), the process reverts back to where it was, or morphs into something else entirely – but equally wasteful.

Meanwhile the improvement specialists have moved on to the next project. Even if the local leader did ask for assistance, they might not be available, or worse, they tell him to figure it out.

Follow this with an “audit” that dings the local leader for “not supporting the changes” and wonder why he is less than enthusiastic about this kind of help.

Here is the question I want to leave hanging out there:

What was the intent of the kaizen event? (and was that intent accomplished?)

Notes From a Kaizen Event

I was cleaning out some old stuff and came across a folded piece of paper with notes on it. They were from my parting comments to a kaizen event team that had put in a great week with spectacular results. They had started out wanting to improve the delivery of WIP to and from the warehouse.

When we went to the shop floor to see the current situation, what I saw was much more opportunity. It took a little work, especially with the area manager, but by the end of the week they had gone from needing 5 work cells with 6 people each – plus more to meet the holiday seasonal production – to 4 production cells with 5 people each, that could comfortably meet the rush. Not bad for a week’s work.

That’s the background.

When I look at old notes like this, I am always comparing what I knew then with what I know now. Now and than I turn up something that gives a hint that I knew what I was doing.

These comments were as much for the rest of the audience as they were for the team members themselves. After all, they knew what they did, and were fully aware of what they had to do next. But the other teams, and their collective bosses, needed to hear it as well.

  • Wow – great team. You caught flow fever early in the week and ran with it. You make me look like I knew what I was doing – thank you.
  • You connected the operations into a smooth flow.
  • Now you can begin the process of kaizen. Stick with it, stay on the shop floor, and work to stabilize the work. Many problems will come up. Help the work teams learn how to see them and solve them.
  • If you can save, and stabilize, a quarter of a second every day, in three months you can get another 20% of productivity. Think about that – and do the math for yourself.

What made this work?

First and foremost, we had the operational manager there, fully participating. He was skeptical at first, but once I sat down with him and went through his production requirements, step by step, he began to see things in terms of takt times and production leveling rather than just quantities to push out the door. That was a big shift.

The other big thing was having  the team work off line for a few hours to construct a mock-up of a “typical” work cell. Then, without worrying a bit about the takt time, work to minimize the cycle time of one person going through the complete cycle. They learned for themselves that to save time you must study motion. We went through three or four cycles of granularity – every time they thought they had “the” solution, we introduced another tool to see the next level of extra motion. Through this exercise, they gained confidence that it was entirely possible to make a dramatic improvement in the “optimal layout” that they already had.

After that, it was a matter of getting to work. They watched the actual operators, and now could see the excess motions that were being driven by the way the work was arranged. They started making little adjustments – always being respectful of the workers. “We’d like to try something different here, just to see if it works better for you. May we just try something?”

That “May we try this?” attitude introduced something into the dynamic that doesn’t show up often enough – humility. Rather than these managers saying “We’ve got a better way, do it like this.” they were saying “We really don’t know if this will work or not,” and asking not only permission to try, but for input on whether it worked, or how it could work if it wasn’t quite there.

A lot of changes got implemented, but there was no arguing or friction because everything was just an experiment to see if it would work or not.

In the end, I saw something I had never seen before – the manager put in a budget request for a reduction, because he knew he could  get it done with less, or at least figuring out how was within his reach.

That scrap of paper reminded me of a pretty good week.

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.

  4. Why does the gap exist?”
  5. “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.

An Exchange with Michael Ballé

Click image for Amazon.com listing

Background –
In my original comments on The Lean Manager, I compared The Lean Manager‘s story structure to that of Eli Goldratt’s classic The Goal.

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.


Michael:

Mark,

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 :))

Michael

Mark:

Michael –

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.

Mark

Michael:

Good debate.

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.

Michael

Mark:

Michael –

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.

Thoughts?

Mark

Michael:

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!

Best,
Michael


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.