Toyota Kata : the “how” of “engaged leadership”

Anyone who is following this blog knows my view of “engaged leadership.” As I read this book, I had two experiences.

  1. I found it validating. There were a lot of times I said “oh yeah!”
  2. I found it clarifying. Rother turns up the contrast on a couple of crucial points and I liked that.

This is not to say I don’t have a couple of quibbles, but I’ll get to those at the end.

The bottom line is that I am pushing this book, hard, internally in my company right now as a way to get a focused conversation going about what we mean when we say “engaged leadership.”

A Caveat

Before I get into this, I want to be clear about something. There have always been individuals and small groups out there that have had a deep, intimate understanding of how the Toyota Production System works and how to teach it. What I will be commenting on here is our community’s success at getting that deep understanding into the mainstream of thought. For example, “The Machine That Changed The World” revealed nothing new to anyone who had been teaching and practicing this stuff for a decade. What it did accomplish, however, was moving the discussion into the mainstream.

Thousands of people inside, and outside, of Toyota have been following some form of the practices Rother outlines for many decades. I have seen for myself the results of just trying to follow these practices. (The results from doing it badly are vastly superior to those gained from not trying.) Toyota Kata is an opportunity for at least a fundamental understanding of these practices to spread and hopefully generate a bit of a shift.

So, this review is not intended to say to anyone who has been successfully applying these skills that you didn’t know what you were doing. Quite the opposite. It is a validation of what you have been doing. The mainstream press is finally saying “ah-ha!” and understanding just how critical this is for sustaining and success.

Rother’s book describes a crucial piece that is simply not addressed well in any of the “lean industry” publications. That is the good news. The bad news is that it is going to be enormously difficult to get this piece into place in most companies. I’ll get into why later on.

History

The Toyota Production System was never designed. There are no specifications or blueprints. It grew, and continues to grow, organically. We learn about how it works by studying it. Therefore, our knowledge and understanding should be continuing to evolve and grow, as indeed, the TPS itself continues to evolve. Anyone who says “We get it now” has stopped learning.

In the early days we looked at the TPS through the eyes of engineers. We regarded it as a machine. If we could just see all of the parts and pieces, and understand how they work, we could reverse engineer the machine. That is where we get the emphasis on the tools, like one-piece-flow, pull, “looking for waste vs. value-add,” standard work and such.

In his doctoral research, however, Steven Spear took a different look. He went in with social science eyes rather than engineering eyes. His doctorial research findings have been cited as “potentially the most significant research ever to come out of the Harvard Business School.” Spear discovered the connections that make the mechanics into a living thing that engages people in improvement. His work is summarized in “Decoding the DNA of the Toyota Production System” published in 1999.

That was 11 years ago.

Unfortunately, in the meantime, other publications of the “lean industry” have continued to imply that “all you have to do is…” and describe sequences of using and implementing the tools. This has been at best misleading, and resulted in a graveyard of failed efforts to adopt the TPS.

Everybody, though, has been clear that “engaged leaders” are crucial for success. But up to this point, nobody has really said what the term “engaged leaders” means in terms of what they actually do. There have been hints – John Shook’s Managing to Learn does a great job describing the process of mentoring, but does not set the context as well as Rother does.

So my first key point is that I believe Toyota Kata is a significant contribution to the popular body of theory – it is the first book that really describes, in detail, the mechanics of “engaged leadership” in a continuous improvement environment.

Kata

The term kata is found mostly in the study of Asian martial arts. Kata are the basic motions, “wax on, wax off,” that are foundational building blocks. Once those foundations are embedded into subconscious memory, it is no longer necessary to focus on them. Though they are not called kata, the basic drills that any athlete learns are foundational in the same way.

Rother contends that Toyota’s improvement processes are build upon two fundamental kata.

  • A kata for improvement or problem solving.
  • A kata for coaching.

This does bring up my first quibble about the book. I wish it had a different title. While it is a great metaphor, I have found that the word “kata” is foreign to many people and I end up having to spell it and explain it as I tout the book. I ran into he same thing with Spear’s book Chasing the Rabbit – having to explain what the rabbit is and why we are chasing it – and note that his book has been re-issued with a title that better explains what the book is actually about.

Context

A “kata” is just a practice – in effect, yet another tool. There are lots of books and materials out there for problem solving methods, and John Shook’s Managing to Learn does a decent job describing the coaching process. So what is new here? In my opinion, Rother does the best job so far of setting the context – describing the improvement culture and environment if you will – of any popular press publication so far. It is this context that I find lacking in so many of the publications coming out of the “lean press.”

The book covers five interlocking topics.

  1. The role of vision and direction in continuous improvement.
  2. Critical context for the “classic lean tools” as target conditions.
  3. The problem solving kata, and how it differs from what most of us do.
  4. The coaching kata, really describing how management engages.
  5. A proposal for teaching the problem solving and coaching kata to a management team.

In addition, there is an overarching theme which compares this style of management with what is traditional taught and practiced in most business.

I would like to discuss these in detail, and offer my thoughts on each of them.

Vision and Direction

Maybe you’ve been there. “Top management” makes a “commitment” to “use lean principles” or some such. But nobody ever really defines what that means. The implementation is delegated to staff specialists, and it is up to them to provide “management education” and, ultimately, make the case for each and every improvement step.

I suppose there might be cases where this approach has worked and sustained. I just don’t know of any.

In the Toyota that Rother describes, there is an an overarching sense of direction, the true north that is used to unify the organization’s understanding of what “improvement” means.

Although Rother describes Toyota’s concept of being a perfect supplier much the same way that Spear does, (zero defects; 100% value added; one-by-one, in sequence, on demand; security for people) the concept comes through in other companies in other forms.

In “Made to Stick,” for example, Heath and Heath cite a story about Herb Kehler, then chairman of Southwest Airlines, as he describes how he uses a simple concept of the ideal to make decisions. In his case it is “We are the low-fare airline.” Thus, any “improvement” that does not consistently move Southwest in that direction is considered off track. (I should point out that “…without compromising safety or consistent performance in any way” are likely unspoken “givens” in this example.)

In The High Velocity Edge (formerly titled Chasing the Rabbit), Steven Spear points out several examples, including Toyota, where there is a strong explicit, or implicit, sense of an uncompromising direction. And Jim Collins’ book, Good to Great talks about defining what “we will be the best in the world at” as one of the key factors to sustainable breakout.

So, again, while this is not a new concept, Rother turns up the contrast and elevates it to a prominent position in decision making and direction setting.

Why is this important?

Because it focuses the debate away from “should we do it” to “what problems are in our way?” Rother gives a great example on page 50 and 51:

… we pointed out the potential for smaller batch sizes to the management team.  … closer to 1×1 flow, less inventory and waste, faster response to different customer requirements, less hidden defects and rework, kanban systems become workable and so on.

Almost immediately the assembly manager responded and said “We can’t do that,” and went on to explain why. [… the usual excuses here …] “Those extra non-value-added activities would be waste and would increase our cost. We know that lean means eliminate waste, so reducing the lot size is not a good idea.”

The plant manager concurred, and therein lies a significant difference from Toyota.

A Toyota plant manager would likely say something like this to the assembly manager.

You are correct that the extra paperwork and first-piece inspection requirements are obstacles to achieving smaller lot size. Thank you for pointing that out. However the fact that we want to reduce lot sizes is not optional nor open for discussion because it moves us closer to our vision of a one-by-one flow. Rather than losing time discussing whether or not we should reduce the lot size, please turn your attention to those two obstacles standing in the way of our progress.”

By clearly defining what “progress” is – outside of the scope of the daily debate – the debate is shifted away from whether or not there is a problem to a discussion on how best to solve it.  This, in my view, is one of the most important policy decisions a management team can make. It gives people a foundation of consistency. But for this to work, there must be no caveat such as “when it makes sense to do so.” Adding one provides an “out” that allows people to accept the status quo rather than focusing people’s attention in solving the problems so it does make sense.

Rother goes on to point out how this sense of direction re-shapes cost-benefit analysis. The question being answered is now not whether we will make this decision, but rather whether the solution is adequate, or we must keep looking for a better one.

Step by Step

A common source of confusion in organizations trying to adopt these principles is the tension between the theoretical ideal or vision (as defined above) and the “what we can do now.” This is made worse when there is no clear sense of the ideal vision or direction because it reduces each step to a choice of “do we take it?” rather than “what must we do to get there?”

What happens in that case is some people are talking about the vision, others dismiss it as “unrealistic” and a lot of energy gets expended because people think the vision is something that must be achieved with a single comprehensive plan..

In reality, though, no one has any idea what the clear path is. Trying to build a detailed plan to “implement lean” is destructive because there is no way to predict what problems will need to be solved until they are encountered. If you think about it a comprehensive project plan assumes that we have such a clear grasp of the current condition and already know what must be done to get us to the desired end state. In reality, we are driving on a winding road in the dark. We can only see as far as our headlights.

“We’ll just solve the problems before we discover them”

– Dilbert

Rother describes a series of target conditions as the true objectives of improvement.

Because there is a strong sense of direction, it makes sense to set an immediate target just beyond what we can achieve today. While there is no clear path to the notional end state, the target condition is much closer, so the immediate issues that must be overcome are plainly visible.

While this is somewhat understood in general principle, Rother takes it down a couple of layers. He points out that each of the common “tools and techniques of lean” are actually targets to strive for. Only by setting an objective, and then trying to hit it can we learn why we cannot. That, in turn, becomes the focus for kaizen.

The example that will most challenge a lot of practitioners out there is takt time as a target condition. This is one of the few mainstream books that gets beyond the overly-simplistic notion of takt time only as the rate of customer demand. Rother acknowledges that, internally, there is an intentional overspeed built into the system as a target. And here is the key point: You rarely hit the target. At least not at first. It is established as something to strive for, step by step, each day. The system is set up so people can both succeed in meeting the customer’s needs every day and have a challenge for the next level of performance.

From this foundation, Rother expands the concept across the other “tools of lean” – not as things you implement, but devices to focus your attention on the next problem. The common excuses and obstacles we are used to hearing are turned around into those challenges. The work cycle is too unbalanced to achieve one-by-one flow? OK – then that is the focus or our kaizen activity until we break down that problem. The kanban discipline broke down? Great! What didn’t we understand when we set it up?

In each case the questions are:

Can we run this way? (smooth, level pulls; one-by-one; cycle time = takt time; etc)

If no, then “What is preventing us… now… from doing so?” Crutch the system while you work on the problem, but work on the problem. Rather than using the problem as a barrier, it become the next challenge.

Rother goes into quite a bit of detail for each of the common tools, and resets the commonly held idea that they are something to implement. I am glad for this chapter because it clarifies (or contradicts?) the idea that these tools are “what makes a value stream lean.” That idea has been firmly entrenched by the middle chapter of Rother and Shook’s book Learning to See which, in turn, is the cornerstone of the LEI’s publications and doctrine. We are finally starting to move beyond that anchor and understand that these tools are not the fundamentals of lean.

The entire concept of a target condition, that describes not simply the performance but the operating characteristics of the system, is a critical one. The vision of ideal sets the general direction for forward progress, the target condition issues a clear done-or-not-done challenge for the next step.

This concept links back to Learning to See in that the “future state map” can define an overall target condition rather than some long-term end state. Perhaps that was the intention all along. But Learning to See and its publishers are vague about that, and many companies have tried to reach too far into the ideal with their future state with the idea that it describes an end game rather than the next challenge.

Kata 1: Problem Solving

Of course if the target could be achieved today, it is a poorly set target. There are likely problems to solve.

Where we commonly fall short in problem solving is trying to take on too much at once. We try to take on complex problems, create elaborate dependencies, and work on multiple things at the same time. As a result, we never really gain a clear understanding of what worked (or didn’t) or why because we are manipulating all of the variables at once.

Unfortunately most “problem solving” courses teach us to do it just this way.

Rother, on the other hand, points out that rapid, linear solution of small problems, focusing on single issues and single countermeasures, lets us gain that process understanding – and increase our profound knowledge in the process.

A really telling chart on the crucial difference between a problem solving culture and a problem avoiding culture is in the section titled What Toyota Emphasizes in Problem Solving.

 

Toyota “Us”
Focus Learn about the work system.Understand the situation. Stop the problem!
Typical Behavior Observe and study the situation.Apply only one countermeasure at a time in order to see cause and effect. Hide the problem.Quickly move into countermeasures. 

Apply several countermeasures at once.

This little chart covers a lot of ground. Where “we” are primarily interested in eliminating the effects of the problem so we can move on to something else, the Toyota approach, according to Rother, is to learn and understand more about the process. So while solving the problem is the goal, it is only acceptable to solve it in a way that improves understanding. A blind solution is no solution.

Logically, of course, this makes sense. But in real life it is extraordinarily difficult in the heat of the moment, with people demanding a quick fix, to exercise this kind of discipline. This is driven by a fear that thorough = slow, which is simply not true.

And as each countermeasure is applied, the next problem becomes apparent – and that problem is the next barrier to better performance. Progress can be made very quickly in this way because there is a much reduced risk of leaving problems behind us as we move forward.

In contrast, I find two main issues with most “problem solving” approaches.

First, they spend an inordinate amount of time deciding which problem to work on. While that may feel like working on solving problems, no actual progress is being made. The countermeasure for this waste is to have a clear sense of direction, and a clear target objective that makes “which problem to work on” painfully clear – it is the obstacle between the current state and where you want to go.

Second, and perhaps worse, is that we like to think we are working on “important” problems, which seems to mean difficult ones. Maybe this is because if feels like a waste of time to work on the simple issues. “Problem solving” is often taught as a complex, drawn out process (which often begins with deciding which problem to solve…). We learn about designed experiments, statistical analysis, stratification techniques. Some problems require this kind of work, but not very many. Worse, learning to solve those problems well requires a thorough grounding in the fundamental logic which is best learned by solving lots of problems.

The only way to solve lots of problems is to start with the simple ones, but apply rigorous methods in doing so. But we skip that part, and then wonder why “problem solving” doesn’t take hold. We are trying to teach multivariate calculus before we learn algebra.

Toyota avoids this issue because they develop these skills from the basics, at the very start of their employment. Teaching the fundamentals – the entry level stuff – to senior people with advanced career positions can be problematic. More about that later.

Kata 2: Developing People (Coaching)

Even in the rare organizations that have fantastic problem solving and kaizen skills, the development of people often a very weak process. There is no systematic approach to doing it.

Let me be specific about this, just to be clear.

Most companies have some kind of “performance management” system that is built around some form of “management by objectives.” The team member is supposed to develop a set of goals with his boss. Those goals may even include “developmental goals.” They might even be specific things like taking a class or performing an assignment. Then, at the end of the rating period, the team member is evaluated on his performance against those goals.

This is not developing people. Not by a long shot.

“Coaching” is often a euphemism for the boss telling the team member that something in his behavior or performance is seriously inadequate. It is the first step in the “steps of accountability” which, in itself, is a euphemism for escalating punitive actions on a path to termination for cause.

This is not coaching. Not by a long shot.

And both of these functions are usually delegated to Human Resources rather than being clearly owned and adminstered by line leaders.

Rother, on the other hand, describes a process of mentoring. The boss has skin in the game because he is accountable to his boss for the results. Yet he does not direct solutions. He guides the subordinate through the process of solving the problem in the correct way. In fact, upon study, it becomes clear that the process of coaching (the “coaching kata”) is simply an instance of the problem solving kata. There is a target condition for the team member’s capability. The current condition is understood, gaps are assessed, and at each step of the way, countermeasures are applied in the form of direction that will build the team member’s problem solving skills. In the end, it is the team member, not the boss, who comes up with the solution, and the boss has to live with whatever it is as long as it works.

What is critical to understand here is a difference in who carries out improvements. In most of our companies, improvements are the domain of skilled staff specialists. These are the people who plan and lead kaizen events, or carry out black belt projects, or whatever improvement process is used. Those people are probably quite good at what they do, but they are the only ones who do it. The attention is always on solving the problem. Yes, they go through the motions of developing people – they teach them the principles, they guide them to the correct solution, but in the end, the process of how to improve is the domain of the specialists.

This is, in reality, a very traditional approach – a slight evolution from the practices outlined by Fredrick Taylor in 1911. Yes, they do a better job of “engaging the workers” vs. just telling them what to do, but when that engagement is limited to specially planned events, we are really not developing anyone, nor are we truly engaging them.

In a Toyota Kata type environment, most improvements are led by lower level line leaders, and they do so in way that is designed to develop people’s depth of knowledge. Yes there are staff specialists, but they are pulled in when a problem requires technical help rather than being pushed in to “fix things.”

The other key point is that in the Toyota-type environment, the entire operation is built around flagging problems immediately. Spear describes how work, information flows, material flows, and indeed the flow of problem solving itself is deliberately structured to always be testing against an explicit intent.

In this environment, the vast majority of problems are discovered and handled while they are relatively small and manageable. In contrast, “traditional” organizations deal with problems only when they can no longer be tolerated. Where Toyota deliberately stops the process at the first hint of trouble, other organizations run it until it is so overwhelmed that it is brought to its knees.

Following that, in the Toyota-environment, someone other than the production operator responds to the problem. This, again, is a huge contrast. But if you think about it, the only thing the production worker can do is work around the problem enough to keep moving. He doesn’t have time to solve it and continue production. So when we say “We want out workers to see problems and solve them” that may be well intentioned, but it isn’t going to happen without the rest of the structure in place.

What this means is that there is no such thing as an entirely autonomous worker, nor can there be a “self directed team” that operates completely independently. Trying to do so is leaving people on their own, without support from the rest of the organization. That doesn’t mean we micro manage, but it does mean that there is a clear delineation between “normal” and “abnormal” and, further, “abnormal” demands that someone gets notified right away, and responds in a specified, standard way.

The role of leaders in this world is two fold.

  1. Respond immediately at the first hint of a problem. Take ownership of the issue. Get the problem cleared – that is, establish a temporary countermeasure which allows safe, defect-free production to resume.
  2. The problem has revealed something that was not previously understood about the process. Work together with the people in the trenches to develop that understanding and guide them through the process of implementing a workable solution.

The coaching kata is how this is done.

In the end, not only is the problem fixed, but the profound knowledge of the entire organization has improved.

A couple of things that make this different.

The initial temporary countermeasure will likely “bust the system.” By that I mean it takes things away from the ideal. But that happens all of the time, everywhere, doesn’t it? True, but what happens next is critical. The leader is responsible for the issue until the system is not only restored, but improved. Where “the rest of us” willingly accept that we have to compromise and make things a little less than ideal to get the product out the door, the Toyota Kata mindset accepts this only as a scaffold to hold up the process until it can be repaired… and strengthened so it won’t break again. With one mindset, things get a little worse. With the other, they get better. “Chatter is signal.”

Rother describes this process with a few stories and examples that make the point very well. So does John Shook in Managing to Learn.

Adopting the Kata

One thing I like about this book over many others is that Rother goes beyond just describing an ideal environment. In Chapter 9 Developing Improvement Kata Behavior in Your Organization he openly discusses the very real barriers that an organization must surmount to get this thinking and practice into place.

He says the challenge is:

“Not to implement or add on some new techniques, practices or even principles”

rather it is

“To develop consistent behavior patterns across the organization.”

He is, of course, talking about a fundamental change in culture. Let’s talk about that a bit. “Culture” is really defined, not so much by the behavior of individuals, but rather, it is something that emerges from the norms and rituals people follow when they interact with one another. This is true of a national or ethnic culture as much as a corporate culture.

The coaching kata describes a specific way that people interact with one another when solving a problem. It is not individual behavior – what we commonly teach in “problem solving” – it is group behavior. Therefore, this is not something that can be taught to individuals.

Rother is clear about a couple of things. First is that nobody has succeeded in doing this as well as Toyota yet. We are cutting new ground here. There is no clear path to the end state. There is a clear vision for what the end state looks like, and each of us should know (or be able to assess) the current state in our individual organizations. If this sounds familiar, it is. Rother is describing a process of using the very principles discussed in the book to put these patterns into place. Why? Because when the practices are applied correctly, they work. If they don’t work, we must look at the quality of our application, not the validity of the approach. “If the student hadn’t learned, the teacher hasn’t taught.”

He is equally clear in a section titled What will not work.

  • Classroom training does not work any better here than it would to teach you to swim or ride a bicycle.
  • “Workshops” do not work – especially if they are focused on making improvements vs. developing behaviors. I’ll talk more about that in the next post.
  • Hiring consultants to lead improvements for you, does not work.
  • Using metrics to alter people’s behavior. Management by measurement does not work.
  • Reorganizing, “re-engineering,” whatever you call altering the lines on the org chart, does not work.

What does work?

Continuous and conscious practice with the oversight of a coach. Every world-class athlete in the world has a coach. Only the coach can observe her performance objectively and see what must be adjusted to improve it. I always wonder why it is that, in business or operations, we believe that once some level is reached there is no need for this.

In this section Rother outlines what seems to be a pretty good plan for applying the improvement kata to the problem of developing the organization’s skills.

A couple of keys.

  • Learn to do before learning to coach.

While this makes sense when we write it, again, in business organizations it seems that people’s capabilities to do something they have never done before are not questioned once they reach some level of seniority. This is, of course, silly. Rother proposes to start at the top with the basics – not because they end up as the primary coaches. No, that is primarily the domain of the middle managers and below. But because someone has to coach those middle managers, and it has to come from above. Rother’s point is around classic change management. I would add that starting in the middle puts those people in an untenable position because they are being taught to behave in ways that their bosses do not understand. Getting the top level team not only involved, but embedded, in the process is a countermeasure.

I am not going to go into a lot of detail and spoil the book. Get it and read it. Form your own view on this. Just understand that getting this thinking into place is a big deal.

Final Thoughts

This book is a good one, but I want to add a little reality here.

Like every book before it, Toyota Kata is targeted primarily at senior leaders. I would like to say that it will take off like The Goal or The Machine that Changed the World. It is probably too early to tell, but I don’t see it happening yet. Like most books of these books, its primary readers are going to be technical practitioners.

Those technical practitioners are the ones leading the classroom training, leading the kaizen workshops or black belt projects. They are the ones who are doing most of the things that do not work. They are doing those things because that is what their bosses expect (or allow) them to do since, rightly or wrongly, “improvement” is largely delegated to them.

Odds are you are one of those people if you are reading this blog, and odds are you are the only one who will be reading this book. It is a great book, but you will find it frustrating because you bosses aren’t reading it.

Here is what you can do.

First, practice this stuff on your own. Coach each other. It will feel awkward. Get as good at this as you can.

Then start altering how you run your events. Shift them to changing the behavior of team leaders and supervisors. Teach them to see, clear, and solve problems quickly. Set more clear target objectives. Hold yourself to a higher bar. At the end of an event, where you have traditionally focused on clearing newspaper action items, focus instead on ensuring that this behavior is embedded. Coach and support those front line leaders until they are habitually employing the kata every single day. That is the only way your results will sustain. Then, and only then, move to the next “event.” Your objective is not so much to make change in the way things flow as it is to systematically transfer this behavior to those critical first two or three levels in the organization.

Then comes the hard part.

The leadership above is going to say and do things that introduce problems. You have to intervene, but use it as a coaching opportunity. Apply the kata, just like you would for any other issue. Now, though, you are coaching those leaders – gently – through the process of understanding what is really happening, what they truly want to achieve, and understanding what is truly in their way. Maybe, just maybe a few of them will listen.

And maybe you can lead them through a study of this book so they can begin to understand what you are doing.

Just to be clear, Rother says that everything I have just said is the wrong way to go about this. It has to start from the top. Perhaps he is right. But sometimes you do what you can, where you can.

In the end, these concepts have to overcome huge momentum. Our business leaders today are firmly entrenched in a management paradigm that was developed, ironically, in General Motors. It is taught by every major business school in the world. Now we are beginning to see that there is a better way. But the better way is very different from anything they understand, and it is a lot of work. Its focus on developing people, first and foremost, runs counter to the paradigm of an objective, numbers-based analytical “business decision.” Ironically Toyota’s approach is based in far deeper understanding of objective facts than the financial-decision paradigm, but it does not feel that way when you are doing it.

Thus – this is a great book. Read it. Do what it says. But it isn’t going to move the Earth for us. There is still a lot of work we have to do ourselves.

I welcome your thoughts and comments.

Takt Time Is Local

There was an interesting search in my logs today.

[does a system have a single takt time or multiple]

I always figure that if one person is looking, others are also curious, so let’s address it and maybe there will be a better search result for the next Googlenaut out there.

Takt time is local.

It is calculated based on the demand from your customer.

This is a critically important concept because for takt time to be of any use, it has to be relevant to the people who are actually doing the work.

Example 1:

A factory has four final assembly lines that feed into shipping.

There are 420 minutes of working time in the day, and total aggregated leveled output is 350 units of production.

What is the takt time?

For shipping, it is straight forward. The customer takt time is:

420 minutes / 350 units shipped = 72 seconds

So for shipping to stay on task, their process must be capable of packing and loading one unit every 72 seconds. If they can’t consistently achieve that, they are falling behind.

What about the assembly lines?

You don’t know, because you don’t know what each of them is expected to produce. You could say that the factory takt is 72 seconds, but that does not pass the “so what?” test for the people working on those lines. But if you know that:

  • Line A’s leveled production is 75 units
  • Line B’s leveled production is 50 units
  • Line C’s leveled production is 100 units
  • Line D’s leveled production is 125 units

then you can determine a meaningful takt time for each of those lines.

  • Line A: 336 seconds
  • Line B: 504 seconds
  • Line C: 252 seconds
  • Lind D: 201 seconds

In reality, I am going to run these lines a little faster, but that is a different topic entirely.

Now we have a takt time that actually matters. It reflects the work cycle that must be achieved for that line to meet its obligation to its customers.

Example 2:

Upstream there are fabrication or other feeder processes. We have not yet gotten them into directly linked flow.

Process E feeds one part to each unit produced on Line B; and one part on every FIFTH unit on Line C. What is the takt time?

Line B needs 50 parts. Line C needs (100 / 5 =) 20 parts for a total of 70 units of output.

So Process I has a takt time of (420 minutes / 70 units of output =) 360 seconds.

Value stream mapping is very useful for untangling this. Hopefully you can also start to see one of the reasons we work so hard to level volume and mix.

This isn’t complex stuff, but on the other hand, if you oversimplify it then it becomes meaningless. Remember, this is not about OUTPUT, it is about testing whether your process has succeeded each and every time it is carried out. You can only do that if you know what is expected right then and there.

Go to your shop floor. Watch the work. Can you tell, with each unit of output, whether the team member was successful that time? (More precisely, can you tell whether you were successful in giving that team member what she needed to succeed!). If you can’t tell, I guarantee that the people doing the work have no idea, which means you are leaving them to guess. Not a good thing.

Home Appliance Utilization

Bob Hanover has a great little article about applying visual controls to household laundry on his “Thoughtput Solutions” site. (cute way to use TPS as the name for the company, too.)

The concept he outlines is the same one that is (or should be) used to trigger batch run points for kanban managed machines.

But I want to talk about machine utilization, especially of home appliances.

A modern home washing machine can cost anywhere from a few hundred dollars to over a thousand, depending on the make, model and features.

In a household like Bob’s, with two adults and seven kids, it makes sense to ensure this expensive machine is running to full capacity.

To keep the machine running, as each load is complete, the next one should be started, otherwise the machine will sit idle, and that would be bad… right?

Let’s do some math.

Typically a home washing machine completes its automatic cycle in just around half an hour.

Typically a home dryer completes its automatic cycle in around 45-50 minutes.

So, if you want avoid having the washer stand idle, what are you doing to do?

I’ll tell you what nobody does. Nobody keeps putting loads into the washer and piling up wet clothes to wait for the dryer. It is obvious that the dryer is pacing the process, and running loads through the washer faster than the dryer can take them would defy common sense. Wouldn’t it?

Yet we do this all of the time in factories.

Why?

Toyota Kata: Avoid Pareto Paralysis

A great key point comes out on page 124 of Toyota Kata by Mike Rother.

…a Toyota person once told me to focus on the biggest problem. However, when I tried to do this I noticed a negative effect: We got lost in hunting for and discussing what was the biggest problem. When we tried gathering data and making Pareto charts, it took a lot of time and the biggest problem in the Pareto chart was usually “other” which put us back into debating options. By the time we decided what the biggest problem was, the situation at the process had changed. This effect is called Pareto paralysis, and I encourage you to avoid it. Pareto paralysis delays your progress as people try to determine the “right” first step to take.

[…] it matters more that you take the first step than what the first step is.

I have seen this many times with my own eyes. It is a common problem when “problem solving” is taught as “application of the seven tools” and “correct” use of the tools becomes more important than understanding the problem or making actual progress.

Hirano, I believe, has been quoted as saying:

Waste often comes disguised as useful work.

That is what is happening here. The team thinks they are working to solve the problem when, in reality, they are still trying to decide what problem to work on. The gridlock may be driven by fear of working on the wrong problem. But in reality, there is no wrong problem, there is only the one that is in your way.

Here is something else I commonly see. When they discover “problem solving” many organizations want to immediately undertake large projects that involve “stretch goals” and breaking down complex issues. They look at operational metrics that are actually aggregated – total inventory, total lead time, productivity of the entire factory, total defect rates, total lead time through the system. While those metrics are nice to gage progress, they do not give you any actionable information.

Even worse is using averages. Averages aggregate even more, and “bad” tends to be countered by “good” in many average calculations. What is important is to look at each instance vs. an external, discrete, and objective standard or specification. Average defect rates tell you nothing at all about what to work on. But this unit had this defect, or this part dimension was this amount out of specification DOES.

Put another way, there are very few big problems. Big “problems” are the aggregated symptoms of many small problems.

This is good news and bad news.

The good news is that small problems can usually be understood, cleared and sometimes solved fairly quickly. The bad news is that it takes work to do this. The other bad news is that there isn’t any other way that actually works.

Doing a good job working on large complex issues requires engaging across the organization, time, and a high level of skill at understanding the situation, framing the problem, getting to causes, working on solutions, testing understanding, etc. Doing it well requires a mentor who is intimately familiar with the thinking behind problem solving.

This skill can not be gained in a “problem solving” or “A3” class, at least not one that simply walks the team members through the process once or twice. Skill comes from practice, and effective practice comes from starting simple, working in an environment where it is safe to experiment and to be wrong. This means working on shop floor issues that can be isolated from one another, the effect of a test or simulation can be seen immediately. The factory and production organization that Steven Spear describes in his research about Toyota is actually designed deliberately to facilitate this kind of work.

Another common mistake is setting up performance targets too early. If the processes are inherently unstable – if there is no sense of takt time, you are having problems with consistent quality or delivery, the first goal is simply to get to the point where you actually know how things are performing against an indicator of stability. Again, this is usually much simpler than setting a high level target and then trying to break down and stratify all of the issues out there. Set that stability target, study the process, and take on the disruptions as you see them. If there is a debate about which one to start with, then start with the simplest one so you can improve your capabilities.

In the end, it is about taking on problems as they come up, where they come up. That thinking is facilitated by the way you structure the flow, the work, and the organization itself. Get to the shop floor, stand in the chalk circle, and ask “What is stopping this team member from being successful right now.”

What Follows “Yes, but…”

I am in the process of (finally!) reading Mike Rother’s great book Toyota Kata. The book has already gotten great reviews out there, and I am not going to contribute a lot more to that dialog except to say I think it is the first substantial addition to community knowledge about TPS since Steven Spear published his dissertation in 1999.

As I go, I am taking notes of thoughts that are provoked, and I will share a few of them as they come up.

Early in the book, Rother makes a clear distinction between managerial systems that try to cost justify each and every activity, and those which have their focus on an ideal future state.

He cites a number of examples of how the dialog in these companies is shaped by this vision, or lack of it. This is one:

Almost immediately the assembly manager responded and said, “We can’t do that,” and went on to explain why. “Our cable product is a component of an automobile safety system and because of that each time we change over to assembling a different cable we have to fill out lot traceability paperwork. We also have to take to the quality department the first new piece produced and delay production until the quality department gives us an approval. If we were to reduce the assembly lot size from five days to one day we would increase that paperwork and those production delays by a factor of five. Those extra none-value added activities would be waste and would increase our cost. We know that lean means eliminate waste, so reducing the lot size is not a good idea.”

The plant manager concurred, and therein lies a significant difference from Toyota. A Toyota plant manager would likely say something like this to the assembly manager: “You are correct that the extra paperwork and first-piece inspection requirements are obstacles to achieving smaller lot size. Thank you for pointing that out. However, the fact that we want to reduce lot sizes is not optional nor open for discussion, because it moves us closer to our vision of one-by-one flow. Rather than losing time discussing whether or not we should reduce the lot size, please turn your attention to those two obstacles standing in the way of our progress. Please go observe the current paperwork and inspection process and report back what you learn. After that I will ask you to make a proposal for how we can move to a one day lot size without increasing our cost.” [emphasis added]

To this hypothetical Toyota manager, the ideal state is achieving one-by-one flow, on demand, in sequence, as requested, without waste. He sees the drive toward this ideal state as the method to drive the next problems to the surface which, when solved, will remove a round of waste from the process.

There are a number of key points to take away from this.

Avoiding waste vs. removing waste. The assembly manager is confusing the avoidance of wasteful activity from removing wasteful activity from the process. The large lot sizes are avoiding wasteful activity, but it is still there, lurking under the surface as a barrier to further improvement.

One-by-one flow as a crucial goal. In this example, the concept of one-by-one (or one piece) flow worked exactly as it should. The discussion, or attempt, to implement the next step in that direction revealed the next barrier that must be addressed on the way. Without the imperative to reduce lot size toward that ideal, these reasons, justifications, barriers, excuses prevail and the wasteful activity remains. Yes, its effect can be mitigated by larger batches, but applying that logic, why not make the batches even larger?

It isn’t about what waste you can remove. It is about what wastes must be removed to achieve the next target condition. Having this sense of the ideal to define the direction of progress focuses the team on removing the next barrier to higher performance. This keeps things on a path toward higher system performance. Contrast this to the classic “drive by kaizen” approach where we go on waste safari and then look for opportunities where waste we can remove the most easily. This results in a patchwork of improvements that rarely find their way to the bottom line.

Cost justification would say leave the waste there. The cost justification for reducing lot sizes comes primarily from the reduction of inventory holding costs. Unfortunately, unless the inventory is insanely expensive (like jet engines), that alone rarely justifies the effort. But this thinking also stops any further opportunities for improvement in their tracks.

On the other hand, if the goal is to drive toward the ideal of one-by-one in a way that does not increase cost, then once this single-day lot size is achieved, they would be asking “What will it take to get to half a day?” Eventually they will be asking about every part every day. And then true mixed one-item-flow.

At each juncture an important thing happens. They must confront the next problem, and the next waste in the system. They must find a way to remove that wasteful activity without increasing cost. Eventually they will be making one cable each takt time, and following that, making the cables and installing them immediately.

To get there all of the inspections and traceability paperwork requirements will either be removed as no longer necessary or will be built in to the process itself. How will that be done? I don’t know. Nobody knows. That is the point. We can’t solve all of the problems ahead of time, nor can we solve them before they are discovered. The path to the ideal state is vague and unknowable when you begin. It is revealed step by step, as you take those steps.

The key is to have faith that, among all of the people in your operation, someone will find a way to crack that next problem.

This is how you harness people’s creativity.

In his classic JIT Implementation Handbook, Hirano says to force one piece flow to reveal the waste in the system. That was in 1988. Rother introduces the critical human element into the equation. One piece flow is not an abstract concept, it is a critical guide for management decision making.

Rother goes on to make other examples. In each case, the tool or technique – such as takt time or leveling – specifies how we want things to work. That provides a baseline for comparison so we can see the problems we need to work on next.

Here is another example. Ironically, while Rother uses it in his book, I have experienced it in real life. The factory is trying to introduce leveling. They set up a stock of finished goods. They set up a kanban leveling box, and they set up a fairly well thought out process of leveling the demand on the production stock, allowing the inventory to absorb the ups and downs. Their rule is that if the inventory hits a high or low limit, they will take action and assess what is happening.

Then the email arrives – “A big order arrived, and flushed out our inventory, we had to catch up, what do we do?”

After doing what is necessary to recover the system, this was a great opportunity to look at why orders arrive in big batches. In this case, I suspect it was an artifact of the company’s distribution network. The plant is at a critical crossroads.

Each of these examples leads me to the same thought.

The “Yes, but…” and the “Now what?” situations are going to happen. They prove the system is working to surface the next problem to be worked on. The reply that follows decides the fate of your improvement process.

You can reply the way the Toyota manager did in Rother’s example, and work hard to improve your process.

Or you can buy the Basic Story that is presented, and in effect agree that no further improvement is possible on this process, or that “lean doesn’t work for us because [put your “unique situation” here]”.

Which do you do?

Takt Time – Cycle Time

There has been an interesting discussion thread on “Kaizen (Continuous Improvement) Experts” group on LinkedIn over the last few weeks on the differences between takt time and cycle time.

This is one of the fundamentals I’d have thought was well understood out there, along with some nuances, but I was quite surprised by the number (and “quality”) of misconceptions posted by people with “lean” and “Sigma” in their job titles.

I see two fundamental sources of confusion, and I would like to clarify each here.

“Cycle Time” has multiple definitions.

“Cycle time” can mean the total elapsed time between when a customer places an order and when he receives it. This definition can be used externally, or with internal customers. This definition actually pre-dates most of the English publications about the Toyota Production System.

It can also express the dock-to-dock flow time of the entire process, or some other linear segment of the flow. The value stream mapping in Learning to See calls this “production lead time” but some people call the same thing “cycle time.”

In early publications about the TPS, such as Suzaki’s New Manufacturing Challange and Hirano’s JIT Implementation Manual, the term “cycle time” is used to represent what, today, we call “takt time.” Just to confuse things more, “cycle time” is also used to represent the actual work cycle which may, or may not, be balanced to the takt time.

We also have machine cycle time, which is the start-to-start time of a machine and is used to balance to a manual work cycle and, in conjunction with the batch size,  is a measure of its theoretical capacity.

“Cycle time” is used to express the total manual work involved in a process, or part of a process.

And, of course, “cycle time” is used to express the work cycle of a single person, not including end-of-cycle wait time.

None of these definitions is wrong. The source of confusion is when the users have not first been clear on their context. Therefore, it is critically important to establish context when you are talking. Adjectives like “operator cycle time” help. But the main thing is to be conscious that this can be a major source of confusion until you are certain you and the other person are on the same wavelength.

Takt time is often over simplified.

The classic calculation for takt time is:

Available Minutes for Production / Required Units of Production = Takt Time

This is exactly right. But people tend to get wrapped up around what constitutes “available time.” The “pure” definition is usually to take the total shift time(s) and subtract breaks, meetings, and other administrative non-working time. Nobody ever has a problem with this. (Maybe because that is the way Shingijutsu teaches it, and people tend to accept what Shingijutsu says at face value.)

So let’s review and example of what we have really done here. For the sake of a simple discussion, let’s assume a single 8 hour shift on a 5 day work week. There is a 1/2 hour unpaid lunch break in the middle of the day, so the workers are actually in the plant “at work” for 8 1/2 hours. (this is typical in the USA, if you are in another country, it might be different for you)

So we start with 8 hours:

8 hours x 60 minutes = 480 total minutes

But there is a 10 minute start-up process in the morning, two 10 minute breaks during the day, and 15 minutes shut-down and clean up at the end of the shift for a total of 45 minutes. This time is not production time, so it is subtracted from “available minutes”:

480 – 45 = 435

A very common mistake at this point would be to subtract the 30 minute lunch break. But notice that we did not include that time to start with. Subtracting it again would count it twice.

So when determining takt time, we would use 435 minutes as the baseline. If  leveled customer demand was 50 units / day, then the takt time would be:

435 available minutes / 50 required units of production = 8.7 minutes (or 522 seconds)

Note that you can just as easily do this for a week, rather than a day.

435 minutes x 5 days = 2175 total available minutes

2175 available minutes / 250 required units of production still equals 8.7 minutes (or 522 seconds)

All of this is very basic stuff, and I would get few arguments up to this point, so why did I go through it?

Because if you were to run this factory at a 522 second takt time, you will come up short of your production targets. You will have to work overtime to make up the difference, or simply choose not to make it up.

Why? Because there are always problems, and problems disrupt production. Those disruptions come at the expense of the 435 minutes, and you end up with less production time than you calculated.

Then there is the fact that the plant manager called an all-hands safety meeting on Thursday. That pulled 30 minutes out of your production time. Almost four units of production lost there.

I could go on with a myriad of examples gathered from real production floors, but you get the idea.

Here is what is even worse, though.

When are you going to work on improvements?

If you expect operators to do their daily machine checks, when do you expect that to happen?

Do you truly expect your team members to “stop the line” when there is a problem?

All of these things take time away from production.

The consequence is that the shop floor leadership – the ones who have to deal with the consequences of disrupted production – will look at takt time as a nice theory, or a way to express a quota, but on a minute-by-minute level, it is pretty useless for actually pacing production.

All because it was oversimplified.

If you expect people to do something other than produce all day, you have to give them time to do it.

Let’s get back to the fundamental purpose of takt time and then see what makes sense.

The Purpose of Takt Time

Here is some heresy: Running to takt time is wholly unnecessary. Many factories operate just fine without even knowing what it is.

What those factories lose, however, is a fine-grained sense of how things are going minute by minute. Truthfully, if they have another way to immediately see disruptions, act to clear them, followed by solving the underlying problem then they are as “lean” as anyone. So here is the second heresy: You don’t NEED takt time to “be lean.”

What you need is some way to determine the minimum resource necessary to get the job done (JIT), and a way to continuously compare what is actually happening vs. what should be happening, and then a process to immediately act on any difference (jidoka). This is what makes “lean” happen.

Takt time is just a tool for doing this. It is, however, a very effective tool. It is so effective, in fact, that it is largely considered a necessary fundamental. Honestly, in day to day conversation, that is how I look at it. I made the above statements to get you to think outside the mantras for a minute.

What is takt time, really?

Takt time is an expression of your customer demand normalized and leveled over the time you choose to produce. It is not, and never has been, a pure customer demand signal. Customers do not order the same quantity every day. They do not stop ordering during your breaks, or when your shift is over. What takt time does, however, is make customer demand appear level across your working day.

This has several benefits.

First, is it makes capacity calculations really easy through a complex flow. You can easily determine what each and every process must be capable of. You can determine the necessary speeds of machines and other capital equipment. You determine minimum batch sizes when there are changeovers involved. You can look at any process and quickly determine the optimum number of people required to make it work, plus see opportunities where a little bit of kaizen will make a big difference in productivity.

More importantly, though, takt time gives your team members a way to know exactly what “success” looks like for each and every unit of production. (assuming you give them a way to compare every work cycle against the takt time – you do that, don’t you?)

This gives your team members the ability to let you know immediately if something is threatening required output. Put another way, it gives your entire team the ability to see quickly spot problems and respond to them before little issues accumulate into working on Saturday.

The key point here is that to get the benefit, you have to have a takt time that actually paces production. It has to be real, tangible, and practically applied on the shop floor. Otherwise it is just an abstract, theoretical number.

This means holding back “available time” for various planned (and unplanned) events where production would be stopped.

Further, in a complex flow, there may be local takt times – for example, a process that feeds more than one main line is going to be running to the aggregated demand, and so its takt will be faster than either of them. Likewise, a feeder line that builds up a part or option that is not used on every unit is going to be running slower.

And finally if disruptions do cause shortfalls to the required output, you have to make it up sometime. If you are constrained from running overtime (and many operations are for various reasons), then your only alternative is to build a slight over speed into your takt time calculation. The nuances of this are the topic of a much longer essay, but the basics are this:

– If everything goes well, you will finish early. Stop and use the time for organized improvement of either process or developing people. Continuing to produce is overproduction, and just means you run out of work sooner if you have a good day tomorrow.

– If there are issues, the use the buffer time for its intended purpose.

– If there are more issues than buffer time, there is an operational decision to make. Have a policy in place for this. The simplest is “hope for a better day tomorrow” and use tomorrow’s buffer time to close the gap. If this isn’t enough, then a management decision about overtime or some other remedy is required.

What about just allowing production to fall short? Well.. if this is OK, then you were running faster than customer demand already. So pull that “extra” out of your schedule, stop overproducing (which injects its own disruptions into things), and deal with what just actually have to accomplish. Stop inflating the numbers because they hide the problems, the problems accumulate, and you end up having to inflate even more.

Gee, all of this seems complicated.

Yeah, it can be. But that complexity is usually the result of having an ad-hoc culture that makes up the reactions as you go along rather than a comprehensive thought-out systems-level approach. The key is to work through the “what if…” for what you are doing and thinking about doing, how the pieces actually interconnect and interact, and have a plan.

That plan is the first part of Plan-Do-Check-Act.

Then, as the real world intrudes, you can test your thinking against reality and get better and better rather than just being glad you survived another day.

And that, is the whole point of knowing your cycle times and takt times.

WSJ: Yes, Everybody Hates Performance Reviews

This article, carried by Yahoo News from the Wall Street Journal succinctly  says something that usually goes unsaid. It goes unsaid for the same reason that “Only Nixon could go to China” – only someone who is heavily invested in the performance review system can dare to criticize it. This, in itself, is an indictment of a process built built around control and fear.

Deming called out the same message decades ago. And even managers who purport to agree immediately start making excuses and justifications for why performance reviews are necessary.

If the question to be answered was “How does this Team Member know he is succeeding each day?” rather than “How do we rank and compare the Team Members against one another?” what would be different about this process?

 

The TPS vs. Toyota’s Production System

Up to this point I have resisted weighing in on the Toyota quality story largely because:

  1. I don’t have anymore insight than anyone else.
  2. The signal-to-noise ratio in the story seems really low, and I didn’t feel I would contribute much.

But there is another story in the back channels of the “lean” community.

Many of us (myself included) have been holding up Toyota as an example of “doing it right,” with good reason.

Toyota, of course, has never publicly claimed to be an icon of perfection, but we have held it up as one.

Now, when their imperfections are exposed, I am seeing a backlash of sorts, questioning whether the Toyota Production System is flawed somehow. This raises some really interesting questions cutting across the principles themselves; the psychology of various groups of practitioners; and of course Toyota’s practice of “The Toyota Production System.”

Are the principles themselves flawed?

We have a whole industry built on extolling the perfection of Toyota. Now we are seeing a bit of a boomerang effect. Say it ain’t so, but believe it or not, there is a population of people out there who are pretty sick of hearing “Toyota this..” and “Toyota that…” and having themselves held up to Toyota and being told they are coming up short.

Shame on us, the lean manufacturing community, for setting that situation up, but now we have to defend the principles on merit and establish credibility for ourselves rather than using Toyota as a crutch. Hopefully the adversity will sort out some of the practitioners who are still advocating rote copy of the tools and artifacts.

So, no, the principles are not flawed, not unless you didn’t believe in scientific thinking to begin with. It is a fallacy to confuse failure to adhere to the principles with failure of the principles themselves. The truth has always been that the Toyota Production System defines an ideal, and Toyota’s practice, like everyone else’s, comes up short sometimes.

So what will happen?

I can imagine that consultants the world over are figuring out how to re-brand their offerings to show how they “close the gaps” in the Toyota Production System to go “beyond lean.”

Meanwhile, though, those who are grounded are going to have to get more grounded. Stay focused on the process, the objectives, what is happening right in front of you. Ask the same questions. Tighten up on your teaching skills because the concepts are going to have to make sense in the here and now. No longer will they be blindly accepted because “That is how Toyota does it.”

 

Information Transfer Fail

While the dentist was looking over my x-rays, he saw something he would like checked out by a specialist. He used words like “sometimes they..” and “might be…” when describing the issue he saw.

I get a referral. The information on the referral slip is the name of the referring dentist (which I can’t read), no boxes checked, and “#31” in the comments.

I call the specialist and start getting technical questions about what my dentist wants them to look at / look for, etc.

So the process is to use the patient as a conduit for vaguely expressed (in layman’s terms) technical information between highly trained specialists.

Sadly, I think this happens all of the time in the health care industry. It seems that there is so much focus on optimizing the nodes that nobody really “gets” that the patient’s experience (and ultimately the outcome of the process) is defined more by the interactions and interfaces than it is by the nodes themselves.

I am really not sure how fundamentally different this is from a pilot asking a passenger to find the maintenance supervisor and tell the mechanic about a problem with a plane.

The net effect is, as I am writing this, the specialist’s office is calling the referring dentist and asking them what, exactly, they want done.. a net increase of 100% in the time involved for all parties to communicate.

While the national debate is on how we pay for all of this, we aren’t asking why it costs so much (or kills more people than automobile accidents do).

Job Shops

“We are a job shop.”

“We never do the same thing twice.”

These are common truths spoken by people who are struggling with how to apply lean production principles to their operation. They want to do better, but don’t see how something that originated in the relentless repetition of an automobile assembly line can work for them.

This is a reasonable reaction in the face of an overwhelming amount of literature and advice that is geared to these repetitive environments. An example of this is the common “elements of standard work” that come right out of Toyota and Shingijutsu:

  • Repeating work sequence (standard work)
  • Balanced to the takt time (which implies repetitive demand)
  • Standard work-in-process (or standard in-process stock)

Another example is “Takt, Flow and Pull” as the key elements of just-in-time production.

All of these things are absolutely true, but as instances of more fundamental principles.

Can lean production principles be applied to a job shop? Absolutely. It just requires someone with a bit more experience who knows how to interpret the situation and apply the principles rather than dogmatically apply a standard toolbox. It’s like the difference between the author who applies the basics of creating a compelling story, and the performer who expertly interprets the script written by others.

I have run into a fair number of “job shops” over the last 20 or so years. This is what I have observed:

A fair percentage of them actually have underlying repetition. It is just obscured by the job shop mentality. That is, they run them like job shops, so they become job shops. Even if only a portion of the work is repetitive, slicing this off and stabilizing it creates that much more mental bandwidth for dealing with the rest of it.

But even the true job shops, the ones who do custom work never to see that customer again are experts at what they do.

Expertise comes from experience.

Experience, in turn, comes from having done it many times before.

There is something they are good at. Each job may be custom, but it is built up from basic elements – the things they are experts at doing. Identifying those elements can clear out a lot of the seeming complexity. True process then emerges as they focus on how those elements are executed and organized, and paying attention to the interactions between them, the people, the customer. Then they work on getting better and better at creating stable processes that may only be carried out one time. But even then, there is knowledge to be gained that can be incorporated into doing it better next time, and that is the essence of kaizen.

Key point: If you are struggling with how to apply these principles, and aren’t getting answers that make sense to you, then (bluntly) you are talking to the wrong people. Keep at it until you find someone who can look at your situation and ask the right questions.