Since writing that, I have been doing a bit of reflection on my own development as a coach, and I need to give credit where it is due.
As any regular reader knows, I have been an enthusiastic student and practitioner of Mike Rother’s Toyota Kata since I first read the book. I have written extensively about it in this forum. And I have made my own modest contributions to the practice. It has been over this time, and countless cycles of guiding beginning (and intermediate, and expert) learners through The Five Questions that I can hold the structure in my own head while not imposing rigidity onto others.
I will always default to using the formal structure because I think, in the vast majority of cases, it sets a better foundation. And even in those cases where I have to let go of the structure, that is a temporary countermeasure.
Once my learner is comfortable with the meta-patterns, then the structure follows, and makes sense to them. Some people learn that way, and I have to be able to pick that up.
I may have been an OK coach before all of this, I likely overestimated my ability at the time. Today, though, thanks to the Toyota Kata structure, I am becoming more comfortable with… not letting go if it, for I hold it in my own mind, but maybe withholding the framework and letting the learner fill it in more fluidly.
As we are boring down on the 10th Anniversary of Toyota Kata, and the 5th KataCon, we have a great opportunity to look at how the pattern that Toyota Kata teaches reaches far beyond process improvement and problem solving.
I will be speaking on the topic of Developing Leaders for Continuous Improvement on Day 1, and yes, we can use the same meta-patterns. Craig Stritar and I will be taking a much deeper look into the same principles in our Experiential Workshop. If you want to get a hands-on, reflective look at meeting your challenges as a change agent, come join us there.
In reality, the teacher learns by sharing and swapping experiences with others. I am not going to try to list everyone you will, and should, meet at KataCon here because I would surely leave someone’s name off my list by accident. But look at the presenters and speakers. I know most of them and were I not presenting my own workshops and breakouts, I would be hard pressed to decide which ones to attend. You can’t make a mistake here.
I’m going to break a rule of blogging and acknowledge I’ve been pretty much offline for quite a while since the last post. But I also want to push through what I started because this all leads to more.
My next pages of notes I took at Menlo were about crafting a message for a Kata Geek audience – what is it about Menlo’s process and culture that is relevant to them (you?).
Again, I am going to pretty much transcribe my notes, though I am going to edit a bit as I wrote them in first person as though I was Rich, and I am not going to do that here. In the end, these became a foundation for the keynote I ended up giving following his.
Key Point: These words are mine, and no one else’s. I do not pretend to speak for Rich or anyone else, I was simply consolidating my own thoughts by using a possible talk as a vehicle for myself.
Theme: The Improvement Kata: Experimenting to create a deliberate culture.
(Scene 1: Exposition)
We are probably all after the same thing: To create a workplace where people are excited to come to work every day.
That experience has little to do with the work itself. It emerges when we can create a culture where:
Fear has been extracted.
Ambiguity (that causes fear) has been eliminated.
Relationships are strengthened every day.
I believe Menlo has created that culture. What I want to do today is discuss how you can use what you are learning with Toyota Kata to create these things in your own organization… Even (especially!) if you are not in charge
(Note – this part may be a little confrontational)
If you are in charge, there is nothing and no one stopping you. It is a matter of knowing what you really want, and being accountable to yourself and your team to create it.
Joy is very different from happiness. Joy is what we experience with the release of creative tension (figuring it out).
Success vs a challenge
Winning a game against a tough opponent.
That feeling we get when “it works!”
We can also experience joy with relief or resolution from psychological or physical danger – the same brain chemicals are at work – but this is DRAMA, not creative attention. We don’t want this, because it is relief from FEAR, not a sense of accomplishment.
(Scene II – “The Call”)
To create joy in others, you must fist look at yourself.
Cross the bridge
Take a step
Give yourself permission to NOT get everything right the first time – EXPERIMENT
“The most dangerous thing you can do is try to pretend you know when you don’t” – leads to paralysis by fear of discovery.
Until you can comfortably say “I don’t know” to yourself, you will be unable to learn.
“Find a a coach / be a coach” with whom you can create a bubble of safety to explore your own threshold of knowledge as a change agent. Arm yourself with allies.
(Scene III – “Walk into Mordor”)
In a large organization, middle management sets the tone.
This is the end of the notes I was taking, but these themes get explored more deeply as I continued this journey.
I have been telling everyone who will listen to read Rich Sheridan’s book Joy, Inc. ever since I came across and read it in the fall of 2015.
Fast forward to earlier this year when Lean Frontiers sent out their request for suggested keynote speakers for KataCon. I wrote to Mike Rother and asked him “Do you think we could get Rich Sheridan?”
Skip ahead a bit more, and I spent four days last week at Menlo Innovations in Ann Arbor – two days “in the chalk circle” paying close attention to the actual day-to-day work there, and two days working (pairing) with Rich Sheridan to work out the key beats for his KataCon keynote.
If you visit Menlo (and I really hope you do!) here is what you won’t see:
“5 Questions” coaching cycles.
Obstacle parking lots.
Experiment Records (PDCA Records)
In other words, you won’t see the explicit artifacts that characterize an organization using Toyota Kata to learn how to think about improvement scientifically. In that sense, Menlo isn’t a “Toyota Kata” benchmark.
You don’t see those things at Toyota either. You don’t go to Toyota to see “Toyota Kata.”
The Underlying Thinking Pattern
What you will see (and hear… if you pay attention) at Menlo Innovations is an underlying pattern of scientific thinking and safe problem solving in everything they do.
Let’s review what Toyota Kata is really all about.
Rather than re-writing something elegant here, I am going to quote from my part of an email exchange between Mike Rother, Rich Sheridan and me:
Going back to Mike’s original research premise, we knew that Toyota has this pretty awesome culture thing, but didn’t really understand the “secret sauce” of the exact structure of their interactions. Put another way, we saw and understood all of the artifacts, but copying the artifacts doesn’t copy the culture.
Mike’s research was really the first that dug deeper into the interactions that the artifacts support.
Once he extracted that “secret sauce” he then boiled off all of the other stuff, and what remained at the bottom of the pot was the Improvement Kata steps and the Coaching Kata steps.
In practice at Toyota, those things are deeply embedded in the artifacts. Sometimes they aren’t even spoken.
My informal hypothesis was that if I spent time paying attention to, not just the artifacts, but the way those artifacts guided interactions at Menlo, and then boiled off the other stuff, what would remain at the bottom of the Menlo pot would also be the Improvement Kata and Coaching Kata steps. And, though I didn’t do this formally, and yes, I had confirmation bias working here, I believe I can safely say “I have no evidence to contradict this hypothesis.”
In our conversation on Friday, Mike pushed back a bit on “just run the experiment,” [context clarification: Experiments to randomly try stuff, without a clear target condition rarely get you anywhere] but the reality I observed and heard was that “purpose” (challenge and direction) and “current condition” are deeply embedded in the day-to-day interactions, and “just run the experiment” is, indeed, working on a specific obstacle in the way of a target condition of some kind.
“What problem are you trying to solve?” is Menlo jargon that I overheard many times just listening to people talk.
Within Menlo, that term is contextual. Sometimes it is about the higher-level direction and challenge.
Sometimes it is about an intermediate target condition.
Sometimes it is about an immediate problem or obstacle.
As we say in Kata world, it is fractal. It is truly fractal at Menlo as well, to the point where the words don’t change at various levels.
The words DO change at various levels in Toyota Kata’s jargon, but we can’t get hung up on the terms, we have to look at the structure of problem solving.
Menlo’s co-founders already had this thinking pattern, and deliberately sought to embed it into the culture of the company they were starting. There wasn’t really any need to explicitly teach it because they weren’t trying to change the default behavior of an organization. New Menlonians learn the culture through the interviewing and on-boarding process and adopt very quickly because the very structure of the work environment drives the culture there.
In fact, spend any time there even just hanging out, and it is very difficult NOT to get pulled into The Menlo Way. Like everyone else, Rich and I were in the daily stand-up as pair-partners, reporting our work progress on his keynote.
What About Toyota Kata?
Menlo has had hundreds (thousands, actually) of visitors, and those who are “lean savvy” all ask if Menlo is “using lean” as their guideline. The answer is “no, we are just trying to solve problems.” While they have certainly incorporated most of the artifacts of “agile software production,” the purists push back that they aren’t “really doing it” because they didn’t copy those artifacts exactly. Nope. They used them as a baseline to solve Menlo’s problems.
When we see an awesome problem-solving culture, it is tempting to try to reverse engineer it by copying the physical mechanics, such as heijunka boxes (work authorization boards), kanban, “standard work” and the like.
But we have to dig down and look at the routines, the behavior that those artifacts and rituals support. When we do, we see the same patterns that Toyota Kata is intended to teach.
You need to begin with the thinking pattern. Use Toyota Kata to learn that.
As you do, take a look at your artifacts – the procedures, the policies, the control mechanics of your work. Reinforce the ones that are working to create the kind of culture you want. Challenge the ones that are getting in your way. Do both of those things as deliberate experiments toward a clear vision of the culture you want to create.
That is the benefit of studying companies like Menlo.
I hope to see you all at KataCon, hear what Rich has to say to our community, and establish a link between these two communities that have, up to now, been separate.
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?