I am cleaning out some old notepads. One page has the notes I took during a 4pm production status meeting during my first “get to know you” visit to this company.
In a box on my notes page it says:
“More information is not going to help until you begin to define how you expect things to run.”
What I had observed is their focus on the previous 24 hours metrics, with lots of speculation about “what happened” to account for the lost production. They were focused on incidents and, honestly, assigning those incidents as causes. Where they came up short, they were seeking more information about lost production incidents.
But everything I have written is just to give you a little context for the scribbled box on my notes a few years ago.
Today? They fixed it. This was one of the most dramatic culture shifts – from “find who to blame” to “let’s solve the problem” I have ever witnessed.
What are your daily meetings like? Are they focused on the stuff that went wrong yesterday? Or are they focused on where you are trying to go in the near future?
Many organizations trying to deploy lean get great results for the first couple of years, then things tend to stall or plateau. This is in spite of continued effort from the “lean team.”
We Still Don’t Have a Lean Culture
This was the comment by the Continuous Improvement director of a pretty large corporation. They had been running improvement events for several years, everyone had pretty much been through one.
Each of the events had made pretty good strides during the week, but the behavior wasn’t changing. Things were eroding behind the events, even though everyone agreed things were better.
It was getting harder and harder to make more progress. They had hit the plateau.
What Causes the Lean Plateau?
While it might not be universal, what I have seen happen is this:
The implementation is led by a small group of dedicated technical experts. They are the ones who are looking for opportunities, organizing the kaizen event teams, leading workshops, and overseeing the implementation of lean techniques.
While this works in the short term, often the last implemented results begin to erode as soon as the lean experts shift their attention elsewhere.
At first, this isn’t noticed because the implementation is proceeding faster than the erosion.
However the more areas that are implemented, the faster the erosion becomes. There is simply more “surface area” of implemented areas.
At some point, the rate of erosion = the rate of implementation, and the lean team’s efforts start to shift from implementing new areas to going back and re-implementing areas that have eroded.
The lean team’s capacity becomes consumed re-implementing, and they spend less and less time going over new ground. They are spending all of their time “spinning the plates” and no time starting new ones.
Key Point: The lean plateau occurs when the level of implementation effort and the rate of erosion reach an equilibrium.
In the worst scenario, sooner or later financial pressures come into play. Management begins to question the expense of maintaining an improvement office if things aren’t getting significantly better on the bottom line. What they don’t see is that the office is keeping things from getting worse, but they aren’t called the “maintain what we have office” for a reason.
Breaking the Lean Plateau
When I was a lean director in a large company, we were confronting this very question. We had a meeting to talk about it, and quickly started blaming “lack of management commitment.”
Leaders Weren’t Stepping Up
In any given area, after education and planning, our last step was always to have a major effort to put flow production into place. Since the performance of the area would be substantially better, we expected the leaders to work hard to continue that performance.
What actually happened in an area was “implemented,” was the line leaders in that area – supervisors, managers, senior managers – weren’t working to look for erosion and correct it.
Instead, when a problem was encountered, they were making some kind of accommodation that compromised flow. The effect of the problem went away, but things had eroded a bit.
What we thought we learned: The weren’t “supporting the changes.”
What we really learned – though it was only realized in hindsight: This is the mechanism of “erosion.”
Flow production is specifically designed to surface small problems quickly. If there is no mechanism to detect those problems, respond, correct, and learn, then the only thing leaders can do is add a little inventory, add a little time, add an extra operation.
As Hirano put it so well decades ago:
All waste is cleverly disguised as useful work.
But Our Current Condition was Incomplete
There were outliers where it was working.
As we talked, we realized that each of us had experience with an outlier – one or two areas that were actually improving pretty steadily. Trying to understand what was different about these bright spots, we looked for what they all had in common. Surprisingly:
They were areas with no dedicated improvement teams.
They ran few, if any, 5-day kaizen events.
They were geographically close to one of us (senior “Directors”).
One of us had decent rapport with the area management team.
We each had an informal routine with them: We would drop by when we had time, and walk the work area with the area leader. We could discuss the challenges they were facing, how things were operating, go together to the operations concerned, and look at what was happening. We could ask questions designed to “sharpen the vision” of the leader. Sometimes they were leading questions. Most of the time they were from genuine curiosity.
By the time we left, there was generally some action or short term goal that the leader had set for himself.
Even though we “lean directors” had never worked together before, our stories were surprisingly consistent.
The Current Condition (Everywhere Else)
aka Dave’s Insight
The next logical question was “If that is what we do, what happens everywhere else? What do the lean staff people do?”
Now we were trying to understand the normal pattern of work, not simply the outcome of “the area erodes because the leaders don’t support the changes.”
Dave confidently stood up and grabbed the marker. He started outlining how he trained and certified his kaizen leaders. He worked through the list of skills he worked to develop:
Proficiently deliver the various topical training modules – Waste vs. Value Add; Standard Work; Jidoka; Kanban and Pull;
“Scan” an area to find improvement opportunities.
Establish the lean tools to be deployed.
Organize the workshop team.
Facilitate the “Vision”
Manage the “Kaizen Newspaper” items
and at some point through this detailed explanation he stopped in mid sentence and said something that brought all of us to reality (Please avert your eyes if you are offended by a language you won’t hear on network TV):
What we realized more or less simultaneously was this:
Management wasn’t engaged because our process wasn’t engaging them.
Instead, our experts were essentially pushing them aside and “fixing” things, then turning the newly “leaned” area over to the supervisors and first line managers who, at most, might have participated in the workshop and helped move things around.
Those critical front line leaders were, at best left with a to-do list of ideas (kaizen newspaper items) that hadn’t been implemented during the 5 days.
There was nothing in the structure to challenge them to meet a serious business objective beyond “Look at how much better everything runs now.” The amount of improvement was an after-the-fact measurement (or estimate) rather than a before-we-begin imperative.
So it really should be no surprise that come Monday morning, when the inevitable forces of entropy showed up, that things started to erode. The whole system couldn’t have been better designed for that outcome.
Why the Difference in Approach?
In retrospect, I don’t know. Each of us senior “lean directors” had been taught, or heavily influenced by, Toyota-experienced Japanese mentors, teachers, consultants.
On the other hand, what we were teaching our own people was modeled more on what western consultants were doing. Perhaps it is because it is easier to use forms and PowerPoint for structure than to teach the skills of the conversations we were having.
Implement by Experts or Coached by Leaders
That really is your choice. The expert implementation seems a lot easier.
Unfortunately the “rapid improvement event” (or whatever you call them) system has a really poor record of sustaining.
Perhaps our little group figured out why.
There are no guarantees. No approach will work every time. But a difficult approach that works some of the time is probably better than an easy path that almost never works.
Credit: A lot of stuff comes across my screen, sometimes more than once. I have seen this illustration several times, but don’t remember where it originally came from. If you created it, PLEASE comment so I can give appropriate credit.
Improvement is messy. Science is messy. Research and Development is messy. These are all cases where we want an outcome, are pretty sure what that outcome looks like, but there isn’t really a clear path to get there.
This illustration has illustrates two very different mindsets.
On the left is how many people believe the improvement / organizational development / learning process works. We set out a phased project plan to transform the organization. We carry out a set of pre-defined steps, and when they are completed, we are at the goal.
Sadly our education process is largely constructed on this model. Take the classes, pass the tests, the student is educated.
This thinking is appropriate when the outcome is something we have done before, like constructing a house. Even if this house is a bit different, the builders have rich experience in carrying out all of the constituent process steps. Further upstream, the designer carefully followed building and construction codes. In those cases, we are applying a rich body of experience (or the documented experiences of others) to reach the end goal.
These tasks can be scheduled and sequenced in a project plan. The steps are known, the result is known.
On the right is the hairball of learning and discovery.
We know where we are starting.
We know where we want to end up.
We are reasonably certain we can get from Point A to Point B. But we don’t know precisely which detailed steps or experiments will give us the results we need.
We don’t know for sure that the next result will be a forgone conclusion from the next action step.
Each step gives us more information about the next step.
In the world of continuous improvement, we live in an interesting paradox.
We often believe we are operating in the set-piece model on the left. We see a situation, we apply tools to duplicate a solution we have seen work in a similar situation before.
An interesting thing happens at this point. The Real World intervenes, and we discover that the situation was actually more like the right side. We thought we knew the right answers. We might have even been mostly right. But at the detail level, things don’t work quite as we predicted.
Now… if the system has been deliberately set up to flag those anomalies, and we are recording them and being curious to discover what we didn’t understand then we are in learning mode.
But all too often the experts who guided the original installation have moved on, leaving the people executing the process behind. The assumption was “It works, we can go to the next problem.”
The people in the process did what they were told, or guided, to do. We might have even asked for their input on the details. But that process rarely leaves them with additional skills they need to deal with anomalies in ways that make the process more robust.
So they do what they must to get things done. Mostly that means adding some inventory here, some additional checks or process steps there. Over time, the process erodes back to something close to its original state.
Why? Because we thought we knew everything… but were wrong. And didn’t notice.
This model applies to any effort to shift how an organization performs and interacts. We outrun our headlights and take on the Big Change because that company “over there” does it, and we just copy the end result.
In the past couple of decades, we went through an “empower your people” fad. We saw work teams in world class companies that were largely self directing, surprisingly well aligned with the overall goals of the organization, and getting things done.
“Well,” we thought, “since empowered teams are obviously more effective, we’ll empower our teams.”
They brandished their wand uttered some wizard’s chant, and bing! empowered their teams.
“What did you expect to happen?”
“We expected our newly empowered teams to self-organize, get the work done, plan all of their own vacations and breaks, and continuously improve their operations on their own.”
“What actually happened?”
“Work ground to a halt, people argued and squabbled, quality went to hell, and labor hours went up 20%”
“What did you learn?”
“That empowerment doesn’t work.”
Which is obviously not true, because there are plenty of examples where it does. Perhaps “Empowerment doesn’t work the way we went about it” might be a better answer. That at least opens the door to a bit more curiosity.
The last place I would expect an experiment in true empowerment would be onboard a U.S. Navy nuclear submarine.
Take a look at this video that Mike Rother sent around a couple of days ago, then come back.
A U.S. Navy submarine skipper isn’t generally inclined to swear off ever giving another order. It runs against everything he has been taught and trained to do since he was a Midshipman.
I’d like to cue in on a couple of things here and dissect what happened.
First is the general conditions. I think he could do this just a bit faster than normal because everyone involved was sealed inside a steel can for six months. Just a thought – groups in those conditions tend to have a lot of team cohesion.
But the mechanics are also critical. He didn’t just say “You are empowered.” Rather, this was a process of deliberate learning and practice.
What is key, and what most companies miss, are the crucial elements that Capt. Marquet points out must be built as the pillars of an empowered team.
Let’s put this in Lean Thinker’s terms.
As the Toyota Kata wave begins to sweep over everyone, there is a rush to transition managers into coaches.
“What obstacles do you think are now in the way of reaching the target?”
See the illustration above.
Competence and clarity.
I am going to start with the second one.
Or… where the hell are we trying to go?
Capt. Marquet points out the critical element of commander’s intent. I learned this during my decade or so as a military officer (U.S. Army). When preparing operations orders, I had to clarify the overall commander’s intent. Why? So that when everything went to hell in a handcart, everyone knew what we were trying to get done even if the how to do itentirely broke down.
What that means in the lean thinking world is “What is the business imperative” or “What is the challenge we are trying to achieve?” If nobody knows “why,” then all they can know is “what” and that comes down to “implement the tools,” which, in turn, comes down to “because I said so” or “Because we need a 3 on the lean audit.”
Doesn’t work. Never has.
But I’m beating that topic to death right now, so I want to move the pillar on the left.
In my book, that means “The leader has a good idea how to do it.”
What does that mean in practical terms? In Capt. Marquet’s world, it means that, fundamentally, the crew knows how to operate a nuclear submarine. Additionally, it means they understand the ramifications of the actions they are taking on the overall system, and therefore, the contribution they are making to achieving the intent.
It doesn’t matter how clearly anyone understands what they are trying to get done if they have no idea how to do it.
In Lean Thinking world, competence means a few things.
The leader knows how to “do the math.” She understands the overall flow, the impact of her decisions on the system and the overall system.
The leader / coach has a good understanding of at least the fundamentals of flow production, and why we are striving to move in that direction.
While these things can be taught through skillful coaching, that implies that the coach has enough competence to do that teaching.
But if the coach doesn’t fundamentally grasp the True North, or doesn’t consistently bias every single conversation and decision in that direction, then Clarity is lost, and Competence is never built.
We end up with pokes and tweaks on the current condition, but no real breakthrough progress.
Day to day, this means you are on the shop floor interacting with supervisors and front line managers. You are asking the questions, and guiding their thinking until they grok that one-by-one flow @ takt is where they are striving to go.
In my Lean Director role in a previous company, I recall three distinct stages I went through with people calling me for “what to do” advice.
First, I gave them answers and explanations.
Then I transitioned to first asking them what they thought I would give as an answer.
Then they transitioned to “This is the situation, this is the target, this is what we propose, this is why we think it will work, what do you think?”
“Captain, I propose we submerge the boat.”
“What do you think I am thinking?”
“Um… you would want to know if it is safe?”
“How would you know it is safe?”
In other words…
What are you trying to achieve here? How will you know?
So here is a challenge.
If you are a line leader, especially a plant manager, take one week and utterly refuse to issue direction to anyone. Ask questions. Force them to learn the answers. Test their knowledge. Have them teach you so they must learn.
You will learn a lot about the competence of your team. You will learn a lot about your own clarity of intent. Try it on. No matter what, you will learn a lot.
The tenor of what “lean” is about is shifting, at least in some places, toward the line leader as improver, teacher and coach. Successfully adopting that role requires a qualification that I wish I saw more of as I work with industrial clients – curiosity.
To succeed in this role, a supervisor must be intently curious about, not only the minute-by-minute performance, but what things are affecting it, or could affect it.
Even if he is just walking by, his eyes must be checking – is there excess inventory piling up? Are all of the standard WIP spots filled? Is anyone struggling with the job? Are the carts in the right places? Pressures and temperatures OK? Kanbans circulating correctly? Workers all wearing PPE? Safety glasses? Ear plugs? Does the fork truck driver have his seatbelt fastened?
Though there should also be deliberate checks as part of his standard work, a leader needs to be intently curious about what is happening all of the time.
To improve things requires even more curiosity. “What obstacles do you think are now keeping you from reaching the target?” is not a question that should be answered casually. Rather, the preparation to answer it properly requires careful study – being curious – about what operational conditions must be changed to reach the target.
Sadly, though, my experience is that true curiosity is a pretty rare commodity. A plant manager that can spout off a barrage of facts and figures about how things have to be, but is surprised every time the math doesn’t reflect his view of reality doesn’t impress me much.
Niwa-sensai said once (probably many times) “A visual control that doesn’t trigger action is just a decoration.”
You have to be curious about what those visual controls are telling you. What good is a gage if it is supposed to read between 4 and 6, but drops to 0 and nobody notices?
That supervisor walking through the area needs to be visually sweeping those gages, looking for leaks, anything unusual or abnormal, and taking action.
“How did that stain get here?” Run the trap line. The process, as designed, shouldn’t let anything leak. Why did it? What is really happening?
All we practitioners can do is patiently, again and again, walk the line with them, ask what they see, stand in the chalk circle with them, and do our best to teach them to see what we do.
Show them the system, show them the future consequences of letting this little thing slide – how second shift is going to be brought to their knees because the work isn’t being processed according to the FIFO rules.
I suspect, though, that at least a few leaders get promoted and somehow believe they reach a level where they are exempt from checking and teaching. That’s someone else’s job.
But if not them, who? And how do they know it is getting done?
Imagine you are driving an automobile with a high-performance suspension. You are on a perfectly straight stretch of road, with smooth pavement. Get yourself up to, say, 65 miles per hour (100 km/h). Got it pointed down the middle of the road?
OK, close your eyes, let go of the steering wheel and wait. (Actually closing your eyes is optional.)
Can you predict what will happen, more likely sooner than later?
It doesn’t matter how “stable” your car is.
There are small, random things that are eventually going to cause your car to drift away from the centerline and off the road, into the ditch on one side, or over the cliff on the other. (Didn’t I mention those?)
I often see people set up a well performing process and treat it the same way – as though it will continue to work the same way forever, without any intervention.
But your process is going to encounter random chatter, and when it does, what typically happens?
In most cases, the team members can find a way to work around the issue, and likely continue to get things done, though they will have added a bit of friction, requiring a bit more effort, to do so. They will add a redundant check to make sure no mistake got made. They will add some inventory under the work bench, in case something runs out. They will carry the product over to the other machine because the one they are supposed to use isn’t working as it should be.
They will clean up the spilled coolant, catch the leaking oil.
They’ll tap out paint clogged or unthreaded holes, cut wires that are delivered too long to length, even drill new holes to mount the part that doesn’t fit.
In the office, they get one more signature, send an email to back-up the “unreliable” ERP messages, and make screen prints so they can enter the data into another system.
“Waste is often disguised as useful work.”
All of this easily goes unnoticed, and eventually (maybe) the process becomes cumbersome enough that someone decides to address it with an improvement activity. And the cycle starts again.
How do we stop the cycle?
The point of intervention is in the last paragraph… “All of this goes unnoticed.”
It isn’t a matter of standing and watching for problems. Sakichi Toyoda figured that out almost 100 years ago. It is about designing your process to detect anomalies in either execution (how it is done, how long it takes) or results immediately, signal, and trigger some kind of response.
Here are some fundamental questions to ask yourself:
Before the process even begins, does the team member have everything he needs to succeed? How does he know? I’m talking about parts, information, tools, air pressure, assistance… whatever you know is needed to get the job done.
If the team member doesn’t have everything needed exactly what do you want him to do?
Is the team member carrying out the process in a way that gets the desired result? How does she know? Is there a sequence of steps that you know will give her the result you want? What alerts her if one of them is skipped?
If the team member, for whatever reason, isn’t able to carry out those steps in sequence, exactly what do you want her to do? Go find a grease bucket? Or let you know?
How long do you want to allow your team member to try to fix something or make it work before letting you know there is a problem? Related to this – how far behind can you allow him to get before he can’t catch up, even with help?
Once the team member has completed the process, how does he know the result is what was expected? If the team member doesn’t have a way to positively verify a good outcome, who does detect the problem, when, where and how? It might be your customer!
An Active Control System
Even if you have all of those checks in place, however, you still need to answer a few more questions starting with “Once the team member detects a problem, what do you what exactly do you want them to do?”
I alluded a little to this above, but let’s go a bit deeper.
On a production line, a typical way for a team member to signal a problem is with some kind of andon. This might, for example, take the form of a rope along the line that the team member can pull in order to trigger a signal of some kind.
But that is the easy part. Lots of factories have copied the mechanics of Toyota’s andon only to see them fall into disuse following a period of cynicism.
The hard part is what is supposed to happen next?
Now we are back to the original questions because the andon is nothing more than a trigger for another process.
Who is the designated first responder? (Remember, if it is everybody’s problem, it is nobody’s problem.) Does that person know who he is?
What is the standard for the response? What is the first responder supposed to do, and how long does she have to do it?
When we had takt times on the order of dozens of minutes, our standard for the first response making face-to-face contact with the team member who signaled was 30 seconds.
How much intervention can the first responder make before being required to escalate the problem to the next level?
As a minimum
As a minimum, the first responder’s primary goal is to restore the normal pattern of work. This might be as simple as pitching in and helping because something minor tripped up the team member’s timing.
This is active control – a system or process that detects something going outside the established parameters, and applying an adjustment to get it back. Active control requires a process to detect abnormalities, a trigger, and a response that restores things. It is no different than maintaining thickness in a rolling operation – the machine measures the output, and adjusts the pressure accordingly – or an autopilot that keeps an airplane on course.
Without some kind of active control system, your process will erode over time as the team members do the only things they can do in an effort to keep things moving: They can overproduce and build inventory to compensate, they can add extra process steps, they can add just about any of the things we call “waste.”
The main purpose of an andon is to signal that some part of the system is no longer in normal operating mode. The immediate response should be to quickly assess the situation, and recover the process to the normal mode.
Many organizations, however, do not make that mental shift. They don’t have a clear sense of whether they are in the normal operating pattern, or in recovery mode.
Without that sense of mode, “recovery” can quickly become the norm, and a culture of working around problems develops. Sometimes we call this a “firefighting culture,” but I find that term regrettable, as it reflects poorly on actual firefighters.
In the andon driven environment, the andon is either on or off. That is, things are either operating as they should be (no andon) or they are not (andon is triggered).
All of this presumes, of course, that you have some idea what your normal operating pattern should be. Go and walk your shop floor or work area. What can you see happening?
Is what you see what you want to be happening? How do you know? What do you compare it against?
Can the people working there tell if they, and their process, are in the normal operating pattern, or in some other mode?
If they are recovering, do they know they are recovering? Are they striving to get things back to the normal operating mode; or are they striving to simply get the job done in spite of the immediate problem? Big, big difference here. This is what makes or breaks your continuous improvement effort.
Once the normal operating mode is restored (assuming you had one), are at least some of these incidents investigated down to root cause, with countermeasures tested by appropriate PDCA cycles and experiments?
The piece follows a machinist through his shift in their maintenance facility.
What is interesting is what he has to do to get the job done.
I’m not going to detail it all out here, but suffice it to say that his shift starts at 2:30 pm, and between then and 7:00 pm he only spends about an hour and 10 minutes to pull the old bearings and install the new ones – actually doing the job he set out to get done on the airplane.
The rest of the time is spent interacting with the job tracking computer, gathering the required tools, supplies, waiting for the inspector, and making a part because the one in the kit didn’t fit.
This team member is working within the system, and what is described here is so routine that it is a featured article in the inflight magazine.
Now – before you get really critical, you might want to follow one of your primary team members around for a shift and see if your organization does any better.
For example a ward nurse in a local hospital spent exactly 10 minutes over a 4 hour period actually providing care to patients and charting – the things I would call “nursing.”
These are dedicated team members, but the system gets in their way.
This is a 5 minute edit of the presentation Mike Rother made at the UK Lean summit.
It is a succinct summary of interaction between a coach (leader) and learner (someone working on improving a process).
My thoughts are below the video…
OK – here are some things I have learned with these methods “in the wild.”
Most organizations I have been working with can’t take on 1-3 year challenges and stay the course for that duration. The horizons are too far for them to see what is possible within that kind of time frame and stay the course.
I have been trying 3-4 month time horizons for initial challenges in organizations where everyone is learning the basics at all levels. That gives them an opportunity to practice with a horizon that is less likely to be derailed by a sudden change in direction during that time. Eventually, as they develop capability, they can extend the time horizon and morph these practice challenges into something more formal, linked to the business plan.
Middle managers like to leap onto the coaching questions much too early – before they are capable of actually coaching. The coaching questions are seductive because they are written down and structured.
The PDCA process is much more nuanced, but it must be mastered before attempting to coach. Why? Because the coaching process is application of PDCA toward the learner’s development.
While it is OK to round-robin coaching and actual process improvement, everyone has to work together to reflect and learn.
In addition, those middle managers tend to try to leap into coaching before they have an internally set non-negotiable sense of “True North” – driving toward better and better flow.
When a middle manager is taking on the role of the “learner” there is a great temptation for him to delegate tasks to others, and get reports. This is status quo, and does nothing at all to develop capability.
Like everything else we do in the West, or at least in the USA, we try to get there fast by skipping the basics.
Make no mistake – you don’t “implement Toyota Kata.”
You use it as a structure to build foundational capability and new thinking patterns.
Those patterns are only developed through practice, and deliberate reflection on the management process itself.
I have also seen an organization that is “getting it” pretty quickly. The difference is that they are all overtly in “we are just learning this” mode, and willing to make mistakes and learn from them vs. trying to appear to be competent from the get-go.
Mike Rother has other videos on YouTube as 734Mike.