I recently did an “Introduction to Toyota Kata” session for Kata School Cascadia. The intent is to give an overview of my interpretation of the background, and how Toyota Kata fits into, and augments, your Continuous Improvement effort.
Here is a direct URL in case you can’t see the embed on your phone or pad: https://videopress.com/v/4vWvDZRe
In this presentation I go over what I mean when I say “culture” and then briefly discuss a “continuous improvement culture.” Then introduce the “why” of Toyota Kata as a way to start to nudge the culture in the direction we want it to go.
Finally I overview the structure of the Improvement Kata and Coaching Kata, then answer a couple of questions.
Let me profile a company – I have an actual company in mind, but this one is only a concrete example.
This company has been engaged with continuous improvement since at least 1998. Yet, just a few weeks ago, they posted an opening for a Continuous Improvement Director. And this isn’t the first time. I have seen this position posted by this company every couple of years.
The posting explicitly calls out this C.I. director’s responsibility to “champion” their “[Corporate Name] Business System.” That at least implies that the [Corporate Name] Business System is something aspirational that must be internally championed by others rather than the way they simply do business every day. Indeed, they feel the need to hire someone from outside the company to champion their [Corporate Name] Business System to their own leaders. This is pretty strong evidence that the actual Business System within the company is something radically different than [Corporate Name] Business System.
This is not a sign of success over the past quarter century. Quite the opposite. We have a company with people on the payroll who were not even born when the C.I. effort was initiated. If senior leaders have come up through the company ranks, they have been exposed to the tenants of the [Corporate Name] Business System their entire careers.
Yet it is still necessary for a dedicated person to advocate for it.
If this company might be you… here are some questions to think about:
How much actual cultural change has taken hold in the day-to-day operations since you have been engaging in kaizen activities?
Is the daily activity of your line leaders – the team leaders, supervisors, first line managers – reflective of something other than your [Corporate Name] Business System? If so, why? What forces are at work to push those activities in a different direction than the one you say you want? For example, are there metrics or line management expectations that run counter to moving continuously toward 1:1 production at takt? What policies or expectations are in place that systematically undo the results of a kaizen event?
How much daily kaizen is done by your line leaders? Your supervisors? Do your first-line leaders coach your supervisors on improvement? Are they qualified to do so? If yes, do those improvement activities tier up through line management toward the higher-level goals of the company?
Do your manufacturing supervisors have the basic industrial engineering skills? Can they fluently talk about takt time, cycle time, flow, work balance, etc? Are those skills represented in the way they run their day-to-day operations?
If the answers to these questions are largely in the negative — if you have been at this for two decades+ and they are still in the negative, then I think I can safely say that this isn’t just some kind of fluke. What you have been doing is not working. If you are looking to do more of what you have been doing, maybe consider trying something else.
That being said, don’t give up. It isn’t that this stuff doesn’t work, it is that your approach to embed it into the organization has, up to this point, been ineffective.
Consider an approach where the primary focus is on the patterns of day-to-day interactions between people, working toward having them engage in effective problem solving and learning on a daily basis. If improvement only happens as an event, then it is, by definition, not “continuous.”
I believe that structuring those day-to-day interactions is the purpose of all of the so-called “lean tools” (and all of the other “tools” called out by other packages such as TQM, xSigma, TOC, etc). But unless those tools are deployed with that purpose in mind, it is all too easy to put in the mechanics without creating any shift in the culture.
And it is the culture that actually matters.
So ultimately my question is this: Do you have the continuous culture that you want today? If your [Corporate Name] Business System is actually in place, congratulations. But if that culture is still aspirational, and if you are trying to, yet again, hire someone from outside to champion that culture, what is everyone in charge doing?
Lately the term “socio-technical system has been starting to show up more and I thought this would be an opportunity to weigh in on what I think it means.
Though the concept has been around since at least 1951 (see below), I think I have tended to “bleep over” the term as jargon without giving it a lot of thought. I don’t think I am alone in that.
People who try to describe the meaning tend to describe a system “that integrates the social and technical aspects” or words like that.
I would posit that it goes much deeper, and we “bleep over” the concept at our peril if we want our organizations to function well.
The Origin of Social-Technical Theory
*Up through the 1940s, coal mining in the UK was largely pick and shovel work aided by drills and, sometimes, explosives. A work crew typically consisted of three to half a dozen men (and they were all men) who were task organized to strip the coal off the seam face, shovel it into mining carts, and move those carts to the transport system.
These teams were distributed through the mine, and because the distance and working conditions really precluded a lot of supervision, the teams largely oversaw their own work.
Since each team worked independently, the system as a whole could easily accommodate the simple fact that in some spots the coal is harder to dig out than in others.
The work also met every definition of “difficult, dirty and dangerous.” That work environment, though, created a social bond among the team members as they worked together to accomplish the task of “mining coal.”
The system was not without its problems, however. The social structure was built around loyalty to the small work team. When “trams” (coal carts) were in short supply, for example, the “trammers” would horde carts to optimize their team’s performance at the expense of other teams being limited by the number of carts available.
This all changed shortly after WWII.
The Long Wall Method
In the late 1940s the industrial engineers turned this craft production system into a factory system with the tasks divided between three shifts.
Long Wall Mining Shift Schedule
The process would begin on the evening shift. They would drill blast holes along the top of the coal seam, then dig an undercut about six inches high at the base to allow the blast to drop the coal. This would be done along a long (up to a couple of hundred meters) face of the coal seam. (Hence the name “long wall mining.”)
Meanwhile another team would break down the conveyor system that ran parallel to the coal face in preparation for moving it forward to position it for removing the loose coal.
Then night shift had two teams. One would extend the “gateway tunnels” at either end of the coal face. This was a crew of 8 men. Simultaneously another team would rebuild the conveyer in the new position.
Once all of this work was done, the shots would be fired, dropping the coal into a pile along the coal seam face.
Day shift would take the loose coal and transfer it to the conveyor system to be taken out of the mine.
Yes, this is an oversimplification, but it suffices for this discussion.
On paper, this process was far more efficient.
In practice, though, things did not go smoothly.
“Isolated Dependence”
A “filler” loads loose coal onto the conveyor.
Looking at this work breakdown, the first two shifts are prep work. Only the day shift, the “fillers,” actually get the coal out of the mine. But their success was entirely dependent on how well the first two shifts did their jobs. If everything was not “by the book” then the fillers would be significantly hampered. Since they were paid by the ton of coal extracted, there was more at stake than just a sense of accomplishment.
If the previous shifts ran into problems – such as a “shot” that failed to separate all of the coal from the roof of the seam, or harder material, etc. these inconsistencies slowed down the “fillers” and made them less successful. If the conveyor was not completely or correctly assembled, they could not begin work until this was corrected.
Because management pressure was on the key performance indicator – the rate of coal extraction, and because the “fillers” were paid by the ton of coal extracted, this created resentment between the “fillers” and crews on the other two shifts, as well as conflicts with management which the working crews began to regard (with ample evidence) as disconnected from the realities of their work.
Then, if the “fillers” were too far behind at the end of their shift, that would delay the start of the next cycle and things spiraled downward from there.
Productivity plummeted. The study I am citing here was commissioned to determine why. Their conclusion, in short, was that the new work organization was built around the paradigm of a factory assembly line without regard for the variation of geology. Success of the three shift cycle depended on each shift meeting a rigid schedule, but that schedule did not account for the simple fact that coal seams are not uniform.
In addition, the work organization destroyed the social structure of the mining crews. Their success was dependent on people they no longer saw or interacted with. The oncoming filler shift, in particular, would be confronted with all of the obstacles left by the previous two shifts. As their resentment for being unsupported built, their willingness to put in any extra effort dropped to zero.
Again – this is an oversimplification. If you want to read the full paper there is a link at the end of this post.
Oversimplification or not, however, the effect was stark. The social structure of the organization was driven to fundamentally change by alternations in the technical structure of the work. Quoting from my source material* :
The effect of the introduction of mechanized methods of face preparation and conveying, along with the retention of manual filling, has been not only to isolate the filler from those with whom he formerly shared the coal-getting task as a whole, but to make him one of a large aggregate serviced by the same small group of preparation workers.
The work design was based on a mechanistic view that ignored the how the social structure impacted the performance of the team.
By the turn of the last century we thought we had the ways of the universe pretty well understood. Hundreds of years (thousands of years in some early societies) earlier we had the ability to predict the motion of the stars and planets – to the point that we could build machines that were analogues of their movements.
The prevailing model in psychology was classical conditioning which, in essence, said that behavior is an almost algorithmic learned response based on previous positive and negative reinforcements.
This mechanistic model leads to a belief that we can carefully design the machine and people’s work within the machine can be carefully designed and shaped through rewards and consequences.
And as long as everything, and every one, works as they are supposed to, it’s all good. If a machine malfunctions, we fix it. If people don’t follow procedures, we “motivate them” with incentives.
This model prevails even today and even colors our teaching of continuous improvement. One of the places we need tend to inherently adopt a mechanistic view is when we use the word “system.”
The Mechanistic View of “System”
In today’s world, when people talk about “the system” they are often referring to an information system of some type. Common examples are an Enterprise Resource Planning (ERP) system, or an Electronic Health Records (EHR) system. And these information processing systems do tend to shape how the organization functions, for better or for worse.
So when people talk about a “system” I think the reflex is to think of the system as a machine that is carefully designed, built, and tuned to perform a particular function or behave in a particular way.
And people tend to assume that once it is working, it will continue to work so long as it is maintained to be kept in the same condition.
This thinking often extends to the people as well. They are often viewed as servicing “the system” – providing it with information, and following the instructions it gives. (this is particularly true in ERP / MRP environments.) Everything is part of a machine, and as long as everyone does their jobs, and the equipment functions as intended, then it all works.
In practice, though, these systems tend to isolate people from one another, or into small single task groups in much the same way as happened in the coal mine.
The Mechanistic Paradigm at Work
The reason I explained all of this is so we can look at our own workplaces through this lens. The crucial question is: Do the work structures and systems support or hamper the social structure of effective teamwork?
Let’s take another look at those ERP or EHR systems. Without the interaction with and the interaction between the people who use them, those “systems” are inert. They do nothing. The mechanistic paradigm, though, tends to look at people as performing a task to serve or enable the system. Instead, we should look at the information system as a tool that should enable people do to a job they otherwise could not.
On the Shop Floor
The sign says “Hearing Protection Required.” The reality is that it is impossible for more than 3 or 4 people to have a conversation on the shop floor, as they are shouting to be heard. The final operation is highly automated, each machine has two people working in isolation, even from one another for the most part. In addition, the machine crews are isolated from one another, both by distance and by the noise level.
The machine operator is measured on his hourly rate of production vs. a standard expectation.
Meanwhile at the opposite end of the building, the production scheduling team works to carefully orchestrate the availability of packaging materials, purchased components, as well as scheduling each phase of production so work is available for the next step.
They do all of this with their ERP system and every day they create orders to issue components, production orders to the various areas in the shop, and purchase orders to their suppliers. They adjust priorities at least daily, based not only on lead times and changing customer requirements, but also on the reality of what has actually been produced, or not, up to this point. Items are early, they are late, production runs ahead, though mostly behind, the scheduled intent.
Everyone is frustrated. The planner / schedulers because production never seems to make what they planned. And production because scheduling never seems to schedule things that can be made with the available materials, etc. Shortages are discovered, an ad-hoc plan is created to keep things moving – but that may well consume components that were earmarked for something later in the week, and the cycle continues.
To make things even more interesting, the planner / schedulers are using production capacity numbers that they know are higher than reality. They are under pressure to put in unrealistic numbers because the real numbers would make the site’s cost estimates too high and attract scrutiny from corporate.
This means “the system” produces schedules that cannot be met by actual production even if everything else works, which, in turn, means continuously over-promising, under-delivering, and adjusting priorities.
Though the work is very different, we have a social structure not unlike the British coal mine.
This is what “isolated dependence” looks like in today’s work environments. If you are seeing blame casting and conflict between groups who are dependent on one another you likely have a similar situation in your organization.
Counter-Productive Response
Unfortunately the typical management response is to increase monitoring, control, incentives, “accountability” on individual parts of the process rather than looking at the entire system.
These things tend to increase the sense of isolation and frustration as they can create a sense of victimhood between the separate groups. For example, in the above situation everyone there told me that they used to have pull system on the factory floor, and it had worked really well, operated predictably, and gave them a lot more insight into what was actually happening. But some time ago a new management team wanted to track everything in the computer “for control” so the current system was installed.
Ironically, that management team had turned over, but for whatever reason people were very reluctant to return to what they knew had worked in the past. But I digress.
The Implications
Human beings are innately social. In any organization, or casual group trying to get something done, people develop webs of social networks. The more they can interact, the more everyone stays on the same page.
There are a few things we can do to reinforce this.
Bring People Together
And I mean bring them together literally, physically. Rather than just confronting one another in the morning meeting, have them literally work side-by-side with the common goal of a smooth process.
Have a Shared, Objective, Truth
Eliminate the need to ask or query “status.” Eliminate the one person who knows the big picture. Get the truth out there in the open– literally, physically. (See a trend here?)
In a well managed operation I nearly always find rich “information radiators” that are an inherent part of the process itself (rather than being a display of information that was input just so it can be displayed). This information is not simply a passive display. It is actively used by the people doing the work to they know where they stand, what comes next, and when they need to raise a concern.
A classic example of this is a heijunka or load-leveling box. The cards, or work orders, or pick tickets, are placed in slots that are based on the time that work is expected to start if everything is working normally. Thus it is insanely easy to spot if something is getting behind, long before it would show up in the daily production report. Menlo Innovations’ Work Authorization Board does the same thing.
The goal is for conversations to be about “How to respond” rather than discussions about “what is happening.”
This is really the purpose of nearly every “lean tool” — to ask, and answer, two key questions:
What should be happening?
What is actually happening?
and then invite a conversation about any difference between the two.
The fact that “we have made 234 widgets” is meaningless without a point of comparison of “how many widgets should we have made up to this point?” The goal is to invite curiosity and foster actual conversations, and eliminate debates about what should be and what actually is.
But more often, this is what I most find lacking. People well tell me they can easily query status, look up individual orders, but even then there is rarely a timely comparison between “nominal” and “actual” in that information. Even if status can be queried, there is often a lack a “compared to what?” Or worse, the status is abstracted from reality, for example, measured in “earned hours” or some other financial metric. Often “ahead or behind” is not known until the end of the day… or the week, or sometimes even the month. The greater the lag, the bigger is the scramble to make up production with overtime.
So here is question #1 for you: If I were to ask you, right now, “Is this operation ahead or behind?” could you tell me? Can the people who are actually doing the work tell me? And by “tell me” I mean immediately, without having to go research or launch some kind of query.
Another version of this question is, “How far behind do you allow yourself to get before you actually know there is a problem?”
Social-Technical
So what we have is a technical aspect of a process that is deliberately designed to support meaningful social interactions between the people responsible for carrying out the work and accomplishing the overall task… as a team. We bring people together rather than isolating them from one another.
This is hard – Yup.
And these principles run against management “best practices” that have been taught since the 1920s.
Where to start? If any of this seems impossible, work on trust. Think about this – Why would people be reluctant to display an objective truth without the ability to first qualify it?
Why would people be reluctant to create a true dependent relationship with another department?
All of these things come down to a culture of self-defense because people feel a need to protect themselves from something or someone. Even if that force is long gone, the effects of leadership-by-fear linger, sometimes for many years, unless you take proactive and direct steps to eliminate that fear.
Once again I am going through old files. These are some notes I wrote back in 2005 that I thought might be interesting here. Looking back at what I was writing at the time, I think I was thinking about nailing these points to a church door somewhere in the company. That actually isn’t a bad analogy as I was advocating a pretty dramatic shift in the role of the kaizen workshop leaders.
All Saint’s Church – Wittenberg, Germany
This was written four years before I first encountered Toyota Kata, and reflected my experience as a lean director operating within a $2billion slice of a global manufacturing company. What reading Toyota Kata did for me was (1) solidify what I wrote below, and (2) provided a structure for actually doing it.
Perhaps this will create some discussion. If you are interested in getting a Zoom session together around it, feel free to hit the Contact Mark in the right sidebar (or just click it here) and drop me a note. If there is interest, I’ll put something together.
Kaizen Events
Kaizen events (or whatever we want to call the traditional week-long activity):
Can be a useful tool when used in the context of an overall plan.
Are neither necessary nor sufficient to implement [our operating system].1
There are times when any specific tool is appropriate, and there are no universal tools. Kaizen tools included.
(Our operating system) is, by our own model, the “Operational Excellence” pillar of (our business system). This is keyed in leadership behavior, not implementation of tools. The tools serve only to provide context for leaders to rapidly see what is happening and the means to immediately respond to problems.
Thus, focusing on implementing the tools of TPS (takt time, flow, pull, etc) outside of the immediate response and problem solving context is an exercise which expends energy and gains very little sustainable change. This is independent of whether it is done in a week-long intense event or not.
However, in my experience, organizations which take a deliberate and steady approach implementing have had more success putting the sustaining mechanisms into place. While it is sometimes necessary to bring teams together for a few days at times to solve a specific problem, or to develop a radically different approach, these efforts tend to be more focused than a typical kaizen week I see.
When the kaizen week is scheduled first, and then the organization looks for what needs improving, this is a symptom of ineffective use of the tool.
In general, a kaizen, whether it is a week, a month, or even just a few minutes, must be focused on solving specific problems which are impeding flow or are barriers2 to the next level of performance. Without this focus, there is no association with the necessities of the business, and no context for the gains.
There are a few simple countermeasures which can be applied to a kaizen week activity that focus the participants much more tightly on learning the critical thinking.
Improvement can, and must, take many forms. A week-long kaizen activity is but one. It is expensive, time consuming, disruptive, and should be used deliberately only when simpler approaches have failed to solve the problem.
Classes and Courses ≠ Teaching and Learning
Bluntly, even though we preach PDCA and say we understand it, we are not applying PDCA in our education approach.
Some fundamental tenets:
All of our teaching should be contextual and focused on what skill or knowledge is required to clear the next barrier to flow or performance.
The above does not rule out teaching fundamental theory, but fundamental theory must be immediately translated into actions and put into practice or it will never be more than a nice discussion.
The vast majority of our teaching should be experiential, and based in real-world situations, solving actual problems vs. examples and contrived exercises.
We want to move our teaching toward an ideal state (a True North in our approach) where it is:
Socratic – focusing people on the key questions.
Experiential – learn by application to solve real problems and thus gain experience and confidence that the concepts translate to the real world.
Thus, education and training is but one tool used by leadership to help people clear the barriers and problems that block progress toward higher levels of performance.
As far as I can determine, the “Toyota Way” of teaching is similar to this model.
Content
The content of training is as critical as the way it is delivered.
Our objective is to shift people’s thinking, and in doing so, shift their day-to-day behavior as they make operational decisions. The target audience for all of our efforts are the people who make decisions which impact our direction and performance. This is anyone in any position of leadership, at any level of the company – from a Team Leader on the shop floor to the CEO.
The key is to embed the structure of applying PDCA into all of our content. For example:
Every tool, technique, etc. we teach, or should teach, is some application of the above. (The rules-in-use include problem detection, response, and problem solving.) I have yet to encounter an improvement tool or technique that does not fit this model.
This approach fundamentally re-frames the concept of “problem” and what should be done about it.
The Toyota Production System (in its pure state) is a process which delivers a continuous stream of problems to be solved to the only component of the system that can think – the people. This is how people are engaged, and this is what makes it a “people based system.” Leave this out, and “people based system” is just hollow words. Nearly every discussion talks about how important people are, but then dives right into technical topics without covering how people are actually engaged — outside the context of a week-long kaizen.
The Role of “Workshop Leaders” in the (Continuous Improvement Office)
No one has disputed the critical make-or-break role played by the line leadership, not only in implementation, but even more so in sustaining.
Workshop leaders are generally taught to plan and lead workshops. The emphasis is on the week-long workshop logistics; on presenting modules in classroom instruction; and on the skills to facilitate a team through the process of making rather dramatic shop floor improvements.
In a typical (not saying it happens here) implementation scenario, it is the workshop leaders who go to the work area, do the observations (usually without a lot of skilled mentoring, and usually just to collect cycle times); build the balance charts and combination sheets; plan what will be changed; how it will be changed, set objectives, targets and boundaries.
They are the most visible leadership of the teams during the week, and they are the ones tracking and pushing follow-up and completion of open kaizen newspaper items.
The effect of this (which is fairly consistent across companies) is:
The standard work tools are something workshop leaders use during improvement events.
Cycle times, observations, and looking for improvement opportunities is something that is the domain of the workshop leaders.
Actually guiding the team members through the problem solving process is the job of the workshop leaders.
The supervisors and managers are there as team members, in order to learn by participation, from this outside expert.
The question is: Who is responsible to coach the line leaders through the process of handling the problems that the TPS is designed to surface in operation?
Once the basic flows are in place, there will be a stream of problems revealed. Those problems will either be seen or not seen. IF problems are seen, they will either be dealt with quickly, following good thinking, or they will be accommodated so they go back to being unseen. This is a critical crossroad for the organization…. and it is the behavior of the first and second line leaders, and the support they get from their leaders, that most influences whether the system backslides or continues to get better and better.
IF problems are seen, they will either be dealt with quickly, following good thinking, or they will be accommodated so they go back to being unseen.
Note: There is not middle ground. One-piece-flow really can’t sustain in a stable state. It is either improving or getting worse. It isn’t designed to stay still, and it won’t. Continuous intervention is required for stability, and that intervention is what improves it.
Who is teaching the leaders to do this?
Each leader must have a coach, by name, who can, and will, always challenge his thinking and his solutions to problems against a specific thinking structure.
My view is this is the primary role for the Kaizen Promotion Office.
The way to do this is through application of a few core skills, and skills can be taught.
We should:
Include this vital role into the expectations of a “workshop leader” – to take them closer to being “coordinators” in the Toyota factory start-up model.
Provide these “coordinators” with a specific support process so they know that they can quickly get assistance if they feel they are in over their heads.
The role of that assistance is not to step in and solve the problem. It is to take the opportunity to teach both the workshop leader and the area manager by guiding them through solving the problem.
My experience with this concept is that teaching these skills to someone is not as difficult as most people assume. The basics of observing and seeing flows can be taught over a few days to someone who is motivated to learn. The skill of teaching by asking questions can be accelerated from the “pure” method by telling them what is being done in why. “This isn’t about the answers, it is about learning the questions.”
Application and good teaching can easily be verified by checking the leader’s (the student’s) level of skill and behavior. (The senior teacher checks the teacher by checking the student… just as the area supervisor checks the Team Leader’s teaching by verifying the standard work on the shop floor.
None of this is an advanced topic. These are the basics. Once a good context is established in people’s minds, my experience suggests that the Toyota system is no longer counter-intuitive. The tools and techniques that, at first, seem alien now make sense.
——–
1 By this I meant to shift the operating culture to one that inherently supports continuous improvement.
2 In Toyota Kata language, we would say “obstacles.” I had used the term “barriers” up to that point.
Jeff Kaas talks about Leader Standard Work https://kaastailored.com/blog/what-is-leader-standard-work/
The people at Kaas Tailored in Mukilteo, Washington are friends, neighbors, and colleagues of mine. They have been a tour stop for people from all over the planet who want to learn more about their people-centric culture of continuous improvement.
Last year when the tsunami of COVID washed over all of us, their business faced an existential threat and they made a dramatic pivot to making medical PPE – masks and face shields. Their main motivation was “This is what our community needs right now.” In fact, you might have seen a bit of their story as part of the PBS Frontline Coronavirus Pandemic episode.
Dramatic change reveals obstacles that may have been buried under the Old Normal, and this was certainly the case for Jeff Kaas and his team. The awesome part is that they doubled down on their effort to learn and practice Toyota Kata as a response. They needed better organizational alignment, tying their organization’s philosophy and direction down to their day-to-day processes, and they used Toyota Kata to do that. I think they are emerging as a stronger organization as a result.
I mentioned in the opening that they have been a tour stop for many years. To further that end, they have worked hard to make that experience available online. What is cool about it is now it isn’t necessary to travel to Mukilteo, Washington (about 20 miles north of Seattle) to see them. They can come to you.
So when they asked me if I would like to participate with them in a series of online events they will be presenting starting on March 24, 2021 my response was an immediate Yes. To be clear, my role is chiming in with color commentary, and perhaps being a little more in front when they start talking about Toyota Kata.
If you would like to participate, here is their registration page:
MONDAY: 2 PERS 1 MACHINE. TODAY: 1 PERSON 2 MACHINES
On a Thursday afternoon in the summer of 1997 I sent that pager message (remember pagers?) to Rick from the factory where I had spent a week working with Mr. Shimura of Shingijutsu and Reiko, his interpreter.
I knew that Rick would be wrapping up a class teaching the basics of kaizen events to a group of suppliers and if I were lucky, he would see the pager message and use it as a reinforcement to the participants. Rick and I usually alternated teaching that class, sometimes we taught it together. We were good work partners, finishing each others’ sentences and the mutual respect was very high.
I was on-site at another supplier. We were there to help them take some first steps toward “lean production.” Our goal, at least the idea, was that we would work through the process of making significant improvements with the thought that they would learn enough to try it themselves.
This was not my first visit – the episode with Mr. Iwata that I relate in my third post to this blog had happened there a couple of months earlier, and that visit had resulted in my company offering up Mr. Shimura’s time on our dime.
This may well have been “an offer they couldn’t refuse” and I’m not sure everyone there saw it as help. We were from their 800 pound gorilla customer, they had trouble making on-time deliveries, and sometimes that isn’t the kind of help that you want. From their perspective their biggest customer had people who knew their way around a factory spending days on their shop floor and, most certainly, ascertaining how much more productivity was possible if only, well, the buyers squeezed them hard enough. It didn’t really work that way, but it had worked that way in the past, so who could blame the suppliers for thinking this was a more sophisticated way to audit them?
Anyway, we had worked through the week to carefully look at the tasks involved to unload, load, and machine a single part on a large linear milling machine. Mr. Shimura was there asking questions, not so much from curiosity but to direct my eyes. I’m sure he already knew the answers. As we dug into the timing, it became clear that there was enough operator waiting time as the part was being milled that a single operator could, theoretically, unload and load an adjacent machine – operating two of them at once.
So we carefully worked out the chorography required to make it work, and on Thursday mid-day it all came together. The work was flowing, the parts were flowing. It was really a thing of beauty.
Friday morning we would report out the week to management, and Friday afternoon I would head to the airport to go home to Seattle.
But I had some worries as well. Although the company President, and the VP of Operations were supportive, their support was along the lines of welcoming everyone into the plant, making it clear they were happy to see us, attending the final report-out and endorsing our efforts.
I was still pretty knew at this. I was making the transition from teaching classes and running simulations to making real change in real factories (that weren’t mine!). I was really fortunate to have a lot of 1:1 time with Mr. Shimura and Reiko. I asked questions, he patiently taught me how to use the standard work combination sheet, and other nuances of kaizen and flow production. I got a lot more out of that week than the supplier did simply because I was there spending time with Mr. Shimura and taking advantage of every second I could. I had 1:1 time because none of the supplier’s managers were seeking him out to learn from his vast experience.
Some quotes I will never forget: “If I see something is hand written, then I know at least one person has read it.”
“If parts that are in tolerance don’t fit, it is a problem with the tolerances.”
(Walking through the shop) “Does this company lose a lot of money?” Reply: “No, they are very profitable.” “Then their prices are too high.”
In the end, though, I am equally certain that come Monday morning the work sequence we had so carefully worked out – at great expense to my company for my time, my travel, Mr. Shimura, his interpreter, and others – was never repeated again.
Why not?
Well, we can all blame “management commitment” because that is really easy to do. But I put equal weight on our paradigm of improvement at the time. The idea that, in 4 working days we could institute a change that flew straight against the operational and cultural norms of the company and expect it to last any longer than until we were out the door was, well, ludicrous.
Why should we expect anything different?
It is ludicrous in any company, whether this work is being brought in from outside or internally generated.
The people who have to manage the daily work, whether they were involved in this exercise or not, have no paradigm for dealing with the myriad of issues that are bound to be surfaced after we pulled all of the buffers out of the material and the time. Yes, it can work, IF we understand the conditions required for success, and IF we pick up right away when those conditions aren’t there and IF we respond to fix it very fast. Then, yes, it can work.
It will be more time and trouble than it was before, though, unless the next things are also done.
For at least some of those issues – maybe not all of them, but always working against a couple of them – seeking out why those issues happened and dealing with the causes.
Just to keep this tiny two-machine “work cell” operating in this large factory would have eventually engaged every support system they had.
That’s the whole point, actually, of a model line. It isn’t building the model line. It is what you have to fix in your systems to keep it going.
Many years later I spent a week on another company’s shop floor with their internal kaizen team and getting an andon / escalation process up and running was the only thing we were working on that week. That process is just as important, if not more, than the baseline work of flow. Because without it, your flow will fall apart.
This is the part of the process that engages people. Putting in the baseline process is the easy part. Fielding the problems that flow surfaces – that takes changing the day-to-day routine in the workplace, and is a lot harder. That is where the culture change comes into play. Actually it is more than engaging people. It engages specific people: This is the part that must engage the leaders. They must lead, guide and coach process of working through all of the issues so stability can be reestablished. Then challenge the team to get to the next level.
But all of that is what I know now. I had the knowledge back then, but not the deep understanding.
So – I am thankful for that week because my understanding of what I had been teaching for months easily doubled… twice in those few days.
I was back there a few more times, they even gave me a badge (which I still have somewhere) so I could let myself in. One time I spent two straight weeks there. They were good people.
But we were applying work to the technical systems, and never really dealing with their default responses to problems, their culture, the way they went managing their daily work.
I know so much more today it is actually humbling to write this. And I still have a lot to learn. We all do.
The company I was working in? They were sold, and sold again. I think they are still in business, but I wouldn’t know anyone there.
I’m digging through old archives again, and came across this graphic I put together around 2006 or so. It depicts more detailed version of “Organize, Standardize, Stabilize, Optimize” showing the continuous comparison between “what should be happening” and “what is actually happening.” It is the gap between these two that drives improvement forward.
Like the pocket card in the last post, this is built on a foundation established by the work of Steven Spear, especially his PhD dissertation that is summarized in Decoding the DNA of the Toyota Production System. By the way, if you are in the business of continuous improvement, reading (and understanding) this breakthrough work is critical for you.
Other than generally sharing this, my other reason for putting this up is that in the Toyota Kata community there has been discussion for about a decade about whether or not the right hand loop – pushing for stability – is an appropriate use of the Improvement Kata.
I think that is an unfortunate result of some very early conversations about the difference between “troubleshooting” and “improving” a process. We get into semantic arguments about “problem solving” as somehow different from “root cause analysis” and how the Improvement Kata is somehow distinct, again, from those activities.
This makes no sense to me for a couple of reasons.
Scientific Thinking is the Foundation
Toyota Kata is not a problem solving tool. It is a teaching method for teaching scientific thinking, and it is a teaching method for learning to teach scientific thinking. In the books and most literature, it uses organizational processes as working examples for the “starter kata,” but exactly the same thinking structure works for such diverse things as working through quality issues, developing entirely new products and processes, working through leadership and people issues. The underlying sub-structures may change, but the basic steps are the same.
When I encounter an organization that already has a “standard problem solving approach” I do not attempt to tell them they are wrong or confuse them by introducing a different structure. Rather, I adapt the Improvement and Coaching Kata to align with their existing jargon and language, and help them learn to go deeper and more thoroughly into their existing process.
Stability is a Target Condition
I see a lot of pushback about working to “return a process to standard.” In reality, that is the bulk of the activity in day-to-day improvement. The whole point of having a standard in the first place is to be able to see when the actual process or result is somehow different.
Think about it: If there isn’t an active means of comparing “actual” vs. “standard” what is the point of having a standard in the first place?
Think of the standard as a target condtion.
What obstacles are preventing you from [operating to that standard]? You can guess, but the best way is to diligently try to operate to the target condition and see what gets in your way. That might not happen immediately. Maybe some time will go by, then BAM! You get a surprise.
This is good. You have learned. Something you didn’t expect has interfered with getting things done the way you wanted to. Time to dig in and learn what happened.
Maybe there was some condition that you could have detected earlier and gotten out in front of. Who knows?
You Cannot Meet a Challenge Without Working on Stability
As you are working to reach new level of performance – working toward a new challenge – there will be a point when the process works sometimes, so you know it is possible. But it doesn’t work every time because there are still intermittent obstacles that get in the way.
Nevertheless, you have to work diligently to see problems as they occur, respond to them, dig into causes (root cause analysis anyone?) and systematically protect your process from those issues.
The only real difference between covering this territory for the first time vs. trying to recover a previously stable process is that in the later case you can ask “What has changed?”
But, in the end, in both cases – stabilizing a new process vs. re-stabilizing an old one – you are dealing with conditions that are changing from one run to the next. That is why it works sometimes and not others. You don’t know what is changing. You are trying to figure it out by experimenting and learning.
What About Root Cause Analysis?
My challenge is still a stable process.
My current condition is my level of understanding of how the process works today, and the exact mechanism that results in a defect. Even defects are produced by a process – just not the process we want.
That understanding will be incomplete by definition – because if we truly understood what was going on we wouldn’t have the problem. So… what do I know (and can prove with evidence) and what do I not know.
What do I suspect? What evidence do I need to gather to rule out this possible cause, or keep it in play? Next experiment. What do I expect to learn?
I’ll write a more detailed post about this at some point. I think it is a topic worth digging into. Suffice it to say that I have absolutely used the Improvement Kata structure to coach people through finding the root cause of wicked quality problems.
It really helped that they were able to see the same underlying pattern that I had already been teaching them. It made things simpler.
Don’t Complicate a Simple Concept
It’s all “solving problems” (the term “problem solving” apparently has some specific form it needs to take for some people).
The underlying structure for all of it is scientific thinking. Some say it’s PDCA / PDSA. Same thing.
Splitting semantic hairs and saying “this is different” makes simple things complicated. Yes, there are advanced tools that you use when things get tough. But… addition and subtraction; basic algebra; advanced polynomials; basic differential calculus; advanced multivariate calculus – IT IS ALL MATH. You apply the math you must to model and solve the problem at hand.
DON’T apply more math than you need just because you can. That serves no purpose except, perhaps, to prove how smart you are… to nobody in particular.
Solving problems is the same. There are some cases where I need to develop a designed experiment to better understand the current condition – the interactions between variables. There are cases where other statistical tools are needed. Use them when you must, but not just because you can.
The default Starter Kata for “Grasp the Current Condition” places heavy emphasis on takt time and variation in timing of a regular process. However a lot of processes, both within manufacturing as well as in other domains such as health care, don’t seem to have any kind of regular heartbeat.
As Steve Medland pointed out at KataCon, this can present a struggle for a novice learner, as well as for a lot of coaches.
Before we get into ways to deal with this, I want to level set on what takt time is, and what it does for us.
Why Takt Time?
From an industrial engineering standpoint, takt time is an expression of how much capacity you need.
The traditional way to calculate takt time is to divide the total time available by the output required in that time. This gives us a “time per unit of output” that we have to achieve if we are going to get everything done. In other words, takt time is the required rate of production.
The whole goal of an ideal “Just-in-Time” system is that we have only the capacity required to meet the demand. If the system is even able to run faster than the takt time, we have excess capacity. Excess capacity = extra cost, and “overproduction” is a symptom of having excess capacity. Note that this is the “ideal” – it isn’t anything we can realistically achieve. The concept gives us a direction to strive toward.
Also Note: Determining how much capacity you need has absolutely nothing to do with how much capacity you have.
OK, that answered the question “What is takt time?” but not the question I posed: “Why takt time?” After all, I could just as easily say I need the capacity to product 96 units per day. But that doesn’t answer the question, “How fast do I need to go?” And that is what takt time gives us.
Think of it this way. If I need to make 96 units during the course of an 8 hour day, then I need to have made 48 units in four hours.
To make 48 units in four hours, I need to make 24 units in 2 hours. Which means 12 units in 1 hour. 6 units in 30 minutes. 3 units in 15 minutes. One unit every 5 minutes. And that is my takt time. (This is an oversimplification since I did not subtract break times to make the math easier to make the point.)
Thinking of it this way gives the people doing the work a quick way to know, very quickly, if they are ahead or behind. They can ask, “How long did this unit take?” and compare that with, “How long did we have?”
A Point of Comparison
Which brings us to the “Why.”
If I measure the time between units output at the end of the line, I can compare the actual time interval (the cycle time) with the required time interval (the takt time).
If we need to complete a unit every five minutes (takt time), AND
We know that our process can do that when there are NO problems, THEN
We can see very quickly if there IS a problem. We have to attack a source of variation and work on stability.
On the other hand,
If we need to complete a unit every five minutes (takt time), and
We know that our process is not capable of doing so even when running smoothly, then
We know we have to change the entire system to make rate.
Distinguishing between these two conditions is the main benefit of building a cycle time run chart (step 3 in the Starter Kata of Grasp the Current Condition.) That is a topic for another post, or just get a copy of the Toyota Kata Practice Guide ;).
The issue comes when people don’t see a steady rate of demand.
Sometimes they generally know how much time is in the day, but they see demand fluctuating all over the place.
This is true in manufacturing work as well as other cases, such as engineering work, software development, and a lot of cases in health care. The time to complete one “unit of work” varies, so it is hard to see any kind of cadence to the output even if the work is steady.
Key Question: Are you ahead or behind?
And how can you tell?
Regardless of all of the variation, though, we still want to know the answer to questions such as “Are we on track to get everything done today?” or “Has my load exceeded my capacity?” or “Is the backlog increasing, decreasing, or holding steady?” unless we are simply relying on luck. Asking and answering these questions is the purpose of many of the “lean tools” – including takt time.
When to Bring it Up
Everything above, though, is information for the coach to keep in mind. What a lot of us (myself included) do all too often is take beginners into advanced application way too fast. We forget what it is like to be overwhelmed with just getting through the day, and the limits that places on anyone for taking in new concepts.
I bring it up for the coach because I think the chances of the learner discovering it on their own are significantly lower (perhaps close to zero) if the coach is starting in the same place.
If you are getting pushback on the concept, it might be time to back off a bit and give your learner some space.
Steve Medland had a mini (5 minute) presentation at KataCon 2020 that briefly addressed some of his experience with this situation.
He pointed out that the default worksheet templates for Grasp the Current Condition and Establishing a Target Condition emphasize process timing and cadence pretty heavily.
From Steve Medlin’s KataCon presentationFrom Steve Medlin’s KataCon presentation
And the alternative is a blank template:
From Steve Medland’s KataCon presentation
Steve makes a good case that there ought to be something that provides a more general structure without removing all structure. I agree – as a coach, structure is one of the things you are bringing to the table. Any learner, at any level of expertise, is more deeply embroiled in the process itself than in the process of improving the process. Having some structure really helps.
The key is to adjust the structure to fit the situation.
From Steve Medland’s KataCon presentation
With beginners, the concept of takt time can be distracting, even paralyzing. Even more so if we use alien jargon like “takt time.”*
Using a hybrid structure like Steve proposes can get the learner moving into process analysis without getting wrapped up on terminology, or struggling with something she sincerely believes has nothing resembling a cadence.
Then, when the opportunity arises, the coach can still gently, but persistently, ask “How often does this need to be done?” and “How do we know if we are ahead or behind?”
Often the resistance is less about knowing there is some kind of schedule, and more about just being overwhelmed by all of the chaos that prevents any kind of stability.
Steve and I agree that timing is important. And I agree that it is important enough that it might be best to hold off on introducing it as a concept so we don’t create resistance unnecessarily.
But please don’t completely throw away measuring time just because it is hard. In fact, the harder it is, the more important it likely is. When it is easy to determine takt time, we likely already have an idea how long things are taking. The less appropriate takt time seems, the more critical it becomes to dig deep into where the time is going.
“Are you ahead or behind?” seems an innocent enough question.
But when asked by a Toyota advisor, the simple process of becoming able to answer it launched Liz McCartney and Jack Rosenburg on a journey of finding consistency in things that were “never the same” and stability in things that “always changed.”
Getting Homeis, first and foremost, a story. And, with the “business novel” being an almost worn-out genre, seeing a non-fiction story was refreshing. So when Chet Marchwinski from the LEI offered a review copy to me, I accepted.
For the story background, I’ll leave it to you to read the blurb on Amazon.* Better yet – read the book – and it is worth reading. I’ll say that right up front.
Yet with stories like this it is all too easy to dismiss them because they have different circumstances from “my” specific case and say “Yeah, it worked there, but won’t work here.”
I would contend, however, that in this case “it worked” in situations that are far more difficult than anything we are likely to encounter in most organizations.
What I want to do here is help pull their specific achievements into more general application – what lessons are here that anyone can take away and apply directly.
What They Achieved
I can’t think of a lot (any?) business circumstances that would have more built-in variability and sources of chaos than the process of rebuilding communities after a disaster such as a hurricane or flood.
Every client has different circumstances. The make, mix and skill levels of the volunteer workforce changes continuously. Every community has different bureaucratic processes – not to mention the various U.S. government agencies which can be, well, unpredictable in how and when they respond.
Yet they have to mobilize quickly, and build houses. This means securing funding, getting permits, mobilizing unskilled and skilled labor, and orchestrating everything to meet the specific needs of specific clients on a massive scale… fast.
How They Achieved It
When they first connected with their Toyota advisor, the simple question, “Are you ahead or behind?” prompted the response that drives all improvement, all scientific advancement, all innovation:
“We don’t actually know.”
Actually they did, kind of, but it was in very general, high-level terms.
And that is what I encounter everywhere. People have a sense of ahead or behind (usually behind), but they don’t have a firm grasp on the cause and effect relationship – what specific event triggered the first delay?
This little book drives home the cascading effect of ever deepening understanding that emerges from that vital shift from accepting things as they are to a mindset of incessant curiosity.
Being able to answer “Are you ahead or behind?” means you have to have a point of reference – what is supposed to happen, in what order, with what timing, with what result. If you don’t know those things, you can only get a general sense of “on track” or not.
They had to develop standards for training – what to train, how to train – volunteers! – , which meant challenging assumptions about what could, and could not, be “standardized.” (A lot more than you think.)
A standard, in turn, provides a point of reference – are we following it, or are we being pushed off it. That point of reference comes back to being able to know “Are we ahead or behind?”
It Isn’t About the Specific Tools
Yet it is. While it isn’t that important about whether this-or-that specific tool or approach is put into place, it is critical to understand what the tools you use are there to achieve.
As you read the book, look for some common underlying themes:
Information as a Social Lever
The project started revolving around the ahead/behind board.
In the “lean” world, we talk about “visual controls” a lot, and are generally fans of status boards on the wall. We see the same thing in agile project management (when it is done well).
These information radiators work to create conversations between people. If they aren’t creating those conversations, then they aren’t working. In Getting Home it was those conversations that resulted in challenging their assumptions.
Beyond Rote Implementation
Each tool surfaced more detail, which in turn, challenged the next level. This goes far beyond a checklist of tools to implement. Each technical change you make – each tool you try to put into place – is going to surface something that invites you to be curious.
It is the “Huh… what is happening here?” – the curiosity response – that actually makes continuous improvement happen. It isn’t the tools, it is the process of responding to what they reveal that is important.
Summary
Like the tools it describes, Getting Home is an invitation, and that is all, to think a little deeper than the surface telling of the story.
My challenge to you: If you choose to read this book (and I hope you do), go deeper. Parse it. Ask “What did they learn?” ask “What did this tool or question reveal to them, about them?” And then ask “What signals did they see that am I missing in my own organization?”
———-
*This is an affiliate link that give me a very small kickback if you happen to purchase the book – no cost to you.
The line is starting to flow, or at least there is more time flowing than not flowing. The places where it isn’t flowing well are now much more evident.
Things are speeding up. That is placing more stress on the engineering and materials supply processes where, before, they were shielded by a rough start-up that was always behind schedule.
They are catching up on the backlog, closing in on “on schedule shipment.”
“John” forgot to send a batch of parts to an outside processor. Before that would have been no big deal, it would be a day or so before those things were actually needed. But this time it briefly stopped the line and forced a work-around.
When everything was a work-around, nobody noticed. This time it got on the radar. It feels worse because the system is sensitive to smaller problems now, and there are plenty of those.
It isn’t “John’s” fault. He is flooded with a constant flow of things he needs to react to. There isn’t a structure for him to work within. That is the next opportunity.
Thus, it is critically important to remember a Toyota mantra:
‘No problem’ is a big problem.
If problems are not coming up, then your system is hiding them, plain and simple. You have stopped learning, stopped improving, stopped growing.
It is an easy groove to get into because we get all kinds of feel-good brain chemicals when things are going smoothly. We want more of those, less of the ones that call us to action.
But it is those “call to action” things that drive us to get better.
