Author: Mark

Posted on

Chasing the Rabbit – Steven Spear

Steven Spear has been on the cutting edge of research about what makes exceptional organizations exceptional for over 10 years. The landmark paper “Decoding the DNA of the Toyota Production System” summarized his PhD research on Toyota. His dissertation is the 5th most popular publication on ProQuest, the online source for academic work.

His recent book, “Chasing the Rabbit” brings his work from academic publications such as “The Harvard Business Review” into the mainstream business press.

One of the differences between Steven Spear and most other experts on the TPS is that Spear is, first and foremost, a student of theory. He does not make casual observation and render an opinion. Rather, he develops a formal theory then seeks to continuously test it against facts.

During his years of research into high-performing organizations, Spear has found consistent examples where – all conditions being equal; where products are a commodity; where the playing field is level – one organization in the field consistently outperforms the others over time. Spear builds on a metaphor of the front-runner in the Boston Marathon seemingly coasting to victory while the pack following him struggles, fights and elbows for the honor of coming in second. He calls these high-performing or high-velocity organizations the “rabbits.”

Spear’s theory of what differentiates the “rabbit” organizations is, ironically, that they consistently apply theory and theory testing into their management systems. I suppose it took someone who was well trained in the “theory of theory” to really see that. He has extended the application into a general set of principles that he has found across all organizations which excel. Further, he has found that mediocre operations which begin to apply the principles can rapidly and dramatically improve their performance.

He makes his case through example after example of organizations outperforming their peers and comps.

I am not going to repeat those stories here – you can click on the link above, buy the book, and read them for yourself. Rather, over a series of posts, I am going to go through some of the points in the book that struck me, share my mental notes, cite examples where I believe his theory holds, and hopefully spark some discussion.

Posted on

Andon Leadership

On a world-class automobile assembly line, the actual work is continuously being compared to the planned work. In each work zone, there is a planned sequence of tasks which are expected to produce a specified output.

If there is any departure at all from the planned sequence, if things get behind the planned timeline, if the necessary conditions are not there, if any process step does not complete as required then either the Team Member or an automated system turns on a help call – an andon.

The response is immediate. The first response is within seconds with a priority of clearing the problem. The line itself is still moving, but if the problem is not cleared before the end of the takt time the line automatically stops – things go from “yellow” to “red.” When that happens, the responsibility for the problem also shifts up a level in the response chain.

The priority is still to clear the problem quickly – and clearing the problem means to restore conditions required for safety and quality without compromise.

Once the problem is cleared, and the line re-started, the rest of the problem solving process engages to find the cause of the problem and address it in the system itself. If the problem is outside of the bounds, or outside of the capability, of the original Team Leader to solve, then his chain-of-support will engage to help him solve it so that his skills can be improved.

In summary – we have a sequence of tasks to be accomplished over about six hours that, in the end, will result in a car. That sequence of tasks is further broken down into sub-intervals where progress against the plan is checked. If problems develop, the system responds, swarms the problem to clear it, understand it, and adjust the process if necessary.

None of the above should be a surprise.

But what happens in your management monthly reviews?

Huh? How are management monthly reviews related to an assembly line?

Let’s see. In a reasonably functional organization the business plan is (or should be!) a series of tasks to be accomplished over a period of time that, in the end, will deliver specified results. That sequence of tasks is further broken down into sub-intervals where progress of the plan is checked.

But in a typical monthly review, the analogy ends there. When problems develop, the reasons are discussed, mentioned, and worked around. In dysfunctional organizations only the objectives are discussed, and in truly dysfunctional organizations the objectives themselves are adjusted to match what is accomplished.

Shift your thinking a bit, and apply the assembly line analogy to its end-state.

The monthly review is the fixed-stop position. Up to this point, the person responsible for the task “owns” it. He should be checking progress and ensuring that things are getting done as specified, and that the results being achieved are as anticipated (predicted). He should be monitoring conditions and making sure that the operating assumptions are holding. Ideally those checks are built-in to the process and planning so that they are at least semi-automatic.

If all is “green” going into the monthly review, then things are great.

But if something is “off” – yellow – that is equivalent to an andon call. The responsible person is that first-responder. He has until the next review to clear the problem. Think about the ramifications here. This means that if the reviews with the boss are every month, the responsible manager better not wait until the week before to find out what is happening so he can report on it. He has to stay in touch with what is happening.

The monthly review is the fixed-stop-position at the review, and the “andon” goes red.

The reviewing manager now “owns” the problem. His job is now to ensure that there are effective countermeasures in place to get things back on track. That does not absolve the responsible manager, but rather, this becomes a “check” and an “act” for his professional development by the more senior leader.

Again, think of the ramifications. The responsible manager must not only be in touch with what is happening, he also needs to make sure his people are being developed and pushed to fully understand the problems as they occur.

The job of these leaders, at each level, is not only to keep intimately in touch with what is going on, but also be fully aware of the skills, gaps and development of their people. If someone should be able to handle an issue, but can’t, that is a skill gap that, like any other gap, must be addressed (in this case by developing the person).

In mediocre organizations, professional development is owned and overseen by H.R. and may be tied to the annual review process. In organizations that “get it” professional development is a natural part of the leadership process, and happens at all levels in the natural course of getting things done.

Posted on

Expectations

This is a bit of a more pragmatic breakdown from the “How Strong Is Your Immune System?” I plan to follow-up with some practical approaches and tools to implement and conduct the kind of problem solving that needs to be done every day.

As we “promote lean,” what expectations to we set?
How well do those promises match up with what is delivered?
If there is a gap, does it dampen the enthusiasm of “management support?”

I think this is important for us to understand.

In the enthusiasm to “make the case” many lean manufacturing proponents point (and rightly so) to the higher performance levels of organizations that have done it. They talk about greatly improved quality, much faster inventory turns, greater returns on capital, much quicker response and throughput. By whatever measure, these systems clearly perform better.

The implementers start teaching the system through its mechanics. Takt time to pace everything; one-piece-flow; pull systems, supermarkets and kanban; quick changeovers; standard work; mistake-proofing.

Now I will be the first to tell you – this is how I was taught – the “just do it, and you will understand” approach. But no matter how well-intended, there is the danger of a diluted message: “Copy the mechanics of how these operations work, and you too can have these results.” Or, put another way, it “Don’t ask questions, just do it” gets (mis)translated into “You don’t have to understand it.”

Wrong. You do.

An expectation is created that, by implementing the basic mechanics of takt, flow and pull, these terrific results can be achieved and sustained.

Here’s the rub. All of the “tools of lean” are designed to force problems to the surface and make them too obvious to ignore. There is an implied expectation that the organization will see these problems and take on the challenge of tackling them as they emerge – true kaizen.

Of course all of this presumes that the organization has the resources, skill and most importantly the stomach to deal with these problems quickly and efficiently.

Bluntly, most don’t. If they did then none of this would have been necessary in the first place.

By implementing the tools alone, they are in effect taking a Newcomen steam engine – primitive, big, inefficient, slow, but functional through brute force- and replacing it with a state of the art steam turbine.

Yes, the turbine is much more efficient, but if you took one and dropped it into the year 1715 it wouldn’t run for very long. They didn’t have the resources or the skill to operate or maintain it.

So, in our lean- implementing factory, the new system is put in and in fairly short order, all of the previously hidden and tolerated problems are now revealed.

And it reveals the problem of “no process to devote the time or to develop the resources and skills to handle those problems” – to detect them, fix them, understand them and solve them.

Lacking the time and skills, the first line leaders do what they must to get the job done… they return to the tried-and-true countermeasures that keep the problems from disrupting things too much:

Kaizen Deterioration Reinforcing Loop

This is the fate of many so-called “kaizen events” which seek to make great change in a hurry.

So why does this happen?

I can speculate that it is a combination of ignorance on the part of some implementers who “got” the “just do it” part but didn’t pick up the “think for yourself” part.

Somewhere, sometime, someone established a precedent that making dramatic but unvalidated changes to a system was “kaizen.” Perhaps, at some point, a sensei said “Don’t ask questions, try this…” with the intention that people would try it and learn what problems came up, only to have it turned into “Do this” without any follow-up or understanding.

Others, perhaps, have an underlying fear that if they revealed just how much work and change was really involved that the leaders would be scared off and not take the first steps.

Now, to be clear, a certain amount of “just try it” is required to anchor that initial leap of faith. But the implementers must be prepared to immediately guide, lead, teach, coach and build the problem solving capability of the organization.

But, in the end, digging further into “Why?” doesn’t give us any more actionable information. “The system is designed to surface problems, and there is no process to handle them” is a root cause that can be directly addressed. It is simply important to acknowledge the truth.

What to do about it. I’ll get into more detail in future posts, but to begin, here are some things to think about:

  1. Small steps. (Note that “small steps” ≠ “slow steps”). Kaizen can be done rapidly, but it must be done deliberately in a context of understanding. Understand why things are the way they are, understand the effect your change should have. Try it out – ideally simulate if first – and see what problems surface. Solve those problems, then implement your change.
  2. Dedicate and manage time for solving problems. This is briefly covered by a couple of previous posts, “Why Doesn’t Daily Kaizen Happen?” and “Systematic Problem Solving” but is worth repeating. Problem solving and kaizen are work, just like anything else. If you want it to happen, you need to allocate time, resources and management to organize it.
  3. Develop a systematic approach, then follow it. I am going to go into some detail on this over the next few posts, but I need to emphasize the last part: then follow it. Too many “standards” are declared, then ignored.
  4. Don’t wait for “the next event” to make improvements.
  5. Just get started. Don’t wait until you are ready, you never will be. The only way to learn is to practice, observe yourself, see what works, what doesn’t, and learn. This, in turn, requires something that is sadly in very short supply in most corporations: humility. Learning means acknowledging, usually in public, that “we don’t have the answers” and perhaps that is the most important lesson.

I could digress into a leadership roles discussion here, but I won’t. But if you want to do a bit of pre-reading for future discussions, find a copy of “Learning to Lead at Toyota” by Steven Spear, and as you read it think about the role of the leader in that story. Bob, the protagonist, starts out with one role, and learns his role is actually quite different. There will be a quiz later.

Posted on

Toyota projects first operating loss since 1941

http://news.yahoo.com/s/ap/20081222/ap_on_bi_ge/as_japan_toyota

At one level, this news drives home the state of the global economy. But let’s parse the story a bit and see if there is contrast about how Toyota handles this vs. how their competitors do.

First, of course, is the “…since 1941” part, compared to the record losses that have been reported by the rest of the sector for many quarters now. This is the first time the leadership has had to report a loss.

Gloom dominated the annual news conference by Toyota’s president, who in recent years had outlined ambitious expansion plans. This year, Toyota President Katsuaki Watanabe even refused to give a worldwide vehicle sales goal for 2009.

“The tough times are hitting us far faster, wider and deeper than expected,” he told reporters at Toyota’s Nagoya office. “This is an unprecedented crisis requiring urgent action.” [emphasis added]

So what will they do about it?

Watanabe vowed Toyota would grow so lean it would realize profitability even if its worldwide sales slid to as low as 7 million vehicles  — what he called the basic “bottom line” for Toyota.

“We must change to become more slim, muscular and flexible,” he said.

While I am certainly not inside anyone’s board room, here is what I am reading between the lines.

In Lansing (GM), the attitude is that external forces are causing an otherwise well managed company to suffer hard times. “We can’t do anything about this, it’s not our fault.”

In Nagoya (Toyota) the attitude is  “If we had managed well enough, this would not have happened. We need to examine ourselves and do something about this so it doesn’t happen again.”

Of course the whole mess is fraught with U.S. politics which will complicate things immensely. But it will still be interesting to watch.

Oh – and, while they are certainly in trouble, I believe our friends in Dearborn (Ford) got off the denial train a while ago. Time will tell if it was soon enough for them.

Posted on

How Strong Is Your Immune System?

Each day you are exposed to an unimaginable number of viruses and bacteria. Any one of them has the potential to overwhelm your body and kill you. But your immune system detects the foreign body, responds, swarms the source of infection, defeats it, and learns so that your immunity is actually strengthened in the process.

Some people, for various reasons, have weak or suppressed immune systems. They suffer from chronic infections. Even if their immune system keeps the infection under control, it is not strong enough to eliminate it. Things which someone else might not even notice take a daily toll on their energy and life.

Your immune system represents your body’s strength to deal with the unanticipated and the unexpected.

In your organization, people encounter unanticipated and unexpected things every day. A small inconsequential defect causes some inconsequential rework. A missing part causes a search and expedite. Each of these things, in turn, propagates more variation, like expanding waves, into the system around it. The variation becomes an infection in your processes, and it has the potential to grow without bounds.

Most organizations have very weak immune systems. They are chronically sick, and expending incredible amounts of time and energy dealing with these “infections.” Because each “infection” is, at best, accommodated rather than eliminated, they tend to accumulate. More and more of the organization’s energy is expended coping.

In the work place this means that the success of the process becomes totally reliant on the vigilance of each individual, working pretty much alone, to see problems and control them enough that some form of output can continue. Worse, many organizations build elaborate systems to assign blame when one of these thousands of opportunities for problems is missed.

Ironically, a lot of “blitz” type kaizen activity actually makes the the system more sensitive to these kinds of problems. If there is no corresponding effort to strengthen the response (swarm, fix, solve) to these problems, it is no wonder that things slide back pretty quickly.

Variation is an infection. And like the viruses and bacteria we are exposed to every day, it will always be there. It is only your ability to quickly detect variation, rapidly contain it, and then deal with its cause that strengthens your organization’s ability to deal with the next one.

Posted on

Article: Teaching Smart People How To Learn

Greg Eisenbach, in his Grassroots Innovation blog, cites a article that gets to the very root of organizational learning, respect for people, and a myriad of other issues.

The article, Teaching Smart people How To Learn was written by Chris Argyris back in 1991. What struck me about it is that it packs a double-whammy to our “lean” community. Most of us are change agents in some form or fashion, whether with direct operational control, or as either internal or external consultants. The hit comes from the fact that the example dysfunctional organization are consultants themselves.

So in that aspect, we all need to read this and take a long, hard look in the mirror.

The other aspect, though, is that everything here extrapolates to the very organizations we are trying to influence. A couple of key points jumped out at me.

Change has to start at the top because otherwise defensive senior managers are likely to disown any transformation in reasoning patterns coming from below. If professionals or middle managers begin to change the way they reason and act, such changes are likely to appear strange—if not actually dangerous—to those at the top. The result is an unstable situation where senior managers still believe that it is a sign of caring and sensitivity to bypass and cover up difficult issues, while their subordinates see the very same actions as defensive.

I can certainly relate the above from personal experience. It is damned difficult to be open and honest in an environment which does not value openness and honesty!

But then the dilemma hits, because there I am “blaming the client” for my own lack of effectiveness. Instead, it is my responsibility to look at what what I actually did, vs. what I wanted to do; look at my actual results vs. my planned results, and apply scientific thinking. To paraphrase back to 1944, “If the student hasn’t learned, the teacher hasn’t taught.”

The good news is that in the article, Chris Argyris not only points out the problem, he gives an example or two of managers leaders who have overcome it. But they did so only through hard introspection and challenging their only assumptions about themselves, their organizations, and their leadership style.

My last challenge here is this: When we talk about “respect for people” are we talking about behavior which avoids the issues so nobody’s feelings are hurt… or are we talking about being truly respectful and getting the truth out into the open so we can all deal with it?

Posted on

A3 by PowerPoint

aarrgh! all of the purists say! Death by PowerPoint. Yup.

But one of today’s realities is that many managers expect to be “briefed” and expect it to be done in a conference room with a projector and… PowerPoint.

Getting them to sit down and go through a single sheet of A3 paper is going to be a stretch at best. So let me propose an interim.

Five slides, six at the most.

No fancy headings, logos, etc. They take up space and distract from the message.

Simple text. No animation. Pictures, graphs to make the points.

The slides are:

Background / Current Condition

Briefly cover where we are, and why we are talking about this right now.

Back up your assertions with data and facts. Note that, in my context, a “fact” is something you can see, observe, sense, touch. The data must be explained by the facts.

Target

What is this going to look like when we are successful?

The target is binary. It is verifiable as “met” or “not met.” It does not include vague words like “improved” or “reduced” which are subject to interpretation.

Analysis

What is keeping us from hitting the target right now? What is in the way? What must be solved, what barrier must be cleared, what factor must be eliminated?

Clearly demonstrate that dealing with these issues will allow reaching the target.

Countermeasures / Implementation

What actions will be taken to deal with the issues or shortcomings?

When will they be taken?

Who will take them?

When will they be checked for successful implementation?

For each one, what is the predicted effect if it works as planned?

How will you check the actual effect?

Do the cumulative predicted effects of your countermeasures add up to enough to close the gap and reach the target?

If not, then what else are you going to do?

Results / Follow-Up

What actually happened?

If When things got off track, what is the recovery / correction plan?

If When actual results were different than planned, what else are you going to do?

Did you reach the target? If not, what else are you going to do?

It’s the thinking, not the format!

Do the headers change sometimes? Sure, but the intent is:

What is happening?

What do you want to happen?

What is the gap?

What will you do to get it there, and how will you check that:

  • You did you you planned.
  • It worked like you expected?

Do it.

Check it.

Fix it.

Learn.

PDCA

This is a leader’s tool

If it is done well, and done correctly, it is done the way John Shook describes it in his new book Managing to Learn. But don’t confuse the size of the paper with the structure of the thinking. Get that right. Worry about the sheet of paper later if you must.

When encountering resistance, a good teacher knows what things can be left for later, and which ones are critical to get right.

Posted on

Not Just Asking Why? – Five Investigations

I hit around this issue in the past, but with the recent publication of John Shook’s new book Managing to Learn, I felt the need to go into it again.

In the text, Shook’s coverage of root cause investigation is very thorough. He tells the story of each “Why?” question triggering another round of investigation.

But in a full page sidebar, he uses the example from Taiichi Ohno’s classic book Toyota Production System: Beyond Large-Scale Production. For those of you following at home, the original example is on page 17 of Ohno’s book, and the reference to it is on page 47 of Managing to Learn.

Quoting from the books:

  1. Why did the machine stop?
    There was an overload and the fuse blew.
  2. Why was there an overload?
    The bearing was not sufficiently lubricated.
  3. Why was it not lubricated sufficiently?
    The lubrication pump was not working sufficiently.
  4. Why was it not pumping sufficiently?
    The shaft of the pump was warn and rattling.
  5. Why was the shaft worn out?
    There was no strainer attached, and metal scrap got in.

The conclusion is that the lack of a strainer is the root cause of the machine stoppage. (“For the want of a nail…“)

This line of thinking is all well and good after the chain is understood. Unfortunately it gives the impression that the root cause of a problem can be reached simply by repeatedly asking “Why?” and writing down the answers. I know this because I have personally experienced well-meaning-but-ignorant consultants who have done exactly that on a flip chart with a team trying to solve a problem.

I have heard “Just ask why five times” as a method, proposed in contrast to more rigorous methods.

It ain’t that simple, folks.

Let’s look at this example.

Why did the machine stop? What I know right now is that the machine isn’t running. Although I can get to the “blown fuse” fairly quickly, let’s not confuse the first or second thing I would check with a process of systematically eliminating other possibilities. The simple fact is that I would check the fuse fairly quickly because I can’t check everything at once, and because I am going to check things more-or-less in order of simplicity. But I am systematically ruling out loss of power at the feed, a physical problem (such as a broken connection), a problem in the control circuitry, and a host of other possible issues. In short, I must investigate a “loss of electrical power” until I reach the conclusion that it is a blown fuse.

Ohno skips a bit by going directly to the cause of the blown fuse as an overload, but it is going to take a little more investigation to get to that conclusion. Coming forward a few decades from when that book was written, I would probably reset the breaker and see if it trips again. But even then, I haven’t ruled out a bad fuse / breaker. Determining, for sure, that it is an overload condition is going to take a little more troubleshooting. A multi-meter would be much more useful than a flip chart at this point.

Once I am pretty certain I am dealing with an overload condition, then I can ask what is causing it.

Why was there an overload? Well lots of things can cause an overload. Something is putting drag on this notional motor. Maybe it was a bearing problem in the motor. Maybe a bearing elsewhere. Maybe a gear has locked up. Is this even an overloaded motor? Or is it an overloaded circuit? Eventually, after systematically checking and testing, I find the bad bearing. Now – Why did the bearing fail? How do I know it is lack of lubrication? Hopefully it is obvious, but there may be some other things I need to look at. Is there a flow of lubricant into the bearing? If that is normal, I need to look elsewhere. But there is not a normal flow of lubricant, so for now I can reasonably assume that lubrication is the problem.

Why was it not lubricated sufficiently? If the lubricant is not reaching the bearing, Why is there insufficient lubricant flow?

Is the sump dry? Is the intake clear? Is the line kinked, clogged or leaking? Is it clear? How do I know? As I work my way upstream, physically checking, I’ll eventually reach the pump that is complaining.

Why was it not pumping sufficiently? At this point, I am probably replacing the pump. But why the pump failed in the first place is a reasonable question to be asking. And only upon physical examination of the old pump am I going to find the worn and rattling shaft. But I am curious, so I look rather than just scrapping the pump and replacing it.

Why was the shaft worn out? Because the scope of investigation is narrowing, things get a little easier. Taking the old pump apart is going to reveal that the shaft is bound up with metal scrap. That takes me through a few more “Why?” questions – how could this get in here? And that is the point where I see no strainer on the intake.

Now, obviously, I made all of this up. But here is my point:

We, the teachers of others, do our students a major disservice when we over-simplify things. “Ask why five times” is very easy for people to take it out of context and try to apply literally. Unless the problem is very simple, it just doesn’t work, and that leaves them:

  • Frustrated.
  • (Correctly) believing that anyone who thinks the real world is this simple has never had to deal with it.

Ohno certainly dealt in the real world. He also uses metaphors. We should caution ourselves not to take everything as 100% literal. Ohno’s point is summed up in the last paragraph of this section of his book on page 18 when he concludes:

In a production plant operation, data are highly regarded — but I consider facts to be even more important. When a problem arises, if our search for the cause is not thorough, the actions taken can be out of focus. That is why we repeatedly ask why. This is the scientific basis of the Toyota system.  [emphasis added]

The scientific method generates understanding through repeated hypothesis testing. A scientist ask “Why?” then fits a possible answer to the facts as he understands them and then asks “What else would be true if I am right?” and builds an experiment (or investigates) to verify, or refute, his thinking. This is how to ask “Why” and this is what you should do five times.

Posted on

Management by Measurement vs. a Problem Solving Culture

As I promised, I want to expand on a couple of great points buried in John Shook’s new book Managing to Learn, published by LEI.

A while back I commented on an article, Lean Dilemma: System Principles vs. Management Accounting Controls, in which H. Thomas Johnson points out that

Perhaps what you measure is what you get.
More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.

In his introduction to the book, Shook describes the contrast:

Where the laissez-faire, hands-off manager will content himself to set targets and delegate everything, essentially saying, “I don’t care how you do it, as long as you get the results,” the Toyota manager desperately wants to know how you’ll do it, saying “I want to hear everything about your thinking, tell me about your plans.”

and a little later:

This is a stark contrast to the results-only oriented management-by-numbers approach.

Shook then also references H. Thomas Johnson’s paper. (like minds?)

But I would like to dive a little deeper into the contrast of leadership cultures here.

Let’s say the “management by measurement” leader thinks there is too much working capital tied up in excess inventory.

His countermeasure would be to set a key performance indicator (KPI) of inventory levels, or inventory turns, and “hold people accountable” for hitting their targets.

Since there is little interest expressed in how this is done, the savvy numbers-focused subordinate understands the accounting system and sees that inventory levels are taken at the end of each financial quarter, and those levels are used to generate the report of inventory turns. This is also the number used to report to the shareholders and the SEC.

His response is to take actions necessary to get inventory as low as possible during the week or on the day when that snapshot is taken. It is then a simple matter to take actions necessary. A couple of classics are:

  • Pull forward orders from next quarter, fill and ship them early.
  • Slow down (or even stop) production in the last week or two of the quarter.
  • Shift inventory from “finished goods” to “in transit” to get it off the books.

While, in my opinion (which is all that is), actions like this are at best deceptive, and (when reported as true financial results) possibly bordering on fraud, the truth is that these kinds of things happen all of the time in reputable companies.

So what is the countermeasure?

In a “management by measurement” culture, the leader (if he cares in the first place), would respond to put in additional measurements and rules that, hopefully, constrain the behavior he does not want. He would start measuring inventory levels more often, or take an average. He would measure scheduled vs. actual ship dates. He would measure “linearity” of production.

Fundamentally, he would operate on the belief that, if only he could measure the right things, that he would get the performance he needs, in the way it should be done. “The right measurements produce the right results.”

While not universal, it is also very common for a work environment such as this one to:

  • Attach substantial performance bonuses to “hitting the numbers.”
  • Confuse this with “empowerment” – and perceive a subordinate who truly wants help to develop a good, sound plan as less capable than one who “just gets it done.” He is seen as “high maintenance.” (“Don’t come to me with problems unless you have a solution.”)
  • Look for external factors that excuse not hitting the targets. (Such as an increase in commodity prices.)
  • Take credit for hitting the targets, even when it was caused by external factors. (Such as a drop in commodity prices.)

Overall, there is no real interest in the assessment of why there even is a gap between the current value and the target (why do we need this inventory in the first place?); and there is even less interest in a plan to close the gap, or in understanding if success (or failure) was due to successful execution or just plain luck.

The higher-level leader says he “trusts his people” and as such, is disengaged, uninformed, and worse, is taking no action to develop their capabilities. He has no way to distinguish between the people who “hit the numbers” due to luck and circumstances (or are very skilled at finding external factors to blame) and the ones who apply good thinking, and carry out good plans. Because the negative effects often take time to manifest, this process can actually bias toward someone who can get good short-term results, even at the cost of long-term shareholder value.

This is no way to run a business. A lot of businesses, some of them very reputable, are run exactly this way.

So What’s The Alternative?

Shook describes a patient-yet-relentless leader who is determined to get the results he wants by developing his subordinate. He assigns a challenging task, specifies the approach (the “A3 Problem Solving Process”) then iterates through the learning process – while applying the principle of small steps. At no point does he allow the next step to proceed until the current one is done correctly.

“Do not accept, create, or pass on poor quality.”

He has a standard, and teaches to that standard.

He is skeptical and intently curious – he must be convinced that the current situation is understood.

He must be convinced that the root cause is understood.

He must be convinced that all alternative countermeasures were explored.

He must be convinced that everyone involved has been consulted.

He must be convinced that all necessary countermeasures are deployed – even ones that are unpopular.

He must be convinced that the plan is being tracked during execution, results are checked against expectations, and additional countermeasures are applied to handle any gaps.

And he must be convinced that the results came as an outcome of specific actions taken, not just luck.

In short, even though he might have been able to do it quicker by just telling his subordinate what to do, in the end, that Team Member would only know his boss’s opinion on a particular solution for a specific issue… he would not have taught how to be thorough.

The Learning Countermeasure

If we start in the same place – too much inventory, too few turns – the engaged leader starts the same way, by setting a target.

Then he asks each of his subordinates to come back to him with their plan.

By definition that plan includes details of their understanding of the situation – where the inventory is, why it is. It includes targets – where the effort will be focused, and what results are expected.

The plan includes detailed understanding of the problems (causes) which must be addressed so that the system can operate in a sustainable, stable way, at the reduced inventory levels.

It includes the actions which will be taken – who will do what by when, and the results expected from those actions. It may include other actions considered, but not taken, and why.

It includes a process to track actions, verify results, and apply additional countermeasures when there is a barrier to execution or a gap in the outcome.

The process of making the plan would largely follow the outline in Managing to Learn. The engaged leader is going to challenge the thinking at each step of the process. He is going to push until he is convinced that the Team Member has thoroughly understood – and verified – the current situation, and that the actions will close the gap to the targets.

Rather than assigning a blanket reduction target, the engaged leader might start there, but would allow the Team Members to play off each other in a form of “cap and trade.” The leader’s target needs to get hit, but different sectors may have different challenges. Blanket goals rarely are appropriate as anything but a starting point. But it is only after everyone understands their situation, and works as a team, that they could come up with a system solution that would work.

Of course then the Team Members who had to take on less ambitious targets would get that much more attention and challenge – thus pushing the team to ever higher performance.

Today’s World

Even in companies deploying “lean”, the quality of the deployment is dependent on the person in charge of that piece of the operation. When someone else rotates in, the new leader imposes his vision of how things should be done, and everything changes.

There are, in my view, two nearly universal points of failure here.

  • The company leadership had an expectation to “get lean” but, above that local level, really had no idea what it means… except in terms of performance metrics. This is often wrapped in a facade of “management support.” Thus, there is no expectation that an incoming leader do things in any particular way. (What is your process to “on board” a new leader prior to just turning him loose with your profits and losses?)
  • The outgoing leader may have done the right things in the wrong way – by directing what was to be done vs. guiding people through the process of true understanding.

Fixing this requires the same thinking and the same process as addressing any other problem. Just trying to impose a standard on things like production boards isn’t going to work. The issue is in the thinking, not in the tools.

Conclusion

You get what you measure, but don’t be surprised if people are ingenious in destructive ways in how they get there.

You can’t force a solution by adding even more metrics.

Only by knowing what you did (the process) will you know why you got the results you achieved (or did not achieve). This is a process of prediction, and is the only way people learn.

Learning takes practice. Practice requires humility and a mentor or teacher who can see and correct.

Posted on

The Messy World of Dealing With People

Jim’s recent comment about his job having a heavy dose of psychology certainly rang true with me. Even Deming acknowledged this in his discussions on “Profound Knowledge” (which is at the core of the TPS even though we use different words).

This article The most common pitfalls that new tech managers face is about leadership in the I.T. world, but the issues are actually common to leadership in any technical function – including those of us who started out as kaizen event leaders or trainers. The skill set is different, and is rarely considered (and almost never developed) prior to promoting someone. So – if you are in this situation, read the article then look in the mirror.

This article Why Do Rational People Make Irrational Decisions ties in with my previous post about Blame vs Accountability. It might help answer the question we all ask sometimes: “What were they thinking?”