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:

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.