“Why Don’t You Just…”

Most leaders will at least superficially agree that organizations with an aligned, empowered workforce are more effective; that decisions are faster when made at lower levels that are closer to the actual facts; and that work teams are the ones in the best position to improve their own processes.

Most would agree that they would prefer their people to take initiative to come up with the best way to solve a problem.

Here’s a quiz.

Take a look at this old photo (it’s real, not staged!), and try to imagine what you think day-to-day interactions with this commander would be like.

Now… answer this question:

How much day-to-day initiative do you think the four officers in this photograph would show when the boss isn’t right there?

What does he teach them to do when he is talking to them?

Why would we expect they would learn to do anything else other than what they are being taught in the course of those day-to-day interactions?

This is, of course, an extreme case, meant to make a point.

But listen to your day to day interactions with your own people.

Do you give them directions they are expected to follow? Those directions, by the way, can take very innocuous forms. They can be disguised as suggestions, “Why don’t you just…” or “Have you considered…?” as well as just being orders.

You can think you are “correcting” or “teaching” people when your language actually is communicating something quite different.

You are teaching your people every time you talk to them. They will answer the questions you ask. If you make a habit of overriding their ideas, they will learn to not bother to work very hard to develop those ideas. If you argue with them, they will quickly learn to give in, or even just wait until you make up your mind. Any time you are making declarative statements about what should be done you are eroding initiative a little.

Frankly, from their perspective, it is a lot easier to just wait for the boss to give direction and follow it than it is to take initiative. There is much less psychological risk and energy involved. And if the organization has a history of risk-aversion you have an uphill battle to begin with.

It only takes a few negative experiences to stamp out initiative.

A thought experiment:

You wish people would take more initiative, self-organize the right people to work on problems in your organization.

Someone is working on understanding a problem or improvement. They come to you with a fairly decent picture of the current condition, but their next step isn’t the one you think they should take.

You have an overwhelming urge to say “Why don’t you just…” and get to a workable solution fast.

If you do so, what have they just learned?

You cannot simultaneously maintain full control and develop initiative.

Creating an Empowered Team

EDIT: There is a follow-on post here: David Marquet: Turn the Ship Around

In the past couple of decades, we went through an “empower your people” fad. We saw work teams in world class companies that were largely self directing, surprisingly well aligned with the overall goals of the organization, and getting things done.

“Well,” we thought, “since empowered teams are obviously more effective, we’ll empower our teams.”

harry potter wandThey brandished their wand uttered some wizard’s chant, and bing! empowered their teams.

“What did you expect to happen?”

“We expected our newly empowered teams to self-organize, get the work done, plan all of their own vacations and breaks, and continuously improve their operations on their own.”

“What actually happened?”

“Work ground to a halt, people argued and squabbled, quality went to hell, and labor hours went up 20%”

“What did you learn?”

“That empowerment doesn’t work.”

Which is obviously not true, because there are plenty of examples where it does. Perhaps “Empowerment doesn’t work the way we went about it” might be a better answer. That at least opens the door to a bit more curiosity.

The last place I would expect an experiment in true empowerment would be onboard a U.S. Navy nuclear submarine.

Take a look at this video that Mike Rother sent around a couple of days ago, then come back.

A U.S. Navy submarine skipper isn’t generally inclined to swear off ever giving another order. It runs against everything he has been taught and trained to do since he was a Midshipman.

I’d like to cue in on a couple of things here and dissect what happened.

First is the general conditions. I think he could do this just a bit faster than normal because everyone involved was sealed inside a steel can for six months. Just a thought – groups in those conditions tend to have a lot of team cohesion.

But the mechanics are also critical. He didn’t just say “You are empowered.” Rather, this was a process of deliberate learning and practice.

What is key, and what most companies miss, are the crucial elements that Capt. Marquet points out must be built as the pillars of an empowered team.

GiveControl

Let’s put this in Lean Thinker’s terms.

As the Toyota Kata wave begins to sweep over everyone, there is a rush to transition managers into coaches.

“What obstacles do you think are now in the way of reaching the target?”

See the illustration above.

Competence and clarity.

I am going to start with the second one.

Clarity

Or… where the hell are we trying to go?

Capt. Marquet points out the critical element of commander’s intent. I learned this during my decade or so as a military officer (U.S. Army). When preparing operations orders, I had to clarify the overall commander’s intent. Why? So that when everything went to hell in a handcart, everyone knew what we were trying to get done even if the how to do it entirely broke down.

What that means in the lean thinking world is “What is the business imperative” or “What is the challenge we are trying to achieve?” If nobody knows “why,” then all they can know is “what” and that comes down to “implement the tools,” which, in turn, comes down to “because I said so” or “Because we need a 3 on the lean audit.”

Doesn’t work. Never has.

But I’m beating that topic to death right now, so I want to move the pillar on the left.

Competence

In my book, that means “The leader has a good idea how to do it.”

What does that mean in practical terms? In Capt. Marquet’s world, it means that, fundamentally, the crew knows how to operate a nuclear submarine. Additionally, it means they understand the ramifications of the actions they are taking on the overall system, and therefore, the contribution they are making to achieving the intent.

It doesn’t matter how clearly anyone understands what they are trying to get done if they have no idea how to do it.

In Lean Thinking world, competence means a few things.

  • The leader knows how to “do the math.” She understands the overall flow, the impact of her decisions on the system and the overall system.
  • The leader / coach has a good understanding of at least the fundamentals of flow production, and why we are striving to move in that direction.

While these things can be taught through skillful coaching, that implies that the coach has enough competence to do that teaching.

But if the coach doesn’t fundamentally grasp the True North, or doesn’t consistently bias every single conversation and decision in that direction, then Clarity is lost, and Competence is never built.

We end up with pokes and tweaks on the current condition, but no real breakthrough progress.

Day to day, this means you are on the shop floor interacting with supervisors and front line managers. You are asking the questions, and guiding their thinking until they grok that one-by-one flow @ takt is where they are striving to go.

In my Lean Director role in a previous company, I recall three distinct stages I went through with people calling me for “what to do” advice.

First, I gave them answers and explanations.

Then I transitioned to first asking them what they thought I would give as an answer.

Then they transitioned to “This is the situation, this is the target, this is what we propose, this is why we think it will work, what do you think?”

“Captain, I propose we submerge the boat.”

“What do you think I am thinking?”

“Um… you would want to know if it is safe?”

“How would you know it is safe?”

In other words…

What are you trying to achieve here? How will you know?

So here is a challenge.

If you are a line leader, especially a plant manager, take one week and utterly refuse to issue direction to anyone. Ask questions. Force them to learn the answers. Test their knowledge. Have them teach you so they must learn.

You will learn a lot about the competence of your team. You will learn a lot about your own clarity of intent. Try it on. No matter what, you will learn a lot.

Curiosity

The tenor of what “lean” is about is shifting, at least in some places, toward the line leader as improver, teacher and coach. Successfully adopting that role requires a qualification that I wish I saw more of as I work with industrial clients – curiosity.

To succeed in this role, a supervisor must be intently curious about, not only the minute-by-minute performance, but what things are affecting it, or could affect it.

Even if he is just walking by, his eyes must be checking – is there excess inventory piling up? Are all of the standard WIP spots filled? Is anyone struggling with the job? Are the carts in the right places? Pressures and temperatures OK? Kanbans circulating correctly? Workers all wearing PPE? Safety glasses? Ear plugs? Does the fork truck driver have his seatbelt fastened?

Though there should also be deliberate checks as part of his standard work, a leader needs to be intently curious about what is happening all of the time.

To improve things requires even more curiosity. “What obstacles do you think are now keeping you from reaching the target?” is not a question that should be answered casually. Rather, the preparation to answer it properly requires careful study – being curious – about what operational conditions must be changed to reach the target.

Sadly, though, my experience is that true curiosity is a pretty rare commodity. A plant manager that can spout off a barrage of facts and figures about how things have to be, but is surprised every time the math doesn’t reflect his view of reality doesn’t impress me much.

Niwa-sensai said once (probably many times) “A visual control that doesn’t trigger action is just a decoration.”

You have to be curious about what those visual controls are telling you. What good is a gage if it is supposed to read between 4 and 6, but drops to 0 and nobody notices?

That supervisor walking through the area needs to be visually sweeping those gages, looking for leaks, anything unusual or abnormal, and taking action.

“How did that stain get here?” Run the trap line. The process, as designed, shouldn’t let anything leak. Why did it? What is really happening?

All we practitioners can do is patiently, again and again, walk the line with them, ask what they see, stand in the chalk circle with them, and do our best to teach them to see what we do.

Show them the system, show them the future consequences of letting this little thing slide – how second shift is going to be brought to their knees because the work isn’t being processed according to the FIFO rules.

I suspect, though, that at least a few leaders get promoted and somehow believe they reach a level where they are exempt from checking and teaching. That’s someone else’s job.

But if not them, who? And how do they know it is getting done?

Active Control

Imagine you are driving an automobile with a high-performance suspension. You are on a perfectly straight stretch of road, with smooth pavement. Get yourself up to, say, 65 miles per hour (100 km/h). Got it pointed down the middle of the road?

OK, close your eyes, let go of the steering wheel and wait. (Actually closing your eyes is optional.)

Can you predict what will happen, more likely sooner than later?

It doesn’t matter how “stable” your car is.

There are small, random things that are eventually going to cause your car to drift away from the centerline and off the road, into the ditch on one side, or over the cliff on the other. (Didn’t I mention those?)

I often see people set up a well performing process and treat it the same way – as though it will continue to work the same way forever, without any intervention.

But your process is going to encounter random chatter, and when it does, what typically happens?

In most cases, the team members can find a way to work around the issue, and likely continue to get things done, though they will have added a bit of friction, requiring a bit more effort, to do so. They will add a redundant check to make sure no mistake got made. They will add some inventory under the work bench, in case something runs out. They will carry the product over to the other machine because the one they are supposed to use isn’t working as it should be.

They will clean up the spilled coolant, catch the leaking oil.

They will head up-line to borrow a team member’s grease bucket.

They’ll tap out paint clogged or unthreaded holes, cut wires that are delivered too long to length, even drill new holes to mount the part that doesn’t fit.

In the office, they get one more signature, send an email to back-up the “unreliable” ERP messages, and make screen prints so they can enter the data into another system.

“Waste is often disguised as useful work.”

All of this easily goes unnoticed, and eventually (maybe) the process becomes cumbersome enough that someone decides to address it with an improvement activity. And the cycle starts again.

How do we stop the cycle?

The point of intervention is in the last paragraph… “All of this goes unnoticed.”

It isn’t a matter of standing and watching for problems. Sakichi Toyoda figured that out almost 100 years ago. It is about designing your process to detect anomalies in either execution (how it is done, how long it takes) or results immediately, signal, and trigger some kind of response.

Here are some fundamental questions to ask yourself:

Before the process even begins, does the team member have everything he needs to succeed? How does he know? I’m talking about parts, information, tools, air pressure, assistance… whatever you know is needed to get the job done.

If the team member doesn’t have everything needed exactly what do you want him to do?

Is the team member carrying out the process in a way that gets the desired result? How does she know? Is there a sequence of steps that you know will give her the result you want? What alerts her if one of them is skipped?

If the team member, for whatever reason, isn’t able to carry out those steps in sequence, exactly what do you want her to do? Go find a grease bucket? Or let you know?

How long do you want to allow your team member to try to fix something or make it work before letting you know there is a problem? Related to this – how far behind can you allow him to get before he can’t catch up, even with help?

Once the team member has completed the process, how does he know the result is what was expected? If the team member doesn’t have a way to positively verify a good outcome, who does detect the problem, when, where and how? It might be your customer!

An Active Control System

Even if you have all of those checks in place, however, you still need to answer a few more questions starting with “Once the team member detects a problem, what do you what exactly do you want them to do?”

I alluded a little to this above, but let’s go a bit deeper.andon-pull

On a production line, a typical way for a team member to signal a problem is with some kind of andon. This might, for example, take the form of a rope along the line that the team member can pull in order to trigger a signal of some kind.

But that is the easy part. Lots of factories have copied the mechanics of Toyota’s andon only to see them fall into disuse following a period of cynicism.

The hard part is what is supposed to happen next?

Now we are back to the original questions because the andon is nothing more than a trigger for another process.

Who is the designated first responder? (Remember, if it is everybody’s problem, it is nobody’s problem.) Does that person know who he is?

What is the standard for the response? What is the first responder supposed to do, and how long does she have to do it?

When we had takt times on the order of dozens of minutes, our standard for the first response making face-to-face contact with the team member who signaled was 30 seconds.

How much intervention can the first responder make before being required to escalate the problem to the next level?

As a minimum

As a minimum, the first responder’s primary goal is to restore the normal pattern of work. This might be as simple as pitching in and helping because something minor tripped up the team member’s timing.

This is active control – a system or process that detects something going outside the established parameters, and applying an adjustment to get it back. Active control requires a process to detect abnormalities, a trigger, and a response that restores things. It is no different than maintaining thickness in a rolling operation – the machine measures the output, and adjusts the pressure accordingly – or an autopilot that keeps an airplane on course.

Without some kind of active control system, your process will erode over time as the team members do the only things they can do in an effort to keep things moving: They can overproduce and build inventory to compensate, they can add extra process steps, they can add just about any of the things we call “waste.”

The only question is what do you want them to do?

Applying 5S to Processes

The idea that “you always start with 5S”, for better or worse, has been deeply ingrained in the “lean culture” since the late 1980’s. A lot of companies start their improvement efforts by launching a big 5S campaign.

Often, however, these 5S efforts are focused on striving for an audit score rather than focusing on a tangible operational objective.

It is, though, very possible to help bridge the gap by putting the process improvement in 5S terms. By using a language the team already understands, and building an analogy, I have taken a few teams through a level of insight.

For example –

We are trying to develop a consistent and stable work process.

Sort

Rather than introduce something totally new, we looked at the process steps and identified those that were truly necessary to advance the work – the necessary. The team then worked to avoid doing as many of the unnecessary steps as possible. In their version of 5S, this mapped well to “Sort.”

Now we know the necessary content of the work that must be done.

Set in Order

Once they knew what steps they needed to perform, it was then a matter of working out the best sequence to perform them. “Set in order.”

Now we’ve got a standard work sequence.

Sweep or Shine

The next S is typically translated as something like “Sweep” or “Shine” and interpreted as having a process to continuously check, and restore the intended 5S condition.

Here is where a lot of pure 5S efforts stall, and become “shop cleanup” times at the end of the shift, for example. And it is where supervisors become frustrated that team members “don’t clean up after themselves or “won’t work to the standard.”

In the case of process, this means having enough visual controls in place to guide the work content and sequence, and ideally you can tell if the actual work matches the intended work. A deviation from the intended process is the same as something being “out of place.” Then, analogous to cleaning up the mess, you restore the intended pattern of work.

One powerful indicator is how long the task takes. Knowing the planned cycle time, and pacing the job somehow tells you very quickly if the work isn’t proceeding according to plan. This is one of the reasons a moving assembly line is so effective at spotting problems.

Now we have work content, sequence and maybe timing, or at the very least a way to check if the work is progressing as intended. Plan, Do and Check.

I believe it is difficult or impossible to get past this point unless your cleanup or correction activities become diagnostic.

Standardize

The 4th S is typically “Standardize”

Interesting that it comes fourth. After all, haven’t we already defined a standard?

Kind of. But a “standard” in our world is different. It isn’t a static definition that you audit to. Rather, it is what you are striving to achieve.

Now, rather than simply correcting the situation, you are getting to the root cause of WHY the mess, or the process deviation happened.

In pure 5S terms, you start asking “How did this unintended stuff show up here?”

The most extreme example I can recall was during a visit to an aerospace machine shop in Korea many, many years ago. The floors were spotless. As we were walking with the plant manager, he suddenly took several strides ahead of us, bent down, and picked up….. a chip.

One tiny chip of aluminum.

He started looking around to try to see if he could tell how it got there.

They didn’t do daily cleanup, because every time a chip landed on the floor, they sought to understand what about their chip containment had failed.

Think about that 15 or 20 minutes a day, adding up to over an hour per week, per employee, doing routine cleanup.

If you see a departure from the intended work sequence, you want to understand why it happened. What compelled the team member to do something else?

Likely there was something about what had to be done that was not completely understood. Or, in the case of many companies, the supervisor, for his own reasons, directed some other work content or sequence.

That is actually OK when the circumstances demand it, but the moment the specified process is overridden, the person who did the override now OWNS getting the normal pattern restored. What doesn’t work is making an ad-hoc decision, and not acknowledging that this was an exception.

Once you are actively seeking to understand the reasons behind departure from your specification, and actively dealing with the causes of those departures, then, and only then, are you standardizing. Until that point, you are making lists of what you would like people to do.

This is the “Act” in Plan-Do-Check-Act.

Self Discipline or Sustaining

One thing I find interesting is that early stuff out of Toyota talks about four S. They didn’t explicitly call out discipline or sustaining. If you think about it, there isn’t any need if you are actively seeking to understand, and addressing, causes in the previous step.

The discipline, then, isn’t about the worker’s discipline. It is about management and leadership discipline to stick with their own standards, and use them as a baseline for their own self-development and learning more about how things really work where the work is done.

That is when the big mirror drops out of the ceiling to let them know who is responsible for how the shop actually runs.

The Struggle

In The Leader’s Journey, I highlighted the struggle with escalating challenges as a core driver of growth in both our fictional heroes and real-life developing leaders.

This week I was essentially doing 2nd level coaching with a client I have been working with for quite a while. One of the things we did was have a brief session where we reviewed and reflected the ideal state of a coaching / problem solving culture (thanks in large part to Gerd Aulinger and Mike Rother). We reviewed the principles of what a coach and the coaching chain is striving to achieve, and the mechanics of doing it.

Combining that review with the shop-floor 2nd level coaching, a couple of my participants commented on how much better they “got” what they were trying to do. They started to move from rote to the higher-level understanding.

I am still digesting why this week had this kind of breakthrough when we have been working on the same key things for months. Nothing we went over was new information. What was different this time around?

My thought right now is that they have been in the struggle trying to understand this stuff, and finally reached the point where the additional theory snapped things into place. I told them “if you hadn’t been struggling with this, you wouldn’t have had the insights you got this week.”

I really think that is the case. We can give people all of the answers. But I am realizing if they haven’t, first, been struggling to find those answers on their own – if they haven’t been trying hard to figure it out – then the additional information would have far less (or little) impact. It is only after they have challenged themselves that the externally supplied insights have any meaning or context.

At least that is where I am right now. Time for a couple of additional experiments.

What Mode Are You In?

The main purpose of an andon is to signal that some part of the system is no longer in normal operating mode. The immediate response should be to quickly assess the situation, and recover the process to the normal mode.

Many organizations, however, do not make that mental shift. They don’t have a clear sense of whether they are in the normal operating pattern, or in recovery mode.

Without that sense of mode, “recovery” can quickly become the norm, and a culture of working around problems develops. Sometimes we call this a “firefighting culture,” but I find that term regrettable, as it reflects poorly on actual firefighters.

In the andon driven environment, the andon is either on or off. That is, things are either operating as they should be (no andon) or they are not (andon is triggered).

All of this presumes, of course, that you have some idea what your normal operating pattern should be. Go and walk your shop floor or work area. What can you see happening?

Is what you see what you want to be happening? How do you know? What do you compare it against?

Can the people working there tell if they, and their process, are in the normal operating pattern, or in some other mode?

If they are recovering, do they know they are recovering? Are they striving to get things back to the normal operating mode; or are they striving to simply get the job done in spite of the immediate problem? Big, big difference here. This is what makes or breaks your continuous improvement effort.

Once the normal operating mode is restored (assuming you had one), are at least some of these incidents investigated down to root cause, with countermeasures tested by appropriate PDCA cycles and experiments?

What mode are you in right now?

How can you tell?

What Must Be Done To Make It Happen?

The May 2013 edition of the U.S. Airways inflight magazine has a really interesting article in a monthly “Making it Happen” feature called “One Job At A Time.” (Click the link to follow along at home. The article is on page 12 of the magazine, page 14 of the pdf.)

The piece follows a machinist through his shift in their maintenance facility.

What is interesting is what he has to do to get the job done.

I’m not going to detail it all out here, but suffice it to say that his shift starts at 2:30 pm, and between then and 7:00 pm he only spends about an hour and 10 minutes to pull the old bearings and install the new ones – actually doing the job he set out to get done on the airplane.

The rest of the time is spent interacting with the job tracking computer, gathering the required tools, supplies, waiting for the inspector, and making a part because the one in the kit didn’t fit.

This team member is working within the system, and what is described here is so routine that it is a featured article in the inflight magazine.

Now – before you get really critical, you might want to follow one of your primary team members around for a shift and see if your organization does any better.

For example a ward nurse in a local hospital spent exactly 10 minutes over a 4 hour period actually providing care to patients and charting – the things I would call “nursing.”

These are dedicated team members, but the system gets in their way.

The Weird Stuff We Notice

Monday and Tuesday I had lunch in the client’s facility.

I had the same sandwich, prepared by the same worker each day.

Monday he put the mayo directly on the chicken salad, on his left.

Tuesday he put the mayo in the other piece of bread on his right.

Then I smiled at myself wondering why on Earth I even noticed that, all the while conversing about something unrelated.

Note to self: get brain checked and turn down the gain a bit.  🙂

The Simplest “Lean Audit”

I’m sorting through some old files, and just tossed a 20 or so page “lean audit” from some consultancy into the recycle bin. Like most of them, it tries to gauge the maturity of the organization by the depth and breadth of their implementation of a packet of “lean best practices” – the tools.

What I am interested in, though, is gauging maturity of the thinking and interactions, the culture.

If I ask a typical supervisor what he or she is working on right now for process improvement, what kind of answer will I get?

Does that supervisor’s boss give me the same answer? Are they coordinating and talking?

Ultimately, it comes down to the shop floor’s perception and answers to questions like:

“What are you trying to achieve?”

“Where are you right now?”

(If these look like the generic coaching questions that Mike Rother talks about in the video clip a couple of posts down, you’re right.)

The context of the answers to those questions tells me a great deal. Is it daily survival / firefighting? Or is there something they are striving for to make things better?

Even if the supervisor is engaged in daily firefighting, there is still some kind of target (usually making the production numbers); some kind of current condition (which may be clear, or may be just a judgment).

So I am curious now about what he sees as the problems and obstacles in his way of success.

“What kind of issues are keeping you from hitting your target?”

Then just listen. Whatever he says is the right answer, because I am interested in his overall perception.

Is the response from someone who is positive and feels supported, or besieged and left on his own?

Then, based on those responses, I might or might not get curious about his improvement activities. If he isn’t engaged in any, I’m not going to try to make anyone wrong, I am just trying to understand what is.

On the other hand, if there are improvement activities, then I am curious to know what he last tried, and learned, and what he plans to do next.

What kind of collaboration do I hear about?

What is the sophistication of the targets, the challenges, the experiments?

THOSE are the things that tell me how “lean” a company is… not whether or not they have uniform label colors on everything.