How Do You Measure Toyota Kata?

I’ve run into a couple of cases where there is an initiative from a corporate continuous improvement team to “implement Toyota Kata.”

Aside from trying to proscribe each and every step of the way (which runs counter to the entire point of discovering the solution – “you omitted step 7b”), they also expect reports of metrics related to the “implementation.”

Things like:

  • Number of coaches.
  • Number of coaching sessions.
  • Number of active improvement boards.
  • Scoring learners on a dozen or so categories of specific attributes for their coaching session.

Then there are bureaucratic reporting structures demanding that this information (and much, much more) get dutifully filled in and reported up to the continuous improvement office so they could monitor how each site is progressing (often from across an ocean).

I’ve seen this before.

I’ve seen companies try to count kaizen events, and quantify the improvements for each one to justify the payback of the effort.

Similarly, I’ve seen top-level corporate leadership teams struggle to determine how to measure, at a glance, whether a site was “doing lean” to get their results (or getting the results by some other means(?) that were less appropriate).

I’ve seen companies try to manage quality by having the quality staff prepare and submit elaborate monthly reports about what was, and was not getting done based on what they felt was important.

I lump all of this under “management by measurement.” I think it is often a substitute for (1) trusting middle management to tell the truth and (2) actually talking to people.

What’s The Alternative?

First we need to work out what we really want people, especially middle managers, to actually do. What would full participation look like if you saw it?

For example, one company I work with has had a problem where middle managers send their people to internally run “kata training,” then say they have no time to coach their people, give them ambiguous or shallow challenges to work on, and generally look at the training as someone else’s responsibility.

OK, what do you want them to do?

In their book Switch, Chip and Dan Heath talk about “scripting the first moves” so someone who is unsure how to begin doesn’t need to expend limited psychological energy figuring out how to start. We want to get them going. We don’t need to lay out the entire process (that will end up being different for everyone) but we can create some clear rules or guidelines for getting started.

From the Switch Workbook on the Heath Brother’s web site:

Be clear about how how people should act.

This is one of the hardest – and most important – parts of the framework. As a leader, you’re going to be tempted to tell your people things like: “Be more innovative!” “Treat the customer with white-glove service!” “Give better feedback to your people!” But you can’t stop there. Remember the child abuse study [from the book]? Do you think those parents would have changed if the therapists had said, “Be more loving parents!”  Of course not. Look for the behaviors.

Asking that question, in terms of what they would actually see their middle managers doing, we came up with three general actions:

  • Work with their learner / improver to establish a clear challenge for them.
  • Commit to regular coaching cycles with their improver.
  • Commit to receiving 2nd level coaching during those sessions (so they can learn as well).

The question then becomes what mechanism can the organization put into place to encourage that behavior vs. just sending people to the class and not following up in any way.

It is easy to tell people what they shouldn’t do. It’s a little tougher to tell them what they should do.

In this case, we discussed establishing prerequisites for sending someone to the class. But these prerequisites are for the organization sending the participant to the training, rather than just the person attending the class.

It is the sponsoring manager who must commit (perhaps even in writing) to ensuring there is an improvement challenge; to establishing a regular coaching cycle; and to welcoming 2nd level coaching.

Perhaps this would be a commitment to the advance team who becomes a bit of an admissions committee – ensuring the support structure is there before we commit to taking someone on in the class.

We discussed taking a copy of the organization chart and putting dots on it where they had active improvement boards and coaching relationships. That would highlight which organization groups were developing their own people and which ones were doing less of it.

We discussed inviting the middle managers who have sent people to the class but, today, are not supporting, to come to the advanced team with a plan – perhaps a similar commitment – for their renewed participation. But no one would be required, because you can’t force anyone to learn something. Put your energy toward the people who want to learn. Trying to get participation from people who don’t want to do it just frustrates everyone.

And finally, create a mechanism for someone inside a non-participating organization to raise their hand and ask for help with their own development. Don’t punish the entire organization because their boss won’t play.

Now you are talking about mechanics, about actions that have testable outcomes: Experiments that can be set up and tried, improved, and iterated in the direction of something that works for your organization.

It is more work than just measuring people. And it doesn’t work every time. But it works more often than something that never works.

A Tale of Two Sites

With apologies to Charles Dickens, but the opening line is just too good to resist…

The Best of Times

In this plant, the advance team is chaired and actively led by the most senior manager on the site. He is actively coaching, he is actively being coached. He is questioning his own learning, seeking council, and acting on it.

They are clear that, while there may be general guidelines, they must learn by trying and experimenting. They cannot simply deploy a roadmap because they can only see the next mile on a 1000 mile journey.

They see it as a method to shift their culture away from its “tell me what to do” legacy and toward one of an empowered workforce that takes initiative and works on the right things, the right way.

There is no doubt among the leadership team that this is the path forward.

They are starting to apply the language of the Improvement Kata informally in their meetings and discussions.

Overall, it seems a bit messy. But learning is like that.

The Other Site

The “implementation of Toyota Kata” is a directive from the corporate Continuous Improvement team.

The corporate team spends much of their energy developing and deploying templates, PowerPoint presentations, setting standards for the forms and the layout, lettering and colors on the improvement boards, and setting milestones.

They have published a step-by-step procedure for a site to implement Toyota Kata, based on their assumptions of what ought to work. None of them has actually led a change like this.

They are, in turn, working through the site continuous improvement team who is expected to execute to these standards.

The site leader receives weekly reports on progress. Training the managers and “implementing Toyota Kata” is the responsibility of one of the site’s continuous improvement staffers. The site leader questions him using the 5 Questions each week, and issues direction in response to the answers.

It is the continuous improvement practitioner who is responsible for motivating the members of the management team to challenge their own processes and develop their improvement boards. A significant number of them are questioning the need or purpose of this exercise.

Thoughts

Unfortunately I run into the second case far more often than I see the first. But the story is decades old. That is how we did Six Sigma, kaizen events, Theory of Constraints, Total Quality Management. In each case we have separated the deployment of a core change in the way we manage operations from the responsibility for actually managing.

It

doesn’t

work.

This TED talk by Tim Harford actually sums up the difference pretty well:

But beyond what works, and what doesn’t, we also have to ask “Which approach is respectful of people?”

What are the underlying assumptions about the people at the gemba when “standards” are established thousands of miles away, published, and then audited into place?

Why do they feel they must tell people exactly what to do?

What do they feel is lacking on the site?  Competence? or Clarity?

Shifting Perspective from Getting Results to Developing People

Note: This post has been in my “Draft” queue for a few months, so actually pre-dates the previous one. But I’m seeing a theme developing in what I am paying attention to lately.

Taken from an actual conversation.

“What is your target condition?”

“To get [this productivity metric] from 60% to 85%.”

(thinking) – he is only talking about the performance metric.

“How would the process have to work to achieve that level of performance?”

(pointing to process flow diagram) “We have two work flows. One for routine project work, the other is high-priority emergent work. Whenever a worker has an opportunity to take on routine project work, I want him to be able to take the next most important job from the prioritized work queue.”

“This would eliminate the need for the worker waste time trying to find me to get an assignment or investigate or guess what he should do next, and let him get started right away. It would also stop cherry picking the easier jobs”

“My goal is for the Team Leader to establish those priorities, and keep track of how work is progressing.”

(thinking) – OK, I see where he is trying to go. I’m not sure I would have taken this exact approach, but it looks good enough right now to let him run with it and see what he learns.

“What was the last step or experiment you completed?” (Note: I am trying asking this question with ‘you completed’ so emphasize I want results from the last one, not information about what is ongoing or next.)

“Before I went on vacation, I looked at the incoming work queue, and established priorities for that work. As the workers needed their next job, it was clear to them what they needed to do.”

“What result did you expect?”

“I expected my productivity metric to hit my 85% target.”

“What actually happened?”

“The metric did hit the 85% target, when I prioritized the work. Then I went on vacation, and as you can see here (pointing at the graph), the productivity dropped back to its baseline level.”

“What did you learn?”

“I learned that when I set the priorities, and track the productivity, it improves as I expected it to. I also learned that when I don’t do it myself, then things go back to the way they were.”

“What obstacles do you think are preventing you from achieving your target condition?”

“People don’t know what the most important job is.”

“You said your target condition is for your team leader to make those assignments. How does that obstacle relate back to your target?”

“My team leader doesn’t know what the most important jobs are.”

“How about writing that down on the obstacle list.”

(he adds it to the list)

“Any other obstacles?”

“Um… I don’t think so.”

(thinking) I’m pretty sure there are other issues, but he seems focused on this one. Let’s see where he is going with it.

“OK, so that (the team leader) is the obstacle you’re addressing now?”

“Yes.”

“OK, what is your next step?”

“I am going to assign the priorities myself.”

“What result do you expect?”

“I expect the performance to go back to its target value.”

“How is that addressing the fact that your team leader doesn’t know how to assign priorities?”

pause…

(thinking) He isn’t connecting the dots here.

“Let’s come back to your target condition. You said you want the team leader to do all of this, rather than you, right?”

“Yes.”

“What is keeping you from just giving him the work and having him do it?”

“If I did that the productivity would go down again.”

”How come?” (Yes, I am leading the witness here. My thinking is that if I can get the right words to come out of him, he’ll “get it.”)

“My team leader doesn’t know how to set the priorities.”

“Right, so that’s the real obstacle in the way of reaching your target of having him do it, right?”

“Yes, but if I have him do it, then my productivity will go down. Isn’t the idea to hit the goal?”

“Yes, but you said in your target condition you wanted to hit the goal by having your team leader set the priorities, not just do it yourself.”

pause… (he’s probably feeling a little trapped now.)

(continuing) “So, if your team leader did know how to set the priorities, you think you’d hit your productivity goal with him doing it, right?”

pause…

“What else might be in the way?”

“He (the team leader) doesn’t like to go and talk to managers in other [customer]departments about their work priorities.”

“Write that down. Anything else?”

“He sometimes is reluctant to give assignments to people who would rather be working on something easier [but less important].”

“Write that down. Anything else?”

“I don’t think so. It sounds like the team leader is the problem.”

“You remember the session we did about David Marquet, the submarine captain, right?”

pause… “yeah.”

“So is this an issue with his (the team leader’s) competence – something you need to teach – or clarity – something you need to communicate?”

“I guess I need to teach him how to set the priorities.”

“So that is still the obstacle you are addressing now?”

“Yes.”

“OK, so what step are you going to take first?”

and from here, the conversation took a 90 degree turn into how this manager was going to develop his team leader.

The target condition got clarified into the capabilities and information the Team Leader needed to be able to perform the job competently.

The obstacles turned into things which must be taught, and things which must be communicated.

In retrospect, the obstacle I was addressing was reluctance on the Manager’s part to accept that developing the team leader was nobody’s job but his. But I’m finding that to be a common theme in a few places.

Coaching: Getting Specific, Finding the Knowledge Threshold

When coaching, I often find improvers / learners who tend to be superficial or vague about target conditions, current conditions, the experiments they intend to run, the results they expect, what they learned.  Huh… I guess I should have said “vague about everything.”

As several of my clients would tell you, one of my themes is “drive out ambiguity.”

Recently I’ve been trying a simple follow-up question that seems to be working to help people dig a little deeper without pushing them back as much as other questions might.

“Could you be more specific?”

I will plead completely guilty to stealing this from an unlikely source.

In his book “The Cuckoo’s Egg“, Clifford Stoll describes a line of questioning during his oral defense of his PhD thesis in astronomy:

I remember it vividly. Across a table, five profs. I’m frightened, trying to look casual as sweat drips down my face. But I’m keeping afloat; I’ve managed to babble superficially, giving the illusion that I know something. Just a few more questions, I think, and they’ll set me free. Then the examiner over at the end of the table – the guy with the twisted little smile – starts sharpening his pencil with a penknife.

“I’ve got just one question, Cliff,” he says, carving his way through the Eberhard-Faber. “Why is the sky blue?

My mind is absolutely, profoundly blank. I have no idea. I look out the window at the sky with the primitive, uncomprehending wonder of a Neanderthal contemplating fire. I force myself to say something—anything. “Scattered light,” I reply. “Uh, yeah, scattered sunlight.”

“Could you be more specific?”

Well, words came from somewhere, out of some deep instinct of self-preservation. I babbled about the spectrum of sunlight, the upper atmosphere, and how light interacts with molecules of air.

“Could you be more specific?”

I’m describing how air molecules have dipole moments, the wave-particle duality of light, scribbling equations on the blackboard, and . . .

“Could you be more specific?”

An hour later, I’m sweating hard. His simple question—a five-year-old’s question—has drawn together oscillator theory, electricity and magnetism, thermodynamics, even quantum mechanics. Even in my miserable writhing, I admired the guy…

[Emphasis added]

As you can see from Stoll’s experience, his professor was seeking to find his knowledge threshold – something a kata coach should be doing as well.

Now, I’m not going to push the “5 Whys” quite as deep as quantum effects (except, perhaps, at one client who DOES deal with things at that level…), but I find this is a far more effective question than “Why?” or asking leading questions. It, obviously isn’t universal, but it has been working reasonably well with a client whose corporate culture drives indirect assertions and vague predictions.

Try it… leave a comment if it works for you (or bombs). But please… be specific.  🙂

P.S. – In this video, Cliff Stoll tells the same story, likely more accurately, and makes another valuable point:  “It’s obvious” is a statement which often hides limited understanding of what is being discussed. It might be “obvious,” but… let’s go see.

Eiji Toyoda 1913-2013

Reuters reports the death of Eiji Toyoda today, 3 days after his 100th birthday.

In the late 1940’s, the fledgling Toyota Motor Company was in financial difficulties, and was forced to lay off workers. As part of the agreement, Kiichiro Toyoda resigned in 1950 and turned the helm of the company over to his cousin, Eiji.

Kiichiro had developed the early concepts of Just In Time production, and his father, Sakichi, had developed the early concepts of stopping a process that was having quality issues (jidoka).

Eiji had to deal with a turnaround situation, and challenged the company to reach U.S. levels of productivity on a very short timeframe. As part of that effort, he assigned Taiichi Ohno, a machine shop manager, to make it all work. The result was what we today call “The Toyota Way.”

Though there were obviously many people involved, Eiji has a huge share of the credit for creating “The Machine that Changed the World.”

Checklists: “Do.” vs. “Did you do?”

When operations or steps get omitted, a common countermeasure is to establish a checklist.

A typical checklist has a list of items or questions – sometimes even written in the past tense.

“Was the _______?”

There are a couple of common problems with this approach.

First, the time to actually, physically make the checks is not included in the planned cycle time. This implies we are expecting the team member to review the checklist and remember what she did.

The second issue is that the team member often does remember doing it even if it wasn’t done.

This is human nature, it isn’t a fault or flaw in the individual. It is impossible to maintain continuous  conscious vigilance for any length of time. There are techniques that help, however they require some discipline from leaders.

Overall, a checklist that asks “Did you___?” in the past tense is mostly ineffective in practice.

We make things worse when the checklist is used as a punitive tool and we “write up” the team member for signing off on something that, actually, didn’t get done. Most of the time it does get done, but everyone in this system occasionally misses something. Sometimes those errors get caught. This kind of “accountability” is arbitrary at best.

Where checklists work is in “what to do next” mode – referring to the check list, doing one item, checking off that it was done, then referring to the next item on the list. This is how it works in an airplane cockpit.*

CAPTAIN: okay, taxi check.

FIRST OFFICER: departure briefing, FMS.

CAPTAIN: reviewed runway four.

FIRST OFFICER: flaps verify. two planned, two indicated.

CAPTAIN: two planned, two indicated.

FIRST OFFICER: um. takeoff data verify… one forty, one forty five, one forty nine, TOGA.

CAPTAIN: one forty, one forty five, one forty nine, TOGA.

FIRST OFFICER: the uh weight verify, one fifty two point two.

CAPTAIN: one fifty two point two.

FIRST OFFICER: flight controls verify checked.

CAPTAIN: check.

FIRST OFFICER: stab and trim verify, thirty one point one percent…and zero.

CAPTAIN: thirty one point one percent, zero.

FIRST OFFICER: the uh…. engine anti-ice.

CAPTAIN: is off.

FIRST OFFICER: ECAM verify takeoff, no blue, status checked.

CAPTAIN: takeoff, no blue, status checked.

FIRST OFFICER ON PA: ladies and gentlemen at this time we’re number one for takeoff, flight attendants please be seated.

FIRST OFFICER: takeoff min fuel quantity verify. nineteen thousand pounds required we got twenty one point eight on board.

CAPTAIN: nineteen thousand pounds required, twenty one eight on board.

FIRST OFFICER: flight attendants notified, engine mode is normal, the taxi checklist is complete sir.

(This is also how it works when assembling a nuclear warhead, but I can’t tell you that.)

This is also very effective for troubleshooting. For example, I was working with a team in a food processing plant. The obstacle being addressed was the long (and variable) time required to change over a high-speed labeling machine and get it “dialed in” and running at full speed without stops and jams.

Some operators were much better at this than others. We worked to capture an effective process of returning the machine’s settings to a known starting point, then systematically adjusting it for the specific bottle, label, etc. It worked when they were able to slow down enough to use it. That was an instance of “Slow is smooth; smooth is fast.”

The act of reading out load, performing the action, and verbally confirming is very effective when it is actually done that way. Even so, people who are very familiar with the procedure will often take shortcuts. They don’t “need” the checklist… until they do.

Still, you have a sequence of operations, and it is critical that they are all performed, in a specific order, in a specific way.

What works?
I’d say look around.
If you are reading this, you likely have been at least dabbling, and hopefully trying to apply “lean” stuff for a while.

What is a basic shadow board? It is a “checklist” of the tools to confirm they are all there – and a lot faster because missing items can be spotted at a glance. At a more advanced level, companies move away from shadow boards and to having the visual controls outlining what should be where to perform the work.

Color coded tool holders.

If you kit parts, you can set them out in a sequence – a “checklist” that cues the team member what order they should be installed.

I could continue to cite examples, but here’s the point.

When things are being left out, there is a high temptation to say “Let’s make a checklist” and sometimes make it worse by saying “…and we’ll have the worker sign it off for accountability.” That is more often than not simply a “feel good” solution. You feel like you have done something, and I’ve even heard “Well, it’s better than nothing.” I’m not sure it IS better than nothing – at least not in very specific conditions.

Instead, you need to study the actual work. Don’t try to ask questions, just stand and watch for a while. (Explain what you are doing to the team member first, otherwise this is creepy. “Hi – I’m just trying to understand some of the things that might get in your way. Do you mind if I just watch for a while without bothering you?”)

What cues the team member which step to perform next? Does he have to know it from memory? Or is there something built into the way the workplace is organized?

Does he end up going back and doing things he forgot?
Does he set out parts and tools in order on his own so he doesn’t forget?
Does he get interrupted, by anyone or anything, that takes him out of his mental zone?
(I go through airport TSA security checkpoints at least twice a week. I have a routine. When the TSA agent tries to “help” by talking to me, my routine gets broken, and that is when I forget stuff.)

If you are coaching someone, it helps if you go there with them, help the see the details by spotting these things and “asking” about them; then taking them to another area and challenging them to see as many of these issues as they can. See who can spot more of them.

What you are seeing are obstacles that impact the team member’s ability to do quality work.

Checklists don’t help remove those obstacles.

___________________

*The checklist transcript here is a cleaned up version of the Cockpit Voice Recorder transcript from Cactus 1549, the US Airways A320 that successfully landed in the Hudson River after multiple bird strikes knocked out both engines. I used it here because it is authentic, and the accident was one where everything went right and no one was seriously injured.

Shifting the Learning Zone

A client and fellow lean learner today shared a cool extension of the Toyota Kata model for establishing target conditions.

Mike Rother’s Improvement Kata Handbook establishes a couple of key concepts about where a target condition should be set. The key is that the target should be somewhere beyond the learner’s knowledge threshold:

image

The knowledge threshold marks the point where the process is not yet fully understood. Setting a target inside that boundary is simply a matter of executing a plan, no learning is required.

A target beyond the knowledge threshold is true improvement, because we don’t know how to do it yet. We just have a reasonable belief we can get there.

This is the concept of challenging the learner, depicted here:

image

Here is another way to look at it – thanks to Matt – though I have altered the geometry a bit here.

image

In the “Comfort Zone” we are, well, comfortable. This is the daily routine, things are predictable. As our brains are wired to seek predictability, most people seek out activities they already know how to perform.

Beyond the knowledge threshold is the “Learning Zone.”

We know from the principle of Deep Practice that skill only develops when we are striving to perform just beyond the limit of our capability – on the edge of failure.

It a zone where small mistakes can be made, realized quickly, and corrected immediately for another try.

If, though, we ask someone to do something that he perceives carries a high risk of failure, he enters the “Fear Zone.”

The boundaries for these zones are individual, and are a mix of the person’s skill and knowledge base + his tolerance for risk.

What I like about this model, though, is that can be extended.

Our brains are incredible simulation machines. We can imagine an activity or event, and feel the same emotional response we would have if it were real.

But we have a heavy, survival based, bias for loss avoidance. Simply put, we have a stronger drive to avoid loss than we do to seek reward. This is why people hold on to investments that are tanking, and remain in bad jobs and unhealthy relationships. The predicted sense of loss is actually stronger than what would actually be felt.

This explains the seemingly backward effect of high stakes incentives that Dan Pink talks about in his book Drive and in this TED Talk. (Skip ahead to 1:50 to get to the main points.)

If the leadership climate sets up fear of loss as a consequence of failure, we have a very strong force pushing the boundary of the fear zone to the left:

image

But what we want to do is, over time, shift the learning zone to the right. That is, the team member is comfortable in increasingly complex situations – her skill levels for dealing with the unexpected are much higher.

So how do we get there?

image

We can look at the highest performing people, and look at the social support networks that nearly all of them have.

If you want performance, you have to (1) remove fear and (2) provide safety for experimentation and learning.

One final note – changing the culture of an organization is not easy, and the appropriate tools to do so are highly situational. You can’t just say “You’re empowered” and expect a transition. More about that in a few days.

PDCA, A3 and Practical Problem Solving

Over the years, I have been party to at least three corporate-level efforts to bring “A3” or “Practical Problem Solving” into their toolbox. Sometimes it has other names, such as “Management by Fact” or such, but the approaches are all similar.

Typically these efforts, if they catch on at all, become exercises in filling out a form.

Actually, that shouldn’t be a surprise, because they are often taught that way – as process of filling in boxes in sequence, with a “module” for teaching each step.

Worse, it is often taught as an intellectual exercise, and once you are done with the three day class, you’ve been “taught.”

The various classes mention PDCA as being a crucial part of this process, but nobody really practices it.

People are sometimes taught that this process should be coached, but the “coaching” they get is typically organized as management reviews via PowerPoint.

The “problem solving team” shows their analysis and their “implementation plan” that is a list of tasks, and a timeline to get them done. The meetings become status reviews.

Sometimes the “coaches” offer suggestions and speculation about the problem, symptoms, or actions that might be taken. They rarely (if ever) get into the quality of the PDCA thinking.

This is one of the challenges we have in the west (and especially in the USA) where our culture is more one of “go it alone then get approval” rather than true teamwork with the boss. This often turns the “A3” into an exercise of getting approval for a proposal rather than a learning process.

Worse, it does nothing to teach the problem solvers to be better problem solvers.

Note that sometimes an A3 is used for a proposal, but the process of creating it is still coached, and part of the process is the consensus-building that happens before there is any meeting. But here in the west, we still seem to like to spring these things on a leadership team without a lot of that background work ahead of time.

Mike Rother and the “Toyota Kata” community have been discussing this gap lately, and working to close it.

The latest iteration is this SlideShare that Rother sent around today:

He clearly points out what people have been missing: The “A3” is really just another method to document the “improvement kata.”

The “Implementation” box, rather than representing an action item lists, is where the problem solver captures her PDCA cycles, what is being tried, what is being learned, as she drives toward the target condition.

The other boxes are capturing her understanding of the current condition, the target condition, and the impact of various problems and obstacles in the way of closing the gap.

One thing that makes this extraordinarily difficult: We are talking about more than the mechanics of problem solving here. We are talking about shifting the default, habitual structure of the interaction between people. That is culture, which is notoriously hard to change. Not impossible, but unless people are up front that they are actually trying to change at this level, there are a lot of obstacles in the way. This can’t be delegated.

Eliminating Key Points

TWI Job Instruction is a structured process for breaking a job or task into teachable elements, and a 4 step process for teaching that job to someone.

I am not going to try to explain everything about breaking down a job here, this post is primarily for people who use job breakdowns and job instruction already.

The process of breaking down a job involves:

  • Identifying the Important Steps – the sub-tasks that materially advance the work.
  • Then identifying Key Points within important steps. These are things which the team member must pay special attention to, or perform a specific way. The guideline is that a key point is something which:
    • Is a safety issue – could injure the worker, or someone else.
    • Would “make or break the job” – critical to quality or the outcome of the work.
    • Is a “knack” or special technique that an experienced team member would use to make the job easier to do.

Breaking down a job this way takes practice, but it is a great way to identify the elements that are critical to safely getting a quality job done, and ensuring that the team member understands them.

But I want to propose this is only the first step.

Every key point is something the team member must remember in order to to not get hurt (or hurt others); to avoid scrapping or damaging something; to perform at the level you need.

Take it to the next level.

Think of these key points and the training that they drive as temporary countermeasures.  They are stop gaps you have in place until you can do something more robust.

Take one key point at a time. Why is it necessary? Why is it possible to do this step any way but the best way?

Can you alter the work environment – the product, the process, the equipment, the visual controls to reduce the things the team member has to remember (and you have to remember to teach)?

Can you make it impossible to perform that step in any way other than the way it should be done?

If you can’t, can you make it impossible to proceed until the error is corrected, before any harm is done?

If you can’t, can you make it so obvious that it is impossible to miss?

If you can’t, can you put in a robust reminder? (Signs and placards generally DON’T WORK for this unless they are especially “sticky.”

Every key point is something you have identified as critical to doing the job directly. Therefore every key point should drive a focused effort to mistake-proof the work.

You want to have as few as possible… but no fewer.

The Value of Mistake Proofing

Most companies use some version of the words “respect for people” in their HR mantras. But how is that respect demonstrated?

A team member made a mistake today. He is building a sub-assembly on a mixed model line. He picked a part from a small blue bin with a divider in it.

On one side of that divider is the part he should have picked and installed.

On the other side of the divider is a very similar part.

Guess which one ended up in his hand?

The issue wasn’t caught until a couple of positions down line. When it was caught, it was quickly reworked and corrected.

This particular team member is coming up on the end of his 90 day probationary employment period.

He has seen co-workers who “didn’t make it” (not cut out for assembly work). But he is a smart guy, hard worker, has participated in a lot of improvements for the work he is doing.

Nevertheless, he is worried about the consequences of making this mistake so close to his 90 day evaluation. He just wrote, it seems, what he hopes is his last COBRA check* that will cover him and his wife until his health insurance kicks in at the end of the month.

What is the value of mistake-proofing this operation?

Actually, the consequences of this error are minor. It is easily caught and quickly corrected in a subsequent operation. It is very, very rare. You could make the argument that there are better returns spending the limited problem solving time on bigger issues, and you’d be right… to a point.

But what if this team member’s experience was to see attention focused, not on him, but on what it was about the layout of the work area, about the presentation of parts, about the structure of the work, made it possible to make this error.

What if they acknowledged, overtly, that this kind of mistake is a consequence of being a human being, and that it was only that he happened to be the one standing there when the random chance generator came up?

What if he saw the team leader and supervisor engage him in conversation about what might be done to at least eliminate some of those possibilities? (We don’t really know what happened, though there are some likely guesses.)

What if he was also asked to look for other similar error opportunities, even in his co-worker’s areas, and help eliminate those as well?

What would be the return?

Might this team member work just a little harder to make things even better in the future?

Maybe he would help turn around a cynical or skeptical co-worker.

Maybe he would feel a bit appreciated for what he is contributing instead of losing sleep about his job.

Maybe, at some point in the future, when he is a shop steward, he might remember that “they” are all to human as well.

Who knows.

Before you say “it isn’t worth it” remember what Deming pointed out – “Management’s real job is to manage the unmeasurable.”

Good news – in this (real life) case, they are, for sure, eliminating the split bin and separating the two similar parts from one another; plus likely separating two other bins holding similar bolts. Maybe more, there are some ideas being kicked around.

In the end, though, consider if you will the ROI on team members knowing you will support them in their quest to succeed every day.

*For my non-US readers: COBRA is a program where someone can continue employer-provided health care after termination of employment for up to 18 months by paying the cost yourself. This is sometimes cheaper than purchasing private health insurance.