A Lean Leadership Pocket Card

I was going through some old files and came across a pocket card we handed out back in 2003 or so. It was used in conjunction with our “how to walk the gemba” coaching sessions that we did with the lean staff, and then taught them to do with leaders.

There is a pretty long backstory, some of it is summarized in Earl’s recollection on this old post: Genchi Genbutsu in a Warehouse as well as here: The Chalk Circle – Continued.

A lot has happened, a lot has been learned since then. Toyota Kata has been published, and that alone has focused my technique considerably (to say the least).

Nevertheless, I think the elements on these little cards are valuable things to keep in mind.

With that being said, a caveat: Lists like this run the risk of becoming dogma. They aren’t. There are lots of lists like this out there, and the vast majority are very good. The key here is something that a leader or team member can refer to as a reminder that may bias a decision in the right direction. It is the direction that matters, not the reminders.

Fundamentals

The fundamentals are based on the “Rules-in-Use” from Decoding the DNA of the Toyota Production System, a landmark HBR article by Steve Spear and H. Kent Bowen. The article, in turn, summarizes (and slightly updates) Spear’s findings from his PhD work studying Toyota.

A. All work highly specified as to content, sequence, timing, and outcome.

B. Every customer-supplier connection is simple and direct.

C. The path for every product is simple and direct.

D. All improvements are made using PDCA process.

What we left off, though, is that in each of those rules there is a second one: That all of these systems are set up to be “self diagnostic” – meaning there are clear indications that immediately alert the front line people if:

  • The work deviates from what was specified.
  • The connection between a customer and supplying process is anything other than specified.
  • The path a product follows deviates from the route specified.
  • Improvements are made outside of a rigorous PDCA (experimental) process.

In other words, the purpose of the rules is to be able to see when we break them, or cannot follow them, so we trigger action.

To put this into Toyota Kata-speak – every process is set up as a target condition that is being run as an experiment – even the process of improvement itself!

Every time there is a disruption – something that keeps the process from running the way it is supposed to – we have discovered an obstacle. That obstacle must first be contained to protect the team members and community (safety) and to protect the customer (quality). Then goes into the obstacle parking lot, and addressed in turn.

If you think about it, the Improvement Kata simply gives us much more rigor to (D).

This ties to the next sections.

Key Leadership Behaviors

Note that this is behaviors. These are things we want leaders to actually strive to do themselves, not just “support.” It was the job of the continuous improvement people to nudge, coach, assist the leaders to move in these directions. It was our job to teach our continuous improvement people how to do that coaching and assisting – beyond just running kaizen events that implement tools.

A. PDCA Thinking

Today we would use Toyota Kata to teach this. But the same structure drove our questioning back then.

B. Four Rules:

1. Safety First

Even though this should be obvious, it is much more common that people are tacitly, or even directly, asked to overlook safety issues for the sake of production. I remember walking through a facility with a group of managers on the way to the area we were going to see. Paul stopped dead in his tracks in front of a puddle on the floor. He was demonstrating just how easy it was for the leadership to walk right past things that should be attended to. And in doing so, they were sending the message – loud and clear in their silence – that having a puddle on the floor was OK.

2. Make a Rule, Keep a Rule

This is a more general instance of Rule #1. But the it is more subtle than it may seem on the surface. Most people immediately interpret this as enforcing organizational discipline, but in reality it is about managerial discipline.

Nearly every organization has a gap between “the rules” and how things really are day-to-day. Sometimes that gap is small. Sometimes it is huge.

Often “rules” are enforced arbitrarily, such as only cases where a violation led to a bigger problem of some kind. Here’s an example: Say your plant has a set of rules about how fork trucks are to be operated – speed limits, staying out of marked pedestrian lanes, etc. But in general the operators hurry, cut a corner now and then. And these violations are typically overlooked… until there is some kind of incident. Then the operator gets written up for “breaking the rules” that everyone breaks every day – and management tacitly encourages people to break every day by focusing on results rather than process.

When we say “make a rule / keep a rule” what we mean is if you aren’t willing to insist on a rule being followed consistently, then take the rule off the books. And if you are uncomfortable taking the rule off the books, then your only option is to develop something that you can stand behind. It might be simple mistake proofing, like physical barriers between forklift aisles and pedestrian aisles. But if you are going to make the rule, then find a way to keep the rule.

Do you have “standard work” documents that are rarely followed? Stop pretending you have standards or rules about how the work is done. Throw them away if you aren’t willing to train to them, mistake proof to them and reinforce following them.

3. Simple is Best

Simply, bias heavily toward the simplest solution that works. The fewest, simplest procedures. The simplest process flow. Complexity hides problems. “Telling people” by the way, is usually less simple than a physical change to the work environment that guides behavior. See above.

4. Small Steps

Again, Toyota Kata’s teaching covers this pretty well today. The key is that by taking small steps, verifying that they work, and anchoring them into practice before taking the next ensures that each step we take has a stable foundation under it.

The alternative would be to make many changes at once in the name of going faster.

We emphasized here that “small steps” does not equal “slow steps.” It is possible to take small steps quickly, and we found that in general doing so was faster than making big leaps. Getting big changes dialed in often required backing out and implementing one thing at a time anyway – just to troubleshoot! See “Gall’s Law” which states:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

John Gall, author of Systematics

and sums this up nicely.

C. Ask “Why, what, where, when, who, and how” in that order.

Here we borrowed the sequence from TWI Job Methods. The first two questions challenge whether a process step is even necessary: Why is it necessary? What is its purpose? To paraphrase Elon Musk, the greatest waste of time is improving something that shouldn’t even exist.

Then: Where is the best place? and When is the best time? These questions might nudge thinking about combining steps and further simplifying the process.

And finally we can ask Who is the best person? and “How” is the best method? The key point here is until we have the minimum possible steps in the simplest possible sequence, and understand the cycle times, it doesn’t make sense balance the work cycle or work on improving things.

Come to think about it – perhaps we should ask “How?” before we ask “Who” since improving the method will change the cycle times and may well inform out decisions about the work balance. Hmmm… I’ll have to think about that. Any thoughts from the TWI gurus?

D. Ask Why 5 Times

Honestly, this was a legacy of the times. Unfortunately it suggests that you can arrive at a root cause simply by repeatedly asking “Why?” and writing down the excuses answers that are generated. In reality problem solving involves multiple possible causes at each level, and each must be investigated. I talked about this in a post way back in 2008: Not Just Asking Why – Five Investigations.

E. Go and see.

Go and see for yourself. Taking this into today’s practice, I think it is something that the Toyota Kata community might emphasize a little more. We tend to ask the question “When can we go and see what we have learned…?” but all too often the answer to “What have you learned?” is a discussion at the board rather than actually going and observing. Hopefully the board is close to where the improvement work is being done. Key point for coaches: If the learner can’t show you and explain until you understand, it is likely the learner’s understanding could be deeper.

As You Walk The Workplace:

Check:

perhaps we should have said “Ask…” rather than “Check” but asking and observing are ways to “check.” All of the below are things that the leader walking the workplace must verify by testing the knowledge of the people doing the work.

A. How should the work be done? Content, Sequence, Timing, Outcome

This is another nod to the research of Steven Spear. The key point here is that before you can ask any of the following questions, you have to have a crisp and precise of what “good” looks like. In this paradigm, all processes are target conditions. And as the work is being done, we are actively searching for obstacles so we can work to make the work smoother and more consistent.

In other words, “What should be happening?” and “How do you know?”

Do the people doing the work understand the standard process as it should be done?

A few months ago I went into some depth on this here: Troubleshooting by Defining Standards. That probably isn’t the best title in retrospect, but there are too many links out there that I don’t want to break by changing it.

B. How do you know it is being done correctly?

Today I ask this question differently. I ask some version of “What is actually happening?” followed by “How can you tell?” We want to know if the people doing the work have a way to compare what they are actually doing against the standard.

C. How do you know the outcome is free of defects?

So, question B asks about consistency of the process, and question C asks about the outcome. Does the team member have a way to positively verify that the outcome is defect-free?

D. What do you do if you have a problem?

Again, we are checking if there is a defined process for escalating a problem. And we define “problem” as any deviation from the standard, or any ambiguity in what should be (or is) happening. We want someone to know, and act, on this, and the only way that is going to happen is to escalate the problem.

We want this process to be as rigorous and structured as the value-adding work.

And we want as much care put into designing production process as was put into designing the product itself. All too often great care and a lot of engineering time goes into product design, and only a casual pass is made at designing and testing the process.

Even better if these are done simultaneously where one informs the other.

For Abnormal Conditions:

ACT:

These are actions that the leader must take if she finds something that isn’t “as it should be” in the course of the CHECK questions above. Key Point: These are leadership actions. That doesn’t mean that the leaders personally carry them out, but the leaders are personally responsible for ensuring that these things are done – and checking again.

That is the only way I know of to prevent the process from continuing to erode.

A. Immediately follow up to restore the standard.

If it isn’t possible to get the intended standard into back place, then get a temporary countermeasure into place that ensures safety and quality.

B. Determine the cause of erosion.

We are talking about process erosion here, with the assumption that something knocked the process off its designed standard. Some obstacle has been discovered, we have to better understand what it is – at least enough to get it documented.

C. Develop and apply countermeasure.

Here we may have to run experiments against this newly discovered obstacle and figure out how to make the process more robust.


That is the end of the little card. But I want to point out that we didn’t just hand these out. You got one of these cards after time paired with a coach on the shop floor practicing answering and asking these questions. Only after you demonstrated the skill did you get the card – just as a reminder, not as a detailed reference. This exercise was inspired by a few of us who had experiences “in the chalk circle” especially with Japanese senseis who had been direct reports to Taiichi Ohno.

We piloted and developed this process on a very patient and willing senior executive – but that is another story for another day. (Thank you once again, Charlie. I learned more from you than you will probably ever realize.)

Ambitious Growth Plans? Your Customers Will Right-Size You

I’ll call the title of this post “Dave’s Observation.”

He is reflecting his experience in varied industries that if a company grows beyond its ability to deliver quality product, on time, then order volume will drop until it reaches a point that performance returns.

The business literature is full of examples of this – companies who could not keep up with their own success, their performance deteriorates and, well, many of them go out of business.

I have seen more than a few companies with aggressive growth plans that outrun their ability to actually execute, and they get into trouble.

This also happens in mergers and acquisitions where one company is merged into another with the assumption that the combined company can execute and perform in ways neither company has ever done. Starry-eyed executives often look only at the financial models, maybe equipment capacity, and skip over the operational aspects of their due diligence.

In the end, though, if the operational capability is not there, then none of the plans actually matter. Your “synergy” or “economy of scale” will evaporate like an ice cube on the Moon until equilibrium is restored.

Bottom line: If you are engaged in an ambitious growth plan, then list everything that has to be different for your model to work.

By “different” I mean you are asking for or expecting some task execution or level of performance that does not exist today as a matter of mundane routine.

Then ask “What is our plan to close this gap?” – and run the same exercise on executing that plan. “Change” is really hard, and just telling people what needs to be different, no matter how pretty the PowerPoint slides are, no matter how slick the presentation is, won’t make anything change. (If anything, it often breeds cynicism because it is read as unrealistic.)

Change requires step-by-step, methodical, practice to anchor each small change into the system, then the next, then the next.

Toyota Kata offers a good pattern for this. Just don’t confuse the underlying pattern with the methods used to teach it.

Creating Resistance As You Go (Don’t)

The role of “change agent” is actually a role of leadership.

Leading change is difficult work that involves changes in the norms, routines, working relationships, behavior within and between groups. It is required when a simple technical change either isn’t going to get the job done, or requires the above changes to work at all. Most (if not all!) of the “lean tools”* fall into the later: The process changes are straight forward, but making them work requires altering the habitual patterns of how people work together.

Before I dive into what works, I want to spend a little time on what doesn’t work.

The Bulldozer: Creating Resistance

Bulldozer climbing a mound of dirt.

A team had a challenge – the result they were striving to achieve – of getting a 2-3 week administrative workflow (that sometimes went longer) down to a consistent three days. Their target condition was a pretty good work flow that, by all accounts so far, could avoid a lot of delays (on the order of days and weeks).

The changes they proposed would eliminate a number of transfers from one department to another (which always means another queue). However it also calls for eliminating some long-standing work-arounds that involve filling out forms and passing them along by email. But now they have a new ERP system, and the intent has been that this work is done within that system.

Those forms are in another department’s process, and involve people who haven’t been involved (so far) with the work to date. (There are valid reasons for this, and yes, some of this could have been avoided by involving everyone from the beginning, but that isn’t the point of the story.)

A functional department manager set off a flurry of pushback through a series of emails that essentially said “This is the future” and exhorting people to get on board with the new process vs. defending the old one.

One of the tenants of an effective change agent is “Don’t work uphill” with the corollary of “Don’t create hills in front of you.” I call the opposite of this the bulldozer approach. Unfortunately, like the picture above, just trying to push things through tends to build up a mound of resistance in front of you.

What did we learn?

Rather than trying to engage the new idea as an experiment – “Let’s try this and see what we learn,” the change agent tried to use position power to push the idea through. He took an action, and had an (implied) expected result – that people would see the light and adopt the new process.. The actual result, though, was quite different than what was expected – they doubled down on their resistance.**

A scientific-thinking change agent (a.k.a “a leader”) is going to step back and assess. Why did I get the reaction I did? What triggered it? What are the values of this constituency that are being challenged? Most pushback comes from a perceived threat to something that is regarded as valuable.

Perhaps the current workflow solves a very real problem. Perhaps it is otherwise very useful for something I am not aware of. Or maybe there is some emotional stake attached to the status quo. There is likely a combination of all three, or other factors I haven’t mentioned.

When proposing a new idea there is an opportunity to become curious about what previously hidden (to us at least) obstacles have just been uncovered, step back and work on the next one.

Leadership is a series of experiments. Not everything will work. But everything is an opportunity for learning and adjusting or adapting the next step appropriately.

People who expect their position-power to carry them through often tend to assign blame to individuals as “resisting the change.” But if we carry a different assumption – that everyone is doing the best they can to do the best job they can – then we can reframe and possibly reinterpret the reaction we are getting.

What other interpretations could we assign to this pushback other than “They don’t want to?” How many of those interpretations can we think of?

What is your next step or experiment?

Each of those possible interpretations is a testable assumption. Now I can frame my next action, conversation, or intervention to test one or more of those assumptions. This requires me to go into curiosity mode, because I really don’t know if they are true or not.

Now I have a different conversation because I am seeking first to understand. I can test assumptions without threatening anyone. Listen. Don’t defend. Paraphrase back until you hear “That’s right” signaling agreement that you heard what they were saying. That doesn’t mean you agree, but that you heard. Until someone feels heard they aren’t going to be soaking in what you are trying to tell them, they are going to be setting up the next defense of their position.

There is VERY rarely a need to directly confront someone over a different interpretation of the facts.

Don’t be a bulldozer – it doesn’t work.

———–

*And Six Sigma tools, and Theory of Constraints tools, and TQM Tools, and the tools associated with pretty much any other “program” that falls under the umbrella of continuous improvement.

**Though, Dr. Phil’s coaching would probably be something along the lines of “What did you THINK would happen??” (Semi-apology to my non-US readers who may not have context for this attempt at cultural humor.)

Creative Safety Supply: Kaizen Training and Research Page

Normally when I get an email from a company pointing me to the great lean resource on their web page, I find very little worth discussing. But Creative Safety Supply in Beaverton, Oregon has some interesting material that I think is worth taking a look at.

First, to be absolutely clear, I have not done business with them, nor do I have any business relationship. I can’t speak, one way or the other, about their products, customer service, etc

With that out of the way, I found their Kaizen Training and Research Page interesting enough to go through it here and comment on what I see.

What, exactly, is “PDCA?”

The section titled Kaizen History goes through one of the most thorough discussions of the evolution of what we call “PDCA” I have ever read, tracing back to Walter Shewhart. This is the only summary I have ever seen that addresses the parallel but divergent histories of PDCA through W. Edwards Deming on the one hand and Japanese management on the other. There has been a lot of confusion over the years about what “PDCA” actually is. It may well be that that confusion originates from the same term having similar but different definitions depending on the context. This section is summed up well here:

The Deming Circle VS. PDCA

In August of 1980, Deming was involved in a Roundtable Discussion on Product Quality–Japan vs. the United States. During the roundtable discussion, Deming said the following about his Deming Circle/PDSA and the Japanese PDCA Cycle, “They bear no relation to each other. The Deming circle is a quality control program. It is a plan for management. Four steps: Design it, make it, sell it, then test it in service. Repeat the four steps, over and over, redesign it, make it, etc. Maybe you could say that the Deming circle is for management, and the QC circle is for a group of people that work on faults encountered at the local level.”

So… I learned something! Way cool.

Rapid Change vs. Incremental Improvement

A little further down the page is a section titled Kaizen Philosophy. This section leans heavily on the thoughts / opinions of Masaaki Imai through his books and interviews. Today there is an ongoing debate within the lean community about the relative merits of making rapid, radical change, vs. the traditional Japanese approach of steady incremental improvement over the long-haul.

In my opinion, there is nothing inherently wrong with making quick, rapid changes IF they are treated as an experiment in the weeks following. You are running to an untested target condition. You will likely surface many problems and issues that were previously hidden. If you leave abandon the operators and supervisors to deal with those issues on their own, it is likely they simply don’t have the time, skill or clarity of purpose required to work through those obstacles and stabilize the new process.

You will quickly learn what the knowledge and skill gaps are, and need to be prepared to coach and mentor people through closing those gaps. This brings us to the section that I think should be at the very top of the web page:

Respect for People

Almost every discussion about kaizen and continuous improvement mentions that it is about people, and this page is no different. However in truth, the improvement culture we usually describe is process focused rather than people focused, and other than emphasizing the importance of getting ideas from the team, “employee engagement is often lip-service. There is, I think, a big difference between “employee engagement” and “engaging employees.” One is passive, waiting for people to say something. The other is active development of leaders.

Management and Standards

When we get into the role of management, the discussion turns somewhat traditional. Part of this, I think, is a common western interpretation of the word “standards” as things that are created and enforced by management.

According to Steve Spear (and other researchers), Toyota’s definition of “standard” is quite different. It is a process specification designed as a prediction. It is intended to provide a point of reference for the team so they can quickly see when circumstances force them to diverge from that baseline, revealing a previously unknown problem in the process.

Standards in this world are not something static that “management should make everyone aware of” when they change. Rather, standards are established by the team, for the team, so the team can use them as a target condition to drive their own work toward the next level.

This doesn’t mean that the work team is free to set any standard they like in a vacuum. This is the whole point of the daily interaction between leaders at all levels. The status-quo is always subjected to a challenge to move to a higher level. The process itself is predicted, and tested, to produce the intended quality at the predicted cost, in the predicted time, with the predicted resources. Because actual process and outcomes are continuously compared to the predicted process and outcomes, the whole system is designed to surface “unknowns” very quickly.

This, in turn, provides opportunities to develop people’s skills at dealing with these issues in near-real time. The whole point is to continuously develop the improvement skills at the work team level so we can see who the next generation of leaders are. (Ref: Liker and Convis, “The Toyota Way to Lean Leadership”)

Staging improvement as a special event, “limited time only” during which we ask people for input does not demonstrate respect, nor does it teach them to see and solve those small issues on a daily basis.

There’s more, but I’m going to stop here for now.

Summary

Creative Safety Supply clearly “gets it.” I think this page is well worth your time to read, but (and this is important), read it critically. There are actually elements of conflicting information on the page, which is awesome because it gives you (the reader) an opportunity to pause and think.

From that, I think this one-page summary really reflects the state of “lean” today: There IS NO CANONICAL DEFINITION. Anyone who asserts there is has, by definition, closed their mind to the alternatives.

We can look at “What Would Toyota Do?” as somewhat of a baseline, but ultimately we are talking about an organizational culture. Toyota does what they do because of the ways they structure how people interact with one another. Other companies may well achieve the same outcomes with different cultural mechanisms. But the interactions between people will override process mechanics every time.

Hopefully I created a lot of controversy here.  🙂

Learning = Extending the Threshold of Knowledge

“My computer won’t boot.”

Mrs. TheLeanThinker’s computer was hanging on the logo screen, keyboard unresponsive.

I know already that if the CPU were bad it wouldn’t get this far.

I also knew that the system hasn’t even tried to boot the OS from the hard drive yet, so that likely isn’t the problem.

Working hypothesis: It’s something on the motherboard.

Start with the simple stuff that challenges the working hypothesis:

  • Hang test a different, known good, power supply. No change.
  • Pull memory cards and reinstall them one by one. No change.
  • Pull the motherboard battery, unplug, wait a few minutes to possibly reset the BIOS. No change.
  • Try holding down the DEL key on power-up to get into BIOS settings. Nope, system still hangs, though it does read that one keystroke, the keyboard is dead after that.
  • Try Ctrl-Home to reach the BIOS flash process. Nope.

image

There is no evidence that the motherboard is not dead. Final test:

Get the numbers off the motherboard, find the same model on Amazon, order it for $37.50 to the door. (Intel hasn’t made this processor type since 2011).

New motherboard arrived today. Switch it out, takes about 30 minutes.

Boot up the machine, works OK, set the time in the BIOS, and pretty much good to go.

Convince Windows 10 that I haven’t made a bootleg copy.

Done.

The Threshold of Knowledge

I learned to code in 1973 on PDP-8 driving teletypes. Although my programming skills are largely obsolete these days, I am comfortable poking around inside the box of a PC, and I generally know how they work. Thus, the troubleshooting and component replacement I described above was not a learning experience. Yes, I learned what was wrong with this computer. (The “bad motherboard” was a hypothesis I tested by installing a new one.) But I didn’t learn anything about computers in general.

Rather than working through experiments into new territory, I was troubleshooting. Something that had worked was not working now. My experiments were an effort to confirm the point of failure.

Therefore, as interesting as the diversion was, aside from a little research on some of the more arcane troubleshooting, it was not a learning exercise for me. It was all within my Threshold of Knowledge.

In the Improvement Kata, “threshold of knowledge” refers to the boundary between “We know for sure” and “We don’t know.” Strictly speaking, we only say “We know” when there is specific and relevant evidence to back it up.

image

In this case, my challenge (fix the wife’s computer) was well inside the red circle.

But this wouldn’t be the case for everyone.

The Threshold of Knowledge is Subjective

Someone else with the same challenge may not see this as a routine troubleshoot-and-repair task. Rather, he has to learn.

I had to learn it at some point as well. The difference is that I had already learned it. I had already made mistakes, taken a week to build a PC and get it working many years ago. I learned by experimenting and being surprised when something didn’t work, then digging in and understanding why. On occasion, especially in the early days, I consulted experts who coached me, or at least taught me what to do and why.

Coaching To Extend the Threshold of Knowledge

Learning is the whole point of the Improvement Kata. That is why we call the “improver” the “learner.” If someone encounters a problem like my example and I am responsible for developing their skills, I am not serving them if I do something like:

  • Sit down at their machine and troubleshoot it.
  • Tell them what step to take, and asking what happened so I can interpret the outcome.

That second case is deceptive. The question is “Who is doing the thinking?” If the coach is doing the thinking, then the coach isn’t coaching, and the learner isn’t learning.

In this case I would also have to recognize this is going to take longer than it would if I did it myself. That is a trap many leaders fall into. They got where they are because they can arrive at a solution quickly. But the only reason they can do that is because, at some point in the past, they had time to learn.

“My computer doesn’t boot.” If my objective is for this person to learn, then I need to go back to the steps of learning. Given that the challenge is likely “My computer operates normally,” what would be my next question to help this person learn how to troubleshoot a problem like this?

I need to know what they know. “Do you know where in the boot sequence it is hanging up?” If the answer is “No,” or just a repeat of the symptom, then my next target condition is for them to understand the high-level sequence of steps that happens between “ON” and the login screen. That would be easy to depict in a block diagram. It’s just another process. But my learner might have to do a little research, and I can certainly point him in the right direction.

I’m not going to get into the details here, because this post isn’t about troubleshooting cranky computers.

General Application

“If somebody comes to me with a problem, I have two problems.”

  • The original issue.
  • The fact that this person didn’t know how to handle it.

You can easily translate my computer example into a production quality example. A defect is produced by a process that normally does not produce them. What is different between “Defect” and “Defect-Free?” Something is. We just don’t know what.

Is it something we need to learn? Something we need to teach? Or something we need to communicate?

If my working challenge for my organization is something like “Everyone knows everything they need to do their jobs perfectly.” then I am confronted every day with evidence that this is not as true as I would like.

If I look at those interventions as “the boss just doing his job” then I lose the opportunity to teach and to grow the organization. I am showing how much I know, and by doing so just extending the dependency. That might feel good in the short term, but it doesn’t do much for the future.

Think about this… in your organization, if the boss were promoted or hired out of the job tomorrow, would you look outside the immediate organization for a replacement? If so, you are not developing your people. When I see senior leaders being hired from outside, all I can do is wonder why they have so little faith in the people they already have.

_________

*I remember when Gateway built their own machines, which I guess shows how long I’ve been playing with PCs. Then again, I remember when the premium brand was Northgate. Of course, I also remember programming on punch cards.

It’s “What must we learn?” not “What should we do?”

Darren left a great question in the Takt Time-Cycle Time post:

Question… Which system is more efficient, a fixed rigid Takt based production line or a flexible One Piece Flow?

In terms of designing a manual based production line to meet a theoretical forecasted ‘takt time’, (10 fixed workstations needs 10 operators), how do you fluctuate in a seasonal business (+/-25%/month) to ensure you don’t end up over stocking your internal customer?

Would One Piece Flow be more efficient on the whole value chain in this instance due to its flexibility?

That was a few weeks ago. Through its evolution, this post has had four titles, and I don’t think there is a single sentence of the original draft that survived the rewrites.

I started this post with a confident analysis of the problem, and the likely solution. Then I realized something. I don’t know.

My brain, just like every other brain on the planet (human and others) is an incredibly efficient pattern matching machine. I got a little bit of information, and immediately filled in a picture of Darren’s factory and proceeded to work out a course of actions to take, as well as alternatives based on other sets of assumptions.

NO, No, no!

Our Reflex: Jumping to Solution

This graphic is copied from Mike Rother’s presentation material. It is awesome.

image

It is likely that at this point you know that it doesn’t say “JUMPING TO CONCLUSIONS” under the little blue square, and of course you are right.

image

But in spite of the fact that you know the truth, it is likely you still read “JUMPING TO CONCLUSIONS” when you look at the first graphic. I know I do, and I present this all of the time.

Our brains are all wired to do this, it is basic survival. It happens very fast. Think about a time when you have been startled by something you thought you saw, that a few seconds later you realized it was nothing.

That pattern recognition triggered the startle. It was seconds later that your logical brain took over and analyzed what was really going on. This is good. We don’t have time to figure out if that movement in the grass was really a leopard or not. We’ll sort that out after we get away.

Our modern brains work the same way with learned patterns imagebut we are usually very poor at distinguishing between “what we really know” and “what we have filled in with assumptions.”

This is the trap that we “lean experts” (whatever that means) fall into all of the time. We take limited information, extrapolate it into a false full understanding, and deliver a diagnosis and treatment.

Boom. Done. Next?

What’s even worse is we often don’t hang around to see if the solution worked exactly the way we expected, or if anomalies came up.

In other words, everything comes down to takt, flow and pull, right? Kinda, but kinda not.

Some Technical Background

All of the above notwithstanding, it really helps to understand how the mechanics of “lean” tie together to create the physical part of an organic/technical process.

What I mean by “really helps” is this understanding gives you a broad sense of how the mechanics help people learn. Someone who only understands the mechanics as “a set of tools” is committing the gravest sin: Leaving out the people.

One Piece Flow

One piece flow is not inherently efficient. It is easy to have lots of excess capacity, which translates to either overproduction or waiting, and still have one piece flow.

This is the people part: One piece flow makes those imbalances very obvious to the people doing the work so you can do something about them, if you choose to. Many people think the goal is one piece flow. The goal is making sure the people doing the work can see if the flow is going smoothly or not; and give them an opportunity to fix the things that make flow less than smooth.

A pull system is designed to throw overproduction (or under-production) right into your face by stopping your line rather than allowing excess stuff to just pile up. Again, it is a tool to give the people doing the work immediate visibility of something unexpected rather than the delayed reporting of inventory levels in a computer somewhere.

Flexibility

Any given level of capacity has a sweet spot for efficiency. Even “inefficient” systems are most efficient when their capacity (usually defined by a bottleneck somewhere) is at 100% utilization (which rarely happens).

If other process steps are capable of running faster (which is the very definition of a bottleneck), they will, they must either be underutilized or build up work-in-process. This is part of the problem Darren is asking about – flooding his downstream operation with excess WIP to keep his line running efficiently.

If your system is designed to max out at 100 units / day, and you make less than, that your efficiency is reduced. If the next operation can’t run at 100 units / day and absorb your output, then it is the bottleneck. See above.

Now, let’s break down your costs of capacity. In the broadest sense, your costs come down to two things:

  • Capital equipment. (And let’s include the costs of the facility here.)
  • Labor – paying the people.

The capital equipment cost is largely fixed. At any rate of production less than what the equipment is capable of holding, you are using it “less efficiently” than you could. Since machines usually operate at different rates, it is you aren’t going fully utilize anything but the slowest one. It doesn’t make sense to even try.

People is more complicated. In the short term, your labor costs are fixed as well. You are paying the people to be there whether they are productive or not.

When the people are operating machines, your flexibility depends on how well the automation is designed. The technical application of “lean tools” to build flow cells pushes hard against this constraint. We strive to decouple people from individual machines, so the rate can flex up and down by varying the work cycles rather than just having people wait around or over produce.

At the other end of the labor spectrum is pure manual work, like assembly. We are striving for that same flexibility by moving typically separated operations together so people can divide the labor into zones that match the desired rate of production.

All of these approaches strive for a system that allows incrementally adjusting the capacity by adding people as needed. However this adds costs as well, often hidden ones. Where do these people come from, and frankly, “what are they doing when they aren’t working for you?” are a couple of questions you need to confront. The people are not parts of the machine. The system is there to help the people, not the other way around. This is people using tools to build something, not tools being run by people.

Handling Seasonal Production Efficiently

“Our demand is seasonal” is something I hear quite a bit. It is usually stated as though it is a unique condition (to them) that precludes level production. In my nearly 30 years in industry, I haven’t encountered a product (with the possible exception of OEM aircraft production and major suppliers) that didn’t have a seasonal shift of some kind.

Depending on the fluctuations and predictability of future demand, using a combination of managing backlog and building up finished goods is a pretty common way to at least partly level things out for planning purposes.

That being said, I know of at least one company whose product is (1) custom ordered for every single unit and (2) highly seasonal (in fact, they are in their peak season as I write this). They don’t have as many options.

Solving the Problem

With all of that, we get to Darren’s specific question.

The short answer is “I don’t know, but we can figure it out.”

There isn’t a fixed answer, there is a problem to solve, a challenge to overcome.

Challenge

I am interpreting the challenge here as “Have the ability to flex production +/- 25% / month without sacrificing efficiency.”

Just to ensure understanding of the challenge, I would ask to translate the production capacity targets into takt times. What is the fastest takt time you would need to hit? What is the slowest?

In other words, the +/-25% makes me do math, even if I know the baseline, before I really know what you need to be able to do. Let’s get some hard numbers on it so we will all agree when we see it, or don’t.

Remember, takt time is simply a normalization of your demand over your production time. It is a technique for short-term smoothing of your demand. It doesn’t mean you are operating that way.

Current Condition

We need to learn more, so the next questions have to do with the current condition.

While this post is too short to get down to the details, there are some additional questions I would really need to understand here.

Known: There are 10 fixed workstations with 10 operators.

Assumed to be known: The high and low target takt times (from the challenge).

How are the workstations laid out?

What are the cycle times of each operation?

What is actually happening at each of the workstations?

What are they currently capable of producing in relation to the takt times we want to cover in our +/- 25% range?

A good way to start would be to get exit cycles from each of the positions, and from the whole line. What is the current cadence of the operation? What are the lowest repeatable cycle times? How consistently is it able to run? What is driving variation?

Since we are looking for rate flexibility, I am particularly concerned with understanding points of inflexibility.

I would be looking at individual steps, at distance between the workstations, and how easily it is to shift work from one to another. Remember, to be as efficient as possible, each work cycle needs to be as close as possible to the takt time we are striving to achieve this season. Since that varies, we are going to need to create a work space that gives us the smoothest transitions possible.

What is the Next Target Condition?

I don’t know.

Until we have a good grasp of the current condition, we really can’t move beyond that point. While I am sure Darren knows much more, I am at my threshold of knowledge: 10 workstations, 10 operators. That’s all I know.

However I do know that it is unlikely I would try to get to the full challenge capability all at once. Even if I did have a good grasp of the current condition, I probably can’t see the full answer, just a step that would do two key things:

  • Move in the direction I am trying to go.
  • Give me more information that, today, is hidden by the nature of the work.

For an operation this size, (if I were the learner / person doing the improvement here) I would probably set that target condition for myself at no more than a week or two. (This also depends on how much time I can focus on this operation, and how easy it is to experiment. The more experiments I can run, the faster I will learn, and the quicker I can get to a target.)

Now… I will re-state the target condition to answer this question:

“We can’t… [whatever the target condition is]… “because ________.” as many times as I can. That is one way to flush out obstacles.

Another way is just to tell the skeptics we are going to start operating like this right away, then write down all of the reasons they think it won’t work. Smile

Then the question is “OK, which of these obstacles are we going to address first?”

Iterate Experiments / PDCA to learn.

Once I know which obstacle I am choosing to address first, I need to know more about it. What do I want to learn, or what effect do I want to have on the process? Those things are my expected result.

Now… what do I need to do to cause that to happen? That is my next experiment.

And we are off to the races. As each learning cycle is completed, your current condition, your current level of understanding, changes. As you learn more, you better understand the obstacles and problems.

When you reach a target condition (or realize you are at the deadline and haven’t reached it), then go back to the top, review the challenge, make sure you understand the current condition, and establish a new target. Lather, rinse, repeat.

This Isn’t About “The Answers.”

imageA long time ago, when I first started this blog, I wrote a post called “The Chalk Circle.” I told the story of one of my more insightful learning experiences in the shadow of one of the original true masters, the late Yoshiki Iwata. My “ah ha” moment finally came several years later, and a year after his death. He wasn’t interested in the answers, he was teaching me the questions.

We don’t know the answers to a problem like “How do I get maximum efficiency through seasonal demand changes.” The answer for one process might give you something to think about, but copying it to another is unlikely to work well. What would work for Darren’s operation is unlikely to work in Hal’s. Even small differences mean there is more learning required.

When confronted with a problem, the first question should never be “What should we do?” Rather, we need to ask “What do we need to learn?”  What do we know? What do we not understand? What do we need to learn, then what step should we take to learn it? Taking actions without a learning objective is just trying stuff and hoping it works without understanding why.

What works is learning, by applying, the thinking behind sound problem solving, and being relentlessly curious about what is keeping you from moving to the next level.

I have come a long way since my time with Mr. Iwata, I continue to learn (lots), sometimes by making mistakes, sometimes with unlikely teachers, at times and in ways I least expect it. Sometimes it isn’t fun in the moment. Sometimes I have to confront something I have hidden from myself.

One thing I have learned is that the people who have all of the answers have stopped learning.

Darren – if you want to discuss your specific situation, click on “Contact Mark” and drop me an email.

Toyota Kata: What is the Learner Learning?

In the language of Toyota Kata we have a “coach” and a “learner.” Some organizations use the word “improver” instead of “learner.” I have used those terms more or less interchangeably. Now I am getting more insight into what the “learner” is learning.

The obvious answer is that, by practicing the Improvement Kata, the learner is learning the thinking pattern that is behind solid problem solving and continuous improvement.

But now I am reading more into the role. The “learner” is also the one who is learning about the process, the problems, and the solutions.

Steve Spear has a mantra of “See a problem, solve a problem, teach somebody.” This is, I think, the role of the learner.

What about the coach?

The coach is using the Coaching Kata to learn how to ask questions that drive learning. He may also be un-learning how to just have all of the answers.

As the coach develops skill, I advise sticking to the Coaching Kata structure for the benefit of beginner learners. It is easier for them to be prepared if they understand the questions and how to answer them. That, in turn, teaches them the thinking required to develop those answers.

Everybody is a Learner

The final question in the “5 Questions” is “When can we go and see what we have learned from taking that step?” It isn’t when can I see what You have learned. It is a “we” question because nobody knows the answers yet.

The Improvement Kata: Next Step and Expected Result

In the Improvement Kata sometimes it helps to think about the outcome desired and then the step required to accomplish it.

A couple of months ago, I gave a tip I’ve learned for helping a coach vet an obstacle.

Another issue I come across frequently is a weak link between the “Next Step” and the “Expected Outcome.”

In the “Five Questions” of the Coaching Kata we have:

What is your next step or experiment?” Here we expect the learner / improver to describe something he is going to do. I’m looking for a coherent statement that includes a subject, verb, object here.

Then we ask “What do you expect?” meaning “What do you expect to happen?” or “What do you expect to learn?” from taking that step?

I want to see that the “Expected Result” is a clear and direct consequence of taking the “Next Step.”

Often, though, the learner struggles a bit with being clear about the expected outcome, or just re-states the next step in the past tense.

While this is the order we ask the questions, sometimes it helps to think about them in reverse.

Reverse the Order

Have the learner first, think about (and then describe) what she is trying to accomplish with this step. Look at the obstacle being addressed, and what was learned from the last step.

Based on those things, ask “what do you want to accomplish with your next step?”

The goal here is to get the learner to think about the desired result. Don’t be surprised if that is still stated as something to do, because we are all conditioned to think in terms of action items, not outcomes.

“What do you need to learn?” sometimes helps.

“I need to learn if ______ will eliminate the problem.” might be a reply.

Even a proposed change to the process usually has “to learn if” as an expected outcome, because we generally don’t know for certain what the outcome will be until we try it.

Have the learner fill in the “Expected Outcome” block.

NOW ask “OK, what do you have to do to ______ (read what is in the expected outcome)?”

PDCA Outcome-Activity

That should get your learner thinking about the actions that will lead to that outcome.

A Verbal Test

A verbal test can be to say “In order to ______ (read the expected outcome), I intend to _____ (read the next step.”

If that makes sense grammatically and logically, it is probably well thought out.

Toyota Kata: Is That Really an Obstacle?

“What obstacles do you think are preventing you from reaching the target condition?”

When the coach asks that question, she is curious about what the learner / improver believes are the unresolved issues, sources of variation, problems, etc. that are preventing the process from operating routinely the way it should (as defined by the target condition).

I often see things like “training” or worse, a statement that simply says we aren’t operating the way the target says.

Here is a test I have started applying.

Complete this sentence:

“We can’t (describe the target process) because ________.”

Following the word “because,” read the obstacle verbatim. Read exactly what it says on the obstacle parking lot. Word for word.

If that does not make a grammatically coherent statement that makes sense, then the obstacle probably needs to be more specific.

 

 

Toyota Kata: Don’t Change The Target Condition Date

A target condition has three main elements:

  • An achieve-by date.
  • A level of performance that will be achieved.
  • The operational process that will be in place.

The details of the #2 and #3 can take a number of forms, but today I want to talk about the achieve-by date.

Keep the time horizon fairly short, especially at first. For a typical process that is carried out every day, I usually suggest a two week time horizon. My rationale is this: I don’t want the target condition to seem big or complex. Two weeks is enough time to understand and significantly improve a handful of steps in a complex process. It is a short enough time to keep the improver from trying to fix a complex or global issue all at once.

For example, if a process is carried out in multiple departments, two weeks is enough to try experiments in one of them, but not enough to implement a change across the whole organization. Having that time horizon helps establish the principle of small, quick, steps rather than trying to develop some kind of implementation plan.

It is important to set an actual date, not just “in two weeks” – in two weeks from when?

But here is the most important part: Once the date is set, don’t change it.

If the date comes up, and the target condition hasn’t been reached, it is very tempting to say “Just a few more days.” But once a date is slipped, the date means nothing, because it can be slipped again.

Instead, missing the date is time to step back, reflect, and go back through the steps of the improvement kata.

This is the same thing you should do when you hit your target condition.

If you hit your target way early, or miss the date, it is also time to reflect on what you didn’t understand about your current condition when you established that target. Then:

  • Confirm understanding of the direction and challenge.
  • Grasp the current condition. This is important. Don’t just assume you know what it is. Take the time to do some observations and confirm everything is working the way you think.
  • Establish the next target condition. This means erasing the old target condition, starting with a clean obstacle sheet, looking at the current condition and establishing a new target condition. I would discourage you from simply re-stating the old one. List the obstacles that you think are now preventing you from reaching the new target.
  • Pick one obstacle (an easy one, not the one you were beating your head on for the last two weeks!), and design your next experiment. Start your PDCA iteration.

Coaches: Don’t let your learner just adjust the date. There is a learning opportunity here, be sure to capitalize on it.