Do Your People Solve the Problem or Work The System?

This article by Anita Tucker and Amy Edmondson at Harvard highlights a problem that is as common on the manufacturing floor as it is in the hospitals they studied:

When people encounter a problem that stops their work, they work the system, get what they need, and continue their work.

A lot of people call this initiative, and most organizations reward this behavior. Many of those organizations have actual or implied negative consequences for bringing up an issue that “you could have solved yourself.” Unfortunately this behavior only accomplishes one thing: It guarantees that the problem will occur again.

What is the big deal? Simple. Small problems accumulate. They do not go away, and more come into play every day. Eventually the Team Members are overwhelmed by “too much to do.” Supervisors press for “more people,” the organization grows in size, and the cycle continues. In health care all you have to do is spend an hour talking to harried nurse to know all of the things that keep them from providing patient care.

Go stand in the chalk circle on your own shop floor. What things keep your Team Members from doing their jobs?

Standards Protect the Team Members

One of my kaizen-specialists-in-training just came to me asking for help. The Team Members he is working with are not seeing the need to understand sources of work variation.

I hear that a lot, both in companies I have worked in and in the online forums. Everyone seems to think it is a problem in their company, their culture – that they are unique with this problem.

The idea of a unique problem is variation on the “our process / environment / product is different so ____ won’t work here.” Someday I will make a list of the standard management “reasons why not” but that isn’t the topic of this post.

I told him:

  1. This is not unique to China, or to this facility. The same resistance a always comes up, and nearly always comes up the same way once the Team Members begin to realize we are serious.
  2. There is no way to just change people’s minds all at once.

Here is something to explain to the concerned Team Members: The standard process is there to protect the team member. If there is a problem, and the standard process was followed, then the only focus for investigation can be where the process itself broke down. Countermeasures are focused on improving the strength of the process.

If, on the other hand, the process was not followed (or if there is no process), then the team member is vulnerable. Instead of the “Five Why’s” the investigation usually starts with the “Five Who’s” – who did it? Countermeasures focus on the individual who happened to be doing the work when the process failure occurred.

As you introduce the concept of standard work into an area that is not used to it, it is probably futile to try to tighten down everything at once. The good news is that you really don’t have to.

Start with the key things that must be done a certain way to preserve safety and quality. If they are explained well and mistake-proofed well, there is usually little disagreement that these things are important.

The next step is to make it clear that the above are totally mandatory. If anything gets in the way of doing those operations exactly as specified, then STOP. Do not just work around the problem, because doing so makes you (the Team Member) vulnerable to the Five Who’s inquisition.

If you focus here for a while, you will start to get more consistent execution leading to more consistent output, which is what you want anyway.

Then start looking at consistent delivery and all of a sudden the concept of variation in time comes into play. Why was this late? The welder ran out of wire, I had to go get some more, I couldn’t find the guy with the key to the locker…… Go work on that. At each step you must establish that the point of all of this is to build a system that responds to the needs of the people doing the work.

Don’t Lose Sight of “Why”

I just finished responding to a post on lean.org where the poster was struggling a bit to justify moving two sequential operations together vs. the proposed simple solution of adding conveyance from one to the other. I thought it would be worth a bit to think that through.

In a previous post “Sticky or Slick”, I admitted struggling a bit myself trying to capture the “lead story” of the Toyota Production System, the one sentence core principle that could guide decisions. I still think it is close to “Structuring the organization and the work environment to harness people’s creativity to save time.

Let’s apply that logic to this situation. Now obviously I have not seen this operation myself, so I have no idea about the work breakdown, the cycle times, the nature of the work elements, so I am going to make up opportunities that illustrate the point.

I believe the key point that gets lost here is that, in 99% of the cases, you are not moving operations closer together. You are moving operators together. You are improving material flow with the purpose of creating better people flow. The TPS is about people. Specifically, it is about organizing the work and the work place so the people can make improvements that save time and make a difference.

If two operations operators team members who are performing sequential operations are separated in space or time, then although each can work to improve her own individual work, the results don’t pass the “so what?” test. “I reduced my work cycle from 10 minutes to 7 minutes.” So what? Now you are idle for 3 minutes. You still need to be there. And it is usually beyond the technical wherewithal of a shop floor team member to automate himself completely out of a job. Since they cannot reduce cycle time to zero, there is no net difference.

But now you have a problem to solve:
This person is idle (the waste of waiting). What must I do so he has meaningfully work?

Changing the layout is now the obvious countermeasure.

To turn this “problem” into true kaizen, create or improve flow by placing those two operations very close together. Now the magic happens. As each team member works to save time (or as they work as a team), they can also continually re-balance their work so at least one of the two is still loaded close to the takt time. Eventually they reach the point where one of them can perform both operations, freeing up the other. Even if this does not quite happen, by always consolidating the wait time onto one person, that person can take on more tasks assuming they are within reach. If they are not within reach, then move them closer together and facilitate more kaizen. Changing the layout is a countermeasure, not the objective. It is a countermeasure to the problem – the waste of waiting.

The “why” of putting things close together is to give the workers the power to improve their own work and the total flow of the system. The side-benefit of doing this is that you reduce inventory and save time. People’s time, throughput time.

Structure the work and the work place so the people who do the work have the opportunity to improve the system in a meaningful way.

The cycle of kaizen:

  • Attack overproduction so other wastes are revealed.
  • Convert other forms of waste to the “waste of waiting.”
  • Adjust the work balance, and then the physical flow to eliminate the waste of waiting.

If you do it in the other order – attack the waste of waiting first, the only way a team member can remain busy is through overproduction… and overproduction is bad. Very bad.

and.. after a couple of months and several dozen posts I finally added the category “kaizen” for this one. I am not sure why it took so long.

The 3 Elements of “Safety First”

When we talk about safety, most people consider the context of accidents and injuries. But if we are to achieve a true continuous improvement environment, where everyone fully participates, we have to consider more.

A good way to sum it up is with three elements that all start with ‘P.’

1) Physical Safety

This is what most people think of when we say “safety is the most important thing.” But, aside from the moral, legal and financial imperatives, what are some other reasons why physical safety is important?

Simple. We want our Team Members 100% engaged in performing their work and improving it. We do not want any of their precious mental bandwidth consumed by worrying about whether or not they will get hurt.

This is a far cry from the “blame the victim” approach I have seen. Root Cause of Accident: Team Member failed to pay attention. Countermeasure: Team Member given written warning.”

A few years ago I was painting my house. I will tell you right now that I am not fond of ladders. (Go figure, I spent three years in the 82nd Airborne, you’d think I would be over it.) There I was up near the top of an extension ladder painting the eaves of the roof. I can tell you that I was paying a lot more attention to staying on the ladder than to where the paint was going. The quality of the job suffered, for sure.

The truth is that a physically safe environment is more, not less, productive. Ergonomically bad motions take more time than good ones. Well designed fail-safe’s and guards prevent quality issues and rework. An even, sustainable pace of work reduces disruptions upstream and downstream. Good lighting lets people catch quality issues and mistakes sooner. Reduced noise levels foster communication. High noise isolates people in invisible bubbles.

2) Psychological Safety

Can your Team Members freely share problems and ideas free of concern for ridicule or rejection by their co-workers? Or is it safer for them to keep to themselves? Do you know who the natural leaders are? Do you know who the influencers are? Do you know who the bullies are? Do you know which line leaders people are afraid of? Which co-workers? Don’t kid yourself, it is only the truly exceptional team that does not have these issues. And most teams that move past these issues become truly exceptional. It is something called “trust” but that is just another way of saying “feeling safe being vulnerable.”

3) Professional Safety

This is a deceptively simple concept. The Team Member is not put in fear (real or implied) of losing his job for doing what is expected of him. That sounds so simple. The really obvious example is the Team Member being asked to contribute to saving cycle time (and therefore, labor) when he knows unnecessary people lose their jobs. But it goes further.

How often do we expect, by implication, people to short-cut The Rules in order to get something done more quickly? Sidney Dekker has authored a number of books and publications focusing on human error as the cause of accidents. One of his key points is that within any organization there are The Rules, and a slightly (sometimes greatly) lower standard of the norms – the way people routinely do things. The norms are established by the day-to-day interactions and the real and implied expectations placed on people to get the job done.

Well meaning Team Members, just trying to meet the real or perceived pressures of everyday work take shortcuts. They do it because they feel they must in order to avoid some kind of negative consequence.

At this point you can hopefully see that these three elements blur together. The work environment and culture play as much a part in a safe work place as the machine guards and safety glasses.

All of these things, together, set the tone for the other things you say are “important” such as following the quality checks (when there is no time built in to the work cycle to do so), and calling out problems (when halting the line means everybody has to work overtime).

One more point – everything that applies to safety also applies to quality. The causes of problems in both are the same, as are the preventions and countermeasures. Do you use the same problem solving approach in both contexts? More about simplifying your standards sometime in the future.

Trust, Then Verify

This article NPR : Mattel Recalls More China-Made Toys highlights one of the problems with doing business with an unproven supply chain.

In this case, the OEM in China had specified the correct paint to their supplier – who was a friend of the owner – but the paint supplier had given them less expensive lead based paint. (Some friend, huh?)

As the story reports, the owner of the OEM company took the coward’s way out and hanged himself.

So – Mattel probably trusted that their OEM supplier in China would deliver what they specified (and would continue to do so after first article inspections). The OEM, in turn, trusted their paint supplier would deliver as specified. Now Mattel’s reputation is in recovery mode and China itself is internationally embarrassed. (Believe me, they do not like it when that happens. On second thought, maybe suicide wasn’t a bad strategy after all.)

The awful truth is that the world out there has people in it who either do not understand that a particular specification is important (which is pretty common here), or worse, are out to make more money (less common, but it happens).

Lean Thinking Question:
What would you learn from this if YOU were Mattel?

Think From The Customer’s Perspective

I was browsing my web email, and I saw an ad for web hosting. The ad was actually set out pretty well because I remember the two pieces of key information: Web hosting for $9.95 a month (free domain, etc.) and the prominent text on the ad: “Superpages.com”

Well, I suppose the ad authors can be forgiven if I didn’t click through the ad. Instead, I typed “superpages.com” into my browser.

The page so prominently called out in the ad carried not even a hint that superpages.com offers web hosting. And by now the ad was no longer displayed.

I typed “superpages” and “web hosting” into the search engine, and found a news article that repeated a 2005 press release. About 2/3 of the way down, it mentioned “my.superpages.com” so I tried that.

There is a mention on that page of web hosting, but it took two more clicks to finally get a page that mentions any details. I stopped at that point.

A couple of things come to mind here.

First – take the perspective of your customer, or better, find someone who doesn’t know the details or designer’s intent of your system and have them navigate it in unexpected ways. Just how many obstacles do you throw in front of the customer who wants to buy your product? How much digging must the prospective customer do in order to get basic information?

Second – and this is much harder – take the perspective of your competitor’s customer. Go buy their product. Experience what their customers experience. Don’t rely on market surveys, go and see for yourself. (“genchi genbutsu”)

What if:

Airline executives bought tickets through their own web site, rode in coach, and checked in just like everyone else – every time, not just as an experiment. They need to be a “frequent flyer” just like the very customers they are trying to retain. What if those same airline executives had to do 50% of their travel on competitor’s airlines? In coach, waiting in the same lines as everyone else.

Do you think it would be interesting for an executive of a prominent red-tailed airline to know that the “elite” line for check-in is much slower than the regular one? Or that they mix re-booking for a canceled flight in with first-class check-in and slow the process to a crawl? What would be that airline executive’s experience if he were to wait in line and just listen to his customers talk to each other? (He would hear the complaints nobody bothers to make because they think nobody cares.)

What would that airline executive’s experience be if he sat in the seat across from the flight attendant who lets all of the customers know what a terrible place his airline is to work. (I have had this experience twice, with the same flight attendant, but I fly a lot.)

What if Ford executives were directed to buy and drive….. Toyotas, and get them serviced at their local dealer just like everyone else. Would they learn anything? Not that Toyota is perfect, certainly their U.S. dealer network is pretty much just like everyone else’s. But that Ford executive might just find a weakness to exploit. What kind of car does Alan Mullally drive? What if auto executives had to buy their cars from heavy-handed closers just like everyone else?

But all of us frequent flyers can laugh about the airlines. What about your company? Do you really know what your customers experience?

Market surveys just don’t do this. They aggregate, consolidate, take averages, and generally dull the senses to what is really happening.

Go and see for yourself.

Hidden Negative Consequences

“Stop the line if there is a problem” is a common mantra of lean manufacturing. But it is harder than first imagined to actually implement.

The management mindset that “production must continue, no matter what” is usually the first obstacle. But even when that is overcome, I have seen two independent cases where peer social pressure between the workers discouraged anyone from signaling a problem. The result was that only problems that could not be ignored would come to anyone’s attention – exactly the opposite of the intention.

Both of these operations had calculated takt time using every available minute in the day. (Shift Length – Breaks etc.) Further, they had a fairly primitive implementation of andon and escalation: The line stop time would usually be tacked onto the end of the shift as overtime. (The alternative, in these instances, is to fall behind on production, and it has to be made up sometime.)

So why were people reluctant to call for help? Peer pressure. Anyone engaging the system was forcing overtime for everyone else.

Countermeasure?

On an automobile line, the initial help call does not stop the line immediately. The Team Leader has a limited time to clear the problem and keep the line from stopping. If the problem is not cleared in time, the problem stops the line, not the person who called attention to it. This is subtle, but important. And it gives everyone an incentive to work fast to understand and clear the problem – especially if they know it takes longer to clear the problem if it escapes down-line and more parts get added on top.

There are a number of ways to organize your problem escalation process, but try to remember that the primary issue is human psychology, not technology.

Be Sure: What Are You Trying To Accomplish?

And how will you know you have accomplished it?

This article on Tech Republic is about defense against a hacker strategy called “Social Engineering” wherein the hacker uses a ruse to gain someone’s trust. The goal (for the hacker) is to leverage human nature and get information or access.

So what does this have to do with lean thinking?

It emphasizes the nature of policies with unintended consequences. I have seen all kinds of environments where a Team Member would suffer negative consequences for doing the very thing required to assure safety, quality, delivery or reduce costs. Never happens in your company, right? The examples in the article are mainly in items (2), (3), and (4).

I especially like (4) where the hacker poses as a person in power and simply intimidates the Team Member into giving him the information he wants. What is the countermeasure?

Strict policies and procedures created to discourage this kind of bullying. If it’s allowed from management, someone engaging in social engineering will be able to employ it.

Think about it. If someone abusing his authority is normal behavior, then your Team Member will not be able to detect this condition something out of the ordinary.

In another context, if a Team Member is routinely told “We’ll fix it in inspection” or to otherwise ignore a defect and allow it to pass on, then he will quickly stop reporting them.

Think through the behavior you want people to exhibit. Then, study (stand in the chalk circle again) and see for yourself what the actual behavior is. If it is different than what you expect or what you want, start asking the 5 Why’s. What people do every day is the norm of your organization. It is the path of least resistance. If you want people to do something different, then you must make the right way the easiest way.

This accomplished by a combination of mistake-proofing, policies and procedures that support people who do the right thing, and continuous two-level checking by leaders to reinforce and encourage.

In Item (2) in the article, the author talks about the “I don’t want to get in trouble” excuse. In his example, there is a negative consequence for reporting a lost or misplaced ID badge, so everyone works to avoid reporting the problem. Perhaps the intent was to have people pay more attention. As Deming said, you must drive out fear, and this isn’t the way to do it.

Remember: The right process will produce the right results. Think:

What results are you trying to accomplish? How will you know you have accomplished them? (How will you check or verify your results?)

The more clear you are on the target condition, the better equipped you are to think through how you will achieve it. When dealing with people, it is easier than you think to build negative consequences for the very thing you want them to do.

Hoopla – Another Quality Story

As I said in a previous post, I am spending the majority of my time in China right now.

As part of his preparation for attending a corporate class, one of my kaizen specialists was reviewing some of the training materials. From the other side of the cubicle wall he asks “What is ‘hoopla?” Although his English is very good, he is Chinese, and “hoopla” just isn’t a word that they teach in the universities.

Now I know for sure he is not the first non-native English speaker to read that material, and I also strongly suspect many before him did not know what “hoopla” means. But the others just made a guess from the context and kept reading.

Derrick, though, applied the first two steps of jidoka – he Detected a problem – something wasn’t right, didn’t meet the standard, or seemed to be in the way. Then he Stopped the process, and called for assistance. Instead of guessing what to do, the Team Member pulled the andon (got his Team Leader’s attention) and pointed out the problem.

The standard in this case is that the person reading the material can understand it, or at least understand the words that are not specifically being explained by the material. In this case, that didn’t happen. “Hoopla” was not understood, so the andon was pulled.

The third step is Fix or correct the problem, restore the standard (without compromising safety or customer quality in any way) and re-start the process. I explained what “hoopla” means, and Derrick could keep reading.

The fourth step is Investigate the Root Cause, Apply a Countermeasure. I sent an email to our training developer and mentioned what has now become “the hoopla incident.” The ensuing discussion among the training developers has resulted in a set of standards and guidelines for writing materials. Among other things, it calls out the need to avoid idioms and slang that might not be understood by non-native speakers. It also addresses other issues which will both make the materials easier for non-native speakers to read and make it easier for translators working to port the material to German, French, Spanish or… Mandarin.

W e should have some hoopla! The process worked – all because someone called out something he didn’t understand instead of just dealing with it on his own.

A Quality Story

On a cloudy morning a few years ago I started my truck, turned on the headlights and noticed one of them was not working. While changing a headlight isn’t that big a deal, I needed a state safety inspection anyway, and I really didn’t want to mess around under the hood.

So I called the auto repair and tire place up the road, and arranged to come in.

When I got there, I explained that the right headlight was out. Since I knew from experience that the left one would probably fail in a few weeks, I said “Go ahead and change the left one too, and I need the state safety inspection.”

Unfortunately they only had one headlight in stock, so they couldn’t change both, I said OK and got a soda to wait.

A while later, everything was good-to-go, I drove back to work and went home that evening. The next day was sunny.

The following day, however, was cloudy again. I turned on the headlights in the garage, and the right headlight was still out. Hmmm. I took a quick look and noticed that the LEFT headlight was new. They had changed the wrong one.

When I got back to work, I called the shop, explained the issue, and they said come over and they would make it right. (Meaning they would replace the RIGHT headlight at no charge.) After handing the keys back in, the mechanic who did the work came out and tried to convince me that he had simply followed the instructions, and it wasn’t his fault.

OK — let’s break down this situation from the perspective of quality and delivery.

Starting from the end of the story, why did the mechanic feel obligated to try to convince me that I had responsibility for a mistake that the owner had already agreed to correct? What could possibly be gained by trying to make the customer feel wrong here?

Now let’s go back to the beginning.
Customer reports a headlight is out. What is the very first thing you would do? How would you confirm the problem?

Turn on the headlights and check. This takes about 10 seconds. If there was a confusing communication about the problem, this is the time to discover it.

Once the repair has been completed, how would you confirm that it worked?
Turn on the headlights and check. This would verify that the results were as intended. (What does the customer need here? Two headlights that work.)

The other item that was on the instruction was a state safety inspection. Now I am not an expert on the New York State safety inspection, but I am willing to bet at least a can of soda that it includes the headlights. So as part of that inspection, the mechanic should turn on the headlights and check.

Even if the problem had gone undetected up to this point, it should have been caught here. Obviously the “inspection” was just a paperwork drill in this case.

Of course, as the customer, I also failed to turn on the headlights and check when I picked up the vehicle. Silly me.

What is the point of all of this?

The first step of solving any problem is to understand or verify the current condition and compare it with your expectations or standard. (More about standards and expectations later.)

Once a countermeasure had been developed and put into place, the situation must be re-checked to ensure that the countermeasure worked as intended and the process or system is back to the standard condition.

Any process has some kind of intended result. In this case, the headlight repair process should result in two headlights that work. Yet the results were not verified, and the incorrect product was delivered to the customer.

So what did all of this cost?

It cost me my time.
It cost the repair place

  • Double the mechanic time.
  • A headlight +the time to go get one during business hours (because they had not replaced the one they installed on the left two days earlier).
  • Good will. (Later, when they failed to tighten the filter after an oil change, I stopped doing business there altogether. One mistake I was willing to overlook, but I was starting to see a trend developing. I also later had some extensive maintenance and repairs done on the truck, but I didn’t have them done there because I could not trust them to change a headlight or change the oil.)

By the way, I still have the truck. It is coming up on 200,000 miles and runs great.