If You Aren’t Being Heard, Then Listen

I was sitting in on a conversation between a Continuous Improvement Manager and the Operations Manager the other day.

The Operations Manager was asking for help developing good leader standard work.

The C.I. manager was responding that she had already developed it for the Value Stream Manager, the Supervisor.

The Operations Manager said he thought right now, they needed to focus on the Team Leads, the first line of leadership.

The C.I. manager reiterated that she had already prepared standard work for the Value Stream Manager and the Supervisor.

The Operations Manager reiterated that he wanted, right now, to focus on the Team Leads.

This went back and forth three or four times, and the Operations Manager moved on to something else.

The C.I. Manager seemed frustrated and even a little angry.

My Working Hypothesis

The C.I. manager was frustrated because the work she had already done had not been implemented or acknowledged.

The Operations Manager was frustrated because his immediate need was not being acknowledged.

So they were each reiterating, again, what they had said before, neither of them acknowledging what the other was trying to say.

Being Heard as a Change Agent

When you say something, and the other person responds by reiterating what they have already said, this is a Big Red Flag for you. They are not going to hear anything you say until they feel you have heard them.

The cool part is that either of these parties can break the cycle of repetition by shifting into listening mode. I am going to take this from the perspective of the C.I. Manager / change agent since most of you reading this are more likely to be in that position.

Book cover: Never Split the DifferenceThere are lots of classes and materials out there about “active listening” but I really like a simple techniques that Chris Voss shares in his awesome book Never Split the Difference.*

At least they seem simple. But they require a lot of deliberate practice to master as they require breaking long standing unconscious habits. At least I know I’m still working on it.

The Goal: Hear “That’s Right”

The first step to listening is to listen!

Is the other person simply reiterating what they have said before in response to your message? Are you even aware of that? (or are you waiting them to stop talking so you can reiterate your message?) Take responsibility for breaking the cycle. Pay attention to their body language. Try to read how they are feeling right now.

Then test your hypothesis.

Instead of reiterating your message, repeat theirs back to them. Even better if you acknowledge the emotions behind their message.

“It sounds like you are really concerned that the leads don’t know what to do.”

Critical: In the words of Chris Voss, this requires that “late night FM DJ voice.”

NO sarcasm. NO implied judgement. You must come from a position of being curious about what they are trying to communicate, and what they are feeling.

You are trying to learn. You are not trying to make them wrong. You are not trying to make a point. You are not trying to be right.

If you are trying to do any of those things, you are not listening. You are, instead, trying to collect ammunition for your next salvo.

You will get one of two responses:

  • The other person will correct you.
  • The other person will give you some version of “Yeah, that’s right.” Those are the magic words you are trying to hear.

Let’s parse that sentence.

“It sounds like…”  (or “It seems like…”). You are not telling them what they are saying. You are telling them what you are hearing and sensing.

This invites correction. “No, that’s not it.” or “No, that’s not what I’m saying.”

They may be frustrated. That is why you must remain the calming influence.

(By the way – this is MUCH easier if you don’t have a stake in the conversation, and the process of being listened to really helps the other person clarify their own position. That is a good place to practice before you are in a high-stakes situation.)

“… you are really concerned…”

Acknowledge how you sense they are feeling. Again, this is inviting correction, clarification or agreement. In either case, you are getting more information.

“… that the leads don’t know what to do.”

This part of the sentence communicates your understanding of what you think is causing the emotion in the other person. Again, this is just an acknowledgment. It doesn’t mean that you agree that this issue should trigger this emotion, you are just acknowledging that it does.

If you don’t get “that’s right” then it is time to humbly and sincerely ask for correction. You have to do so in a way that makes it clear you really care about understanding. (“Seek first to understand.”)

Ideally the other person will attempt to clarify what they are trying to say. Cycle through this until they agree that what you are saying back is what they are trying to convey to you.

Trap: “You’re Right”

Voss points out a trap in this process: The critical difference between “that’s right” and “you’re right.”

First, if you hear “you’re right” that is an indication that the other person perceives you are trying to make your case vs. hearing them. Were you adding to the information? Were you passing judgement?

Next – In this context, “You’re right” often translates as “I’m tired of trying to talk about this.” There isn’t agreement yet. “You’re right” is about you. “That’s right” is about what you were saying. Very different things.

Which leads us to:

Don’t let “being right” about something get in the way of getting what you want or need.

The C.I. manager was right that she had prepared leader standard work for the value stream manager and the supervisor. And she was right that it hadn’t been acted upon.

But by sticking to her guns about that, the Operations Manager was left with the impression that she was refusing to help develop standard work for the team leaders, so he gave up on the conversation.

Here is what happens. Her frustration comes through. His brain (all of our brains) contains “mirror neurons” that invoke in him the emotions he is seeing across the table, which elevates his frustration without him even knowing it.

This is why that calming demeanor is so critical. If the other person picks up sarcasm, negativity, dismissiveness in your voice or body language, that will be reflected right back at you, and amplify everything the wrong way.

After (AFTER!!) getting an acknowledgment that he felt the main priority right now was the Team Leads, the C.I. manager might have created an opening –

State your facts: “I worked really hard on standard work for the value stream leader and supervisor.”

Own your own feelings: “I am feeling frustrated that none of that work was acted upon.” (Avoid victim language like “that makes me feel” or “you make me feel” statements.)

State what you need right now: “I’ll work on the standard work for the leads, but I would like to review the work I have already done and what happened with it so I can avoid the same situation with the leads. Can we do that?”

Finally…

There is no guarantee this works every time. But it works more often than escalating the emotion which probably never works.

_________________

*Why am I touting a book about negotiating? Because change agents must be able to reach agreements with others. And negotiating is a process of agreement creation. Chris Voss is a former FBI hostage negotiator. His job was to create agreements with terrorists, kidnappers, bank robbers. If his techniques work there, they probably work for a change agent in a company.

 

 

Scientific Thinking vs. The Scientific Method

My recent post, “…but where is the problem solving?” stirred up quite a bit of conversation and traffic. I would like to dig a little deeper into what “good problem solving” actually looks and sounds like – beyond the forms and tools.

Underlying all good problem solving is scientific thinking. With it, I am constantly comparing what I think with what I observe, and looking at differences as evidence that what I think might need revision.

Some years ago, I was driving down a residential street in Rochester, New York, and observed a series of signs in a yard, each with a single number on them.

Huh… what are those? Maybe they are the house number. (Hypothesis) I checked the mailbox across the street, and saw the next number in sequence, the neighbor’s mailbox had the same as had the next number after that. (Devise a test of the hypothesis, run the experiment, gather evidence.) I concluded that, yes, the signs were indeed just the address displayed in a creative way, and continued my drive.

I didn’t run any formal experiments. I didn’t document anything. I didn’t go through “the five questions” – I just thought about what those numbers might be, and tested my thinking. Had the house numbers across the street been totally out of sequence, it would have remained a mystery, as my hypothesis would have failed.

Was I applying the scientific method? Not really. I applied all of those “hypothesis” terms after the fact as I wrote this. But at the time I was curious about something (the first step of science), and applied simple logic to test an assumption I had made. While it might not be “the scientific method,” I would contend this was “scientific thinking.”

Most of the time, that is my habit. When I am uncertain and curious about something, I check it out. I apply the same thinking pattern troubleshooting my computer when it does something surprising (or annoying – are you listening, Microsoft?). None of this rises to the level of formal experimentation, it is just methodical thinking.

More difficult problems require more rigor and structure. But many “problems” just require a pause, a little thought, trying something – followed by making sure it works – and moving on. It is the “making sure it works” part that many people leave out of this process. And it is “making sure it works” that raises a blind fire-and-forget action item into an experiment… assuming that if it doesn’t work, you then dig in to understand why.

Most of these things are quick and need little formal structure. People call them “applying common sense,” and I agree – as long as the experimental mindset is there.

Much like that previous post, some of us continuous improvement people have built specific expectations about what “problem solving” should look like. But, no matter what structure is applied, the underlying pattern of thought remains the same – even for casual troubleshooting.

It is this habitual pattern of thought that Mike Rother’s Toyota Kata is intended to teach through practice. He introduces structure, but any logically and consistently applied structure will work.

Let’s not confuse specific jargon or forms with our underlying intent: Learning to habitually glance across the street at a mailbox if you think those signs might just be the house number.

If the student hasn’t learned…

… the teacher hasn’t taught.

Do you regard the structure of problem solving as dogma, or as an experiment with a predicted outcome?

If the learner struggles to master the structure, sometimes it is more valuable to find a different structure than to double down on what clearly isn’t giving the predicted result.

The Problem

Early this year I started work with a new client. They were trying to “implement A3,” and as I began to work with them, especially the new-in-the-position C.I. manager, I found they were struggling with what to write in the blocks of the “form.”

Of course there isn’t an A3 “form.” The A3 takes many configurations as the problem solver sets out to share the narrative with her coach. Nevertheless, beginners tend to find a format online, and work to put the right information in the various blocks.

In this case, my impression was that the blocks were getting in the way. “What should go in here?”  “What goes in the next block?” I didn’t really make a deliberate decision here, but I’ll tell you what I ended up doing:

What I Tried

First I tried the Toyota Kata format. He really liked that approach, but ultimately in this case we ran into the same kind of struggle. “Getting the structure right” seemed to be obscuring the bigger picture of the underlying thinking.

So I tried something more drastic: I let go of the format and the structure. Instead, let’s work on solving problems.

Like all organizations, there was no shortage of problems to practice on. So we just picked one.

Without the form, I had him map out the basic process steps. Then what happens, then what happens. What, exactly, is happening here. “The part is dropping off the conveyor.”

“OK, that’s the outcome, but what, exactly, is the mechanism that causes it to drop?” Describe what is happening. Draw it. Write it down. Show me.

After working to see process steps, we took on some pervasive quality issues.

“How is it even possible to produce this defect?” What are the steps involved to make a defective product? Yes – making defective product is a process, just like making a good product is a process. It is just a different process. What is actually happening here?

There were trials, experiments, measurements all with the goal of learning more, digging deeper, until the mechanism of the failure could be described. “This is what is happening.”

OK – how could that happen? Always forcing the discussion toward what is actually happening vs. what is not happening. If there was more than one possible mechanism to cause the problem, then “Based on the evidence we have, which of those can we rule out, and why?” Look at what’s left as a possible cause.

Of those, what trial can we run to see if we can rule that one out, or keep it in play.

At the end of a few of these, his language started to shift. He started speaking to others differently. He was learning to coach in different ways. He started asking different questions, boring in on the details with the intent of inquiry and dialog vs. “showing what I know.”

Oh – and he cracked a couple of chronic problems.

Then when the Corporate C.I. guy started insisting on “using A3” it was a pretty simple transition – it is just a way to describe what you know, what you do not know, and what steps you are taking to deepen your understanding because…

“The root cause of all problems is ignorance.”

– Steven Spear

What I Learned:

A core prerequisite to continuous improvement is good daily management of problem solving that applies solid scientific thinking to find the answers.

Once that thinking structure is in place, it can be expressed many ways, and A3 is but one of them. It isn’t the only one. As the level of scientific thinking deepens, the more the various tools and structures simply become fluid extensions to make it easier to express.

Sometimes I have found that if I try to force a particular format into place, I can end up having a container without any content.

Now… to be clear, there are many instances where the structure facilitates learning. It is just that in this particular case, the structure got in the way.

Asking whether learning is actually taking place, rather than trying to force a specific structure into place, may well be the difference between trying to teach by rote vs. staying focused on what the student is actually learning.

Problem: What Does Maintenance Cost?

Another interesting “homework problem” showed up in the searches today:

an assembly line turns out parts at the rate of 250 per hour. on the average, the line must be shut down for maintenance for 20 hours during a month. how much production is lost each month?

Answer: None.

Wait a minute!! What about the 20 hours * 250 units / hour = 5000 units? Isn’t that lost production? Maybe. What problem are you trying to solve?

I’m making a couple of assumptions here. First is around the word “maintenance” vs. the word “repair.” If the line requires 20 hours of maintenance to run reliably and avoid repairs, then this time must be planned into the expected monthly production. Thus, no planned production is lost.

If no production above the planned level is required, then I can’t say any is lost. This is why one-dimensional questions like this are so dangerous. Whenever we are confronted with questions like this, we must always ask another:

Compared to what?

What should be happening? What is normal? What is needed? Simply saying that the line (when it is running) can produce 250 units per hour is data, but it gives us nothing to act on.

Here is the rule I have been pushing lately:

Whenever you measure something, there are always two values.

  1. What you measured.
  2. What is required or expected if the process or thing you are measuring is problem free or otherwise doing what it should or what you expect.

This is equally true for an observation.

  1. What you saw.
  2. What you should have seen if things were as expected or problem-free.

Then you can start the process of meaningful inquiry.

If my line produces 250 units / hour when running problem-free, and requires 20 hours of maintenance a month to be able to do that, we have a single piece of information: How much production I should expect during the month.

Is that enough? Then no problem, turn your attention to something more pressing.

Is that not enough? OK – now we have to get serious.

A lot of management teams confronted with this problem are going to reflex to just allocating fewer hours to maintenance in order to get more hours for production.

Don’t do it.

Just cutting maintenance time is going to make things worse. Maybe not this month or even next, but sooner or later you will be losing a lot more than 5000 units of production / month. What will make this frustrating is you won’t lose them all at once. You will experience slowdowns, short stoppages, jams, and all of these things will seem like a normal day – only you won’t be making 250 units per hour anymore.

This is where a lot of management team struggle. They only look at “maintenance hours” and issue a directive to cut those hours.

But “maintenance hours” is a metric that you cannot action directly. This is a classic example of what I wrote about a couple of years ago in “Performance is the Shadow of Process.”

Worse, this is a step away from what you are trying to accomplish… which is what?

Key Question: What Problem Are You Actually Trying to Solve?

“I need to reduce the time we spend on maintenance.” is not a problem. It might be a desire, or a possible solution, but if you start here, you are already restricting your thinking.

If you did reduce the time you spent on maintenance, what would you be able to do that you can’t do today? Why is this important to work on?

(Sometimes I get “We wouldn’t spend so much time on maintenance.” I always have to laugh when I hear something like this. Aren’t circular arguments fun? “OK, why is it important to spend less time on maintenance?”)

After some discussion, we might arrive at something like a need to produce another 1000 units / month to meet increased sales demand.

That becomes our challenge. Then the fact that we spend 20 hours / month doing maintenance is part of (and only part of) the current condition. But I can ask other question now such as:

How fast must we produce (units / hour) to get another 1000 units / month? You would be surprised how often the math tells us a number that is slower than “250 units per hour.” Huh. So maybe that’s the rate when things are running smoothly… where is the time going?

The point is that it is critically important to understand why you are asking how much time is being “lost” to maintenance to avoid jumping to a solution.

 

Poster - What Problem are you Actually Trying to Solve?

It’s Hard to Learn if you Already Know

In this TED Talk, Amy Edmondson of the Harvard Business School talks about “How to turn a group of strangers into a team.” Although long-standing teams are able to perform, our workplaces today require ad-hoc collaboration between diverse groups. The question is: What kind of leadership, and what kind of structure, contributes to working together on the problem?

For those of you unfamiliar with her work, I’ll add that I have found anything that she writes or speaks about is worth reading or listening to.

The key message starts around the 10:00 minute point:

“When teaming works, you can be sure that leaders, leaders at all levels, have been crystal clear that they don’t have the answers. Let’s call this ‘situational humility.’ It’s appropriate humility. We don’t know how to do it.”

[…]

“It’s hard to offer up an idea that might be a stupid idea if you don’t know people very well. You need psychological safety to do that. They overcame what I like to call this basic human challenge: it’s hard to learn if you already know. And unfortunately, we’re hardwired to think we know. And so we’ve got to remind ourselves – and we can do it – to be curious; to be curious about what others bring.”

Here is the entire TED talk. If the embed isn’t working for you, this is the direct link: How to turn a group of strangers into a team.

 

 

 

Which brings me to the quote I pulled for the title of this post: It’s Hard to Learn if you Already Know. As Amy Edmondson points out, “we’re hard wired to think we know.”

To counteract this we need to construct different artifacts that focus our attention on our shared understanding vs. trying to advocate a particular position.

Creating The Structures of Teamwork

As obvious as this is when we say it, if we want to create a culture or social structure of teamwork this must be done deliberately. This is especially important in environments where ad-hoc groups must collaborate very quickly. So… what works? I don’t know. But we do have the tools to figure it out.

Structure to Focus on The Problem

When two people are talking about a problem while looking at each other, they tend to equate “the problem” with “the other person.” Rather than trying to reach a shared, common understanding, the tendency is to try to convince the other person to adopt their point of view.

But if we introduce some kind of artifact – an A3, a Learner’s Storyboard, a shared keyboard and monitor – that physically turns people to look at the problem rather than at each other, the dialog changes.

Collaboration at a shared keyboard and monitor

Collaboration at a learner storyboard.

“What we’ve got here is a reason to communicate.”

Think about the key difference between people looking together at the information versus someone at the front of the room, facing everyone else. The tone shifts from “tell me” to “work with me.”

Think of the key difference in a meeting between everyone sitting at the table talking about the problem vs. what happens if someone stands up and starts to draw it out on a whiteboard.

What companies like Menlo Innovations, Kaas Tailored, Toyota, and others do is construct physical artifacts to focus people’s attention away from the person and toward the information. The information becomes neutral, vs. being attached to someone. If something isn’t working, we can work together to fix the issue vs. fix blame.

The “Lean Tools”

Let’s take something as simple as standard work. What is it for?

One interpretation could be that I watch you perform the work, and if you violate the procedure, you fail the audit for not following the standard.

But the other interpretation is that we have a neutral point of comparison for how we think the work should proceed if it is problem-free. Seeing, or detecting any difference reveals a problem of some kind. We are invited by this information to look at the problem and seek to gain more understanding.

Of course, just sending an invitation doesn’t mean people come to the party. Shaping that conversation in constructive directions is what leadership is about.

And, as always, I write these posts mostly to clarify my own thinking by trying to explain it to someone else (you). I’d love to know what you think, so post comments!

 

 

Toyota Kata and The Menlo Way

I have been telling everyone who will listen to read Rich Sheridan’s book Joy, Inc. ever since I came across and read it in the fall of 2015.

Fast forward to earlier this year when Lean Frontiers sent out their request for suggested keynote speakers for KataCon. I wrote to Mike Rother and asked him “Do you think we could get Rich Sheridan?”

Skip ahead a bit more, and I spent four days last week at Menlo Innovations in Ann Arbor – two days “in the chalk circle” paying close attention to the actual day-to-day work there, and two days working (pairing) with Rich Sheridan to work out the key beats for his KataCon keynote.

 

The “So What?” Test

Menlo is well known as a benchmark for a great working culture. But the question you may be asking (and, honestly I hope you ARE asking it) is “What does Menlo Innovations and agile software development have to do with Toyota Kata?”

If you visit Menlo (and I really hope you do!) here is what you won’t see:

  • Learner storyboards.
  • “5 Questions” coaching cycles.
  • Obstacle parking lots.
  • Experiment Records (PDCA Records)

In other words, you won’t see the explicit artifacts that characterize an organization using Toyota Kata to learn how to think about improvement scientifically. In that sense, Menlo isn’t a “Toyota Kata” benchmark.

OK… and?

You don’t see those things at Toyota either. You don’t go to Toyota to see “Toyota Kata.”

The Underlying Thinking Pattern

What you will see (and hear… if you pay attention) at Menlo Innovations is an underlying pattern of scientific thinking and safe problem solving in everything they do.

Let’s review what Toyota Kata is really all about.

Rather than re-writing something elegant here, I am going to quote from my part of an email exchange between Mike Rother, Rich Sheridan and me:

Going back to Mike’s original research premise, we knew that Toyota has this pretty awesome culture thing, but didn’t really understand the “secret sauce” of the exact structure of their interactions. Put another way, we saw and understood all of the artifacts, but copying the artifacts doesn’t copy the culture.

Mike’s research was really the first that dug deeper into the interactions that the artifacts support.

Once he extracted that “secret sauce” he then boiled off all of the other stuff, and what remained at the bottom of the pot was the Improvement Kata steps and the Coaching Kata steps.

In practice at Toyota, those things are deeply embedded in the artifacts. Sometimes they aren’t even spoken.

My informal hypothesis was that if I spent time paying attention to, not just the artifacts, but the way those artifacts guided interactions at Menlo, and then boiled off the other stuff, what would remain at the bottom of the Menlo pot would also be the Improvement Kata and Coaching Kata steps. And, though I didn’t do this formally, and yes, I had confirmation bias working here, I believe I can safely say “I have no evidence to contradict this hypothesis.”

For example:

In our conversation on Friday, Mike pushed back a bit on “just run the experiment,” [context clarification: Experiments to randomly try stuff, without a clear target condition rarely get you anywhere] but the reality I observed and heard was that “purpose” (challenge and direction) and “current condition” are deeply embedded in the day-to-day interactions, and “just run the experiment” is, indeed, working on a specific obstacle in the way of a target condition of some kind.

[…]

“What problem are you trying to solve?” is Menlo jargon that I overheard many times just listening to people talk.

Within Menlo, that term is contextual. Sometimes it is about the higher-level direction and challenge.

Sometimes it is about an intermediate target condition.

Sometimes it is about an immediate problem or obstacle.

As we say in Kata world, it is fractal. It is truly fractal at Menlo as well, to the point where the words don’t change at various levels.

The words DO change at various levels in Toyota Kata’s jargon, but we can’t get hung up on the terms, we have to look at the structure of problem solving.

Menlo’s co-founders already had this thinking pattern, and deliberately sought to embed it into the culture of the company they were starting. There wasn’t really any need to explicitly teach it because they weren’t trying to change the default behavior of an organization. New Menlonians learn the culture through the interviewing and on-boarding process and adopt very quickly because the very structure of the work environment drives the culture there.

In fact, spend any time there even just hanging out, and it is very difficult NOT to get pulled into The Menlo Way. Like everyone else, Rich and I were in the daily stand-up as pair-partners, reporting our work progress on his keynote.

image

What About Toyota Kata?

Menlo has had hundreds (thousands, actually) of visitors, and those who are “lean savvy” all ask if Menlo is “using lean” as their guideline. The answer is “no, we are just trying to solve problems.” While they have certainly incorporated most of the artifacts of “agile software production,” the purists push back that they aren’t “really doing it” because they didn’t copy those artifacts exactly. Nope. They used them as a baseline to solve Menlo’s problems.

When we see an awesome problem-solving culture, it is tempting to try to reverse engineer it by copying the physical mechanics, such as heijunka boxes (work authorization boards), kanban, “standard work” and the like.

But we have to dig down and look at the routines, the behavior that those artifacts and rituals support. When we do, we see the same patterns that Toyota Kata is intended to teach.

You need to begin with the thinking pattern. Use Toyota Kata to learn that.

As you do, take a look at your artifacts – the procedures, the policies, the control mechanics of your work. Reinforce the ones that are working to create the kind of culture you want. Challenge the ones that are getting in your way. Do both of those things as deliberate experiments toward a clear vision of the culture you want to create.

That is the benefit of studying companies like Menlo.

I hope to see you all at KataCon, hear what Rich has to say to our community, and establish a link between these two communities that have, up to now, been separate.

katasummit.com

Heavy Equipment Overhaul: Flow at Takt in 1938!

This is a great contemporary film from 1938 describing the complete overhaul of a mainline 4-6-0 steam locomotive in the U.K.

What is interesting (to me) is:

  • The overhaul involves stripping the locomotive down to individual parts. Each of the parts, in turn, flows through a process of inspection / repair or replacement, with a strict timing to ensure it is delivered back to re-assembly when required.
  • There are 6 positions with a takt time of 10 hours 44 minutes. Everything is timed to this cadence.
  • I can only speculate, but with that degree of rigor in the timing, they are going to be able to see a delay or problem very quickly, and get out in front of it before it causes a delay in the main-line work.
  • The parts that come off are not necessarily the exact once that are put back on. Everything is flowing – there are multiple locomotives in overhaul.

More thoughts below the video.

(Here is a direct YouTube link for those who don’t get the embed in the email subscription: https://www.youtube.com/watch?v=ktHw1wR9XOU)

Flow in Overhaul and Repair

This is a great working example of a process flow that proves difficult for some organizations: Overhaul and repair. “We don’t know what we will find, so there is no way we can sequence and index it on a timetable.”

I’ve seen a similar operation overhauling helicopters. The intended flow was exactly the same.

  • Like the locomotive flow, they stripped everything down to the airframe. The various components had different flow paths for sheet metal, hydraulic components, power-train (engine / transmission), rotor components, electrical, avionics, and composite parts.
  • The objective was to deliver “good as new” items on time back to the re-assembly process.

Here is where they ran into problems:

  • If an item needed repair, then the repairs were done, and the item flowed back.
  • But if an item could not be repaired (needed to be scrapped and replaced) it was tagged, and returned to the “customer” – the parts bin in main assembly. It arrived just like any other part except this one was tagged as unusable. It was up to the assembly supervisor to notice, and initiate ordering a new one.

Who is your customer? What do they need?

The breakdown was that the repair line(s) saw themselves as providing a repair service. If it couldn’t be repaired, sorry.

What their customer needed was a good part to install on the helicopter. If they can create a good part by repairing the old one, great. But if it isn’t repairable, their customer still needs a good one and they need it on time.

The Importance of Timing and Sequencing

In the locomotive video, they emphasize the precise timing and sequencing to make sure each part arrives in the proper sequence, when it is needed, where it is needed.

Even if it actually worked like they describe, I can be sure it didn’t work like that when they first started.

The timing and sequencing is a hypothesis. Each time they overhaul a locomotive, in fact each individual part flow, is an experiment to test that hypothesis. Over time, it is possible to dial things in very precisely.

Why? So you can quickly identify those truly anomalous conditions that demand your intervention.

Normal vs Abnormal

Just because there are frequent issues does not negate the fact that most of the time things can probably flow pretty well. What we tend to do, however, is focus on the problem cases and give up on all of them. “What about this? What about that?” bringing up the legitimate issues and problems, causes us to lose sight of the fact that underneath it all there is a baseline pattern.

What is important is to define the point at which we need to intervene, and set up the process to detect that point. When we can clearly distinguish between routine work and true exceptions, and not try to treat everything as a special case.

Experimenting at the Threshold of Knowledge

The title of this post was a repeating theme from KataCon 3. It is also heavily emphasized in Mike Rother’s forthcoming book The Toyota Kata Practitioner’s Guide (Due for publication in October 2017).

What is the Threshold of Knowledge?

“The root cause of all problems is ignorance.”

– Steven Spear

September 1901, Dayton, Ohio: Wilbur was frustrated. The previous year, 1900, he, with his brother’s help1, had built and tested their first full-size glider. It was designed using the most up-to-date information about wing design available. His plan had been to “kite” the glider with him as a pilot. He wanted to test his roll-control mechanism, and build practice hours “flying” and maintaining control of an aircraft.

But things had not gone as he expected. The Wrights were the first ones to actually measure the lift and drag2 forces generated by their wings, and in 1900 they were seeing only about 1/3 of the lift predicted by the equations they were using.

The picture below shows the 1900 glider being “kited.”. Notice the angle of the line and the steep angle of attack required to fly, even in a stiff 20 knot breeze.  Although they could get some basic tests done, it was clear that this glider would not suit their purpose.

image

In 1901 they had returned with a new glider, essentially the same design only about 50% bigger. They predicted they would get enough lift to sustain flight with a human pilot. They did succeed in making glides and testing the principle of turning the aircraft by rolling the wing. But although it could lift more weight, the lift / drag ratio was no better.

image

What They Thought They Knew

Wilbur’s original assumptions are well summarized in a talk he gave later that month at the invitation of his mentor and coach, Octave Chanute.

Excerpted from the published transcript of Some Aeronautical Experiments presented by Wilbur Wright on Sept 18, 1901 to the Western Society of Engineers in Chicago (Please give Wilbur a pass for using the word “Men.” He is living in a different era):

The difficulties which obstruct the pathway to success in flying-machine construction are of three general classes:

  1. Those which relate to the construction of the sustaining wings;
  2. those which relate to the generation and application of the power required to drive the machine through the air;
  3. those relating to the balancing and steering of the machine after it is actually in flight.

Of these difficulties two are already to a certain extent solved. Men already know how to construct wings or aeroplanes which, when driven through the air at sufficient speed, will not only sustain the weight of the wings themselves, but also that of the engine and of the engineer as well. Men also know how to build engines and screws of sufficient lightness and power to drive these planes at sustaining speed. As long ago as 1884 a machine3 weighing 8,000 pounds demonstrated its power both to lift itself from the ground and to maintain a speed of from 30 to 40 miles per hour, but failed of success owing to the inability to balance and steer it properly. This inability to balance and steer still confronts students of the flying problem, although nearly eight years have passed. When this one feature has been worked out, the age of flying machines will have arrived, for all other difficulties are of minor importance.

What we have here is Wilbur’s high-level assessment of the current condition – what is known, and what is not known, about the problem of “powered, controlled flight.”

Summarized, he believed there were three problems to solve for powered, controlled flight:

  1. Building a wing that can lift the weight of the aircraft and a pilot.
  2. Building a propulsion system to move it through the air.
  3. Controlling the flight – going where you want to.

Based on their research, and the published experience of other experimenters, Wilbur had every reason to believe that problems (1) and (2) were solved, or easy to solve. He perceived that the gap was control and focused his attention there.

His first target condition had been to validate his concept of roll control based on “warping” (bending) the wings. In 1899 he built a kite and was able to roll, and thus turn, it at will.

At this point, he believed the current condition was that lift was understood, and that the basic concept of changing the direction by rolling the wing was valid. Thus, his next target condition was to scale his concept to full size and test it.

What Happened

Wilbur had predicted that their wing would perform with the calculated amount of lift.

When they first tested it at Kitty Hawk in 1900, it didn’t.

However, at this point, Wilbur was not willing to challenge what was “known” about flight.

Instead the 1901 glider was a larger version of the 1900 one with one major exception: It was built so they could reconfigure the airfoil easily.

Impatient, Wilbur insisted on just trying it. But, to quote from Harry Combs’ excellent history, Kill Devil Hill:

“The Wrights in their new design had also committed what to modern engineers would be an unforgivable sin. […] they made two wing design changes simultaneously and without test.4

Without going into the details (get the book if you are interested) they did manage to get some glides, but were really no closer to understanding lift than they had been the previous year.

They had run past their threshold of knowledge and had assumed (with good reason) that they understood something that, in fact, they did not (nobody did).

They almost gave up.

Deliberate Learning

Being invited to speak in September actually gave Wilbur a chance to reflect, and renewed his spirits. That fall and winter, he and his brother conducted empirical wind tunnel experiments on 200 airfoil designs to learn what made a difference and what did not. In the process, as an “oh by the way,” they invented the “Wright Balance” which was the gold standard for measuring lift and drag in wind tunnel testing until electronics took over.

They went back to what was known, and experimented from there. They made no assumptions. Everything was tested so they could see for themselves and better understand.

The result of their experiments was the 1902 Wright Glider. You can see a full size replica in the ticketing area of the Charlotte, NC airport.

I’ll skip to the results:

image

Notice that the line is now nearly vertical, and the wing pointed nearly straight forward rather than steeply tipped back.

What Do We Need to Learn?

Making process improvements is a process of research and development, just like Wilbur and Orville were going through. In 1901 they fell into the trap of “What do we need to do?” After they got back to Dayton, they recovered and asked “What do we need to learn?” “What do we not understand?”

The Coaching Kata

What I have come to understand is the main purpose of coaching is to help the learner (and the coach) find that boundary between what we know (and can confirm) and what we need to learn. Once that boundary is clear, then the next experiment is equally clear: What are we going to do in order to learn? Learning is the objective of any task, experiment, or action item, because they are all built on a prediction even if you don’t think they are.

By helping the learner make the learning task explicit, rather than implicit, the coach advances learning and understanding – not only for the learner, but for the entire organization.

Where is your threshold of knowledge? How do you know?

 

________________________________

1We refer to “the Wright Brothers” when talking about this team. It was Wilbur who, in 1899, became interested in flight. Through 1900 it was largely Wilbur with his brother helping him. After 1901, though, his letters and diary entries start referring to “we” rather than “I” as the project moved into being a full partnership with Orville.

2The Wright Brothers used the term “drift” to refer to what, today, we call “drag.”

3Wilbur is referring to a “flying machine” built by Hiram Maxim.

4I’m not so sure that this is regarded as an “unforgivable sin” in a lot of the engineering environments I have seen, though the outcomes are similar.

Coaching Kata: Walking Through an Improvement Board

Improver's Storyboard

The Coaching Kata is much more than just asking the 5 questions. The coach needs to pay attention to the answers and make sure the thinking flows.

Although I have alluded to pieces in prior posts, today I want to go over how I try to connect the dots during a coaching cycle.

Does the learner understand the challenge she is striving for?

The “5 Questions” of the Coaching Kata do not explicitly ask about the challenge the learner is striving for. This makes sense because the challenge generally doesn’t change over the course of a week or two.

But I often see challenges that are vague, defined only by a general direction like “reduce.” The question I ask at that point is “How will you know when you have achieved the challenge?

If there isn’t a measurable outcome (and sometimes there isn’t), I am probing to see if the learner really understands what he must achieve to meet the challenge.

This usually comes up when I am 2nd coaching and the learner and regular coach haven’t really reached a meeting of the minds on what the challenge is.

Is the target condition a logical step in the direction of the challenge?

And is the target condition based on a thorough grasp of the current condition?

I’m going to start with this secondary question since I run into this issue more often, especially in organizations with novice coaches. (And, by definition, that is most of the organizations where I spend time.)

It is quite common for the learner to first try to establish a target condition, and then grasp the current condition. Not surprisingly, they struggle with that approach. It sometimes helps to have the four steps of the Improvement Kata up near the board, and even go as far as to have a “You are here” arrow.

Four steps of the Improvement Kata
(c) Mike Rother

Another question I ask myself is Can I directly compare the target condition and the current condition? Can I see the gap, can I see the same indicators and measurements used for each so I can compare “apples vs apples”?

Along with this is the same question I ask for the challenge, only more so for the target condition:

How will the learner be able to tell when the target is met? Since this has a short-term deadline, I am really looking for a crisp, black-and-white line here. The target condition is either met or not met on the date.

Is there a short-term date that is in the future?

It is pretty common for a novice learner to set a target condition equal to the challenge. If they are over-reaching, I’ll impose a date, usually no more than two weeks out. “Where will you be in two weeks?” Another way to ask is “What will the current condition be in two weeks?”

Sometimes the learner has slid up to the date and past it. Watch for this! If the date comes up without hitting the target, then it is time to reflect and establish a new target condition in the future.

Is the target condition a step in the direction of the challenge?

Usually the link between the target condition and the overall challenge is pretty obvious. Sometimes, though, it isn’t clear to the coach, even if it is clear in the mind of the learner. In these cases, it is important for the coach to ask.

Key Point: The coach isn’t rigidly locked into the script of the 5 questions. The purpose of follow-up questions is to (1) actually get an answer to the Coaching Kata questions and (2) make sure the coach understands how the learner is thinking. Remember coach: It is the learner’s thinking that you are working to improve, so you have to understand it!

(And occasionally the learner will try to establish a target condition that really isn’t related to the challenge.)

Does the “obstacle being addressed” actually relate to the target condition?

(Always keep your marshmallow on top!)

The question is “What obstacles do you think are preventing you from reaching the target condition?” That question should be answered with a reading of all of the obstacles. (Again, the coach is trying to understand what the learner is thinking.) Then “Which one (obstacle) are you addressing now?”

Generally I give a pretty broad (though not infinitely broad) pass to the obstacles on the list. They are, after all, the learner’s opinion (“…do you think are…”). But when it comes to the “obstacle being addressed now” I apply a little more scrutiny.

I have addressed this with a tip in a previous post: TOYOTA KATA: IS THAT REALLY AN OBSTACLE?

It is perfectly legitimate, especially early on, for an obstacle to be something we need to learn more about. The boundary between “Grasp the current condition” and “Establish the next target condition” can be blurry. As the focus is narrowed, the learner may well have to go back and dig into some more detail about the current condition. If that is impeding getting to the target, then just write it down, and be clear what information is needed. Then establish a step that will get that information.

Sometimes the learner will write down every obstacle they perceive to reaching the challenge. The whole point of establishing a Target Condition is to narrow the scope of what needs to be worked on down to something easier to deal with. When I focus them on only the obstacles that relate directly to their Target Condition, many are understandably reluctant to simply cross other (legitimate, just not “right now”) issues off the list.

In this case it can be helpful to establish a second Obstacle Parking Lot off to the side that has these longer-term obstacles and problems on it. That does a couple of things. It can remind the coach (who is often the boss) that, yes, we know those are issues, but we aren’t working on those right now. Other team members who contribute their thinking can also know they were heard, and those issues will be addressed when they are actually impeding progress.

Does the “Next step or experiment” lead to learning about the obstacle being addressed?

Sometimes it helps to have the learner first list what they need to learn, and then fill in what they are going to do. See this previous post for the details: IMPROVEMENT KATA: NEXT STEP AND EXPECTED RESULT.

In any case, I am looking to see an “Expected result” that at least implies learning.

In “When can we go and see what we have learned from taking that step?” I am also looking for a fast turn-around. It is common for the next step to be bigger than it needs to be. “What can you do today that will help you learn?” can sometimes help clarify that the learner doesn’t always need to try a full-up fix. It may be more productive to test the idea in a limited way just to make sure it will work the way she thinks it will. That is faster than a big project that ends up not working.

Averages, Percentages and Math

As a general rule I strongly discourage the use of averages and “percent improvement” (or reduction) type metrics for process improvement.

The Problem with Averages

Averages can be very useful when used as part of a rigorous statistical analysis. Most people don’t do that. They simply dump all of their data into a simple arithmetic mean, and determine a score of sorts for how well the process is doing.

The Average Trap

There is a target value. Let’s say it is 15. Units could be anything you want. In this example, if we exceed 15, we’re good. Under 15, not good.

“Our goal is 15, and our average performance is 20.”

Awesome, right?

Take a look at those two run charts below*. They both have an average of 20.

On the first one, 100% of the data points meet or exceed the goal of 15.

Run chart with average of 20, all points higher than 15.

On the one below, 11 points miss the goal

image

But the both have an average 5 points over the goal.

In this case, the “average” really gives you almost no information. I would have them measure hits and misses, not averages. The data here is contrived, but the example I am citing is something I have seen multiple times.

Why? Most people learned how to calculate an arithmetic mean in junior high school. It’s easy. It’s easier to put down a single number than to build a run chart and look at every data point. And once that single number is calculated, the data are often thrown away.

Be suspicious when you hear “averages” used as a performance measurement.

Using Averages Correctly

(If you understand elementary statistical testing you can skip this part… except I’ve experts who should have known better fall into the trap I am about to describe, so maybe you shouldn’t skip it after all.)

In spite of what I said above, there are occasions when using an average as a goal or as part of a target condition makes sense.

A process running over time produces a range of values that fall into a distribution of some kind.

Any sample you take is just that – a sample. Take a big enough sample, and you can become reasonably confident that the average of your sample represents (meaning is close to) the average of everything.

The move variation there is, the bigger sample you need to gain the same level of certainty (which is really expressed as the probability you are wrong).

The more certain you want to be, the bigger sample you need.

Let’s say you’ve done that. So now you have an average (usually a mean) value.

Since you are (presumably) trying to improve the performance, you are trying to shift that mean – to change the average to a higher or lower value.

BUT remember there is variation. If you take a second sample of data from an unchanged process and calculate that sample’s average, YOU WILL GET A DIFFERENT AVERAGE. It might be higher than the first sample, it might be lower, but the likelihood that it will exactly the same is very, very small.

The averages will be different even if you haven’t changed anything.

You can’t just look at the two numbers and say “It’s better.” If you try, the NEXT sample you take might look worse. Or it might not. Or it might look better, and you will congratulate yourself.

If you start turning knobs in response, you are chasing your tail and making things worse because you are introducing even more variables and increasing the variation. Deming called this “Tampering” and people do it all of the time.

Before you can say “This is better” you have to calculate, based on the amount of variation in the data, how much better the average needs to be before you can say, with some certainty, that this new sample is from a process that is different than the first one.

The more variation there is, the more difference you need to see. The more certainty you want, the more difference you need to see. This is called “statistical significance” and is why you will see reports that seem to show something is better, but seem to be dismissed as a “statistically insignificant difference” between, for example, the trial medication and the placebo.

Unless you are applying statistical tests to the samples, don’t say “the average is better, so the process is better.” The only exception would be if the difference is overwhelmingly obvious. Even then, do the math just to be sure.

I have personally seen a Six Sigma Black Belt(!!) fall into this trap – saying that a process had “improved” based on a shift in the mean of a short sample without applying any kind of statistical test.

As I said, averages have a valuable purpose – when used as part of a robust statistical analysis. But usually that analysis isn’t there, so unless it is, I always want to see the underlying numbers.

Sometimes I hear “We only have the averages.” Sorry, you can’t calculate an average without the individual data points, so maybe we should go dig them out of the spreadsheet or database. They might tell us something.

The Problem with Percentages

Once again, percentages are valuable analysis tools, so long as the underlying information isn’t lost in the process. But there are a couple of scenarios where I always ask people not to use them.

Don’t Make Me Do Math

“We predict this will give us a 23% increase in output.”

That doesn’t tell me a thing about your goal. It’s like saying “Our goal is better output.”

Here is my question:

“How will you know if you have achieved it?”

For me to answer that question for myself, I have to do math. I have to take your current performance, multiply x 1.23 to calculate what your goal is.

If that number is your goal, then just use the number. Don’t make me do math to figure out what your target is.

Same thing for “We expect 4 more units per hour.”

“How many units do you expect per hour?” “How many are you producing now?” (compared to what?)

Indicators of a W.A.G.

How often do you hear something like  “x happens 90 percent of the time”?

I am always suspicious of round numbers because they typically have no analysis behind them. When I hear “75%” or “90%” I am pretty sure it’s just speculation with no data.

These things sound very authoritative and it is easy for the uncertainty to get lost in re-statement. What was a rough estimate ends up being presented as a fact-based prediction.

At Boeing someone once defined numbers like this as “atmospheric extractions.”

If the numbers are important, get real measurements. If they aren’t important, don’t use them.

Bottom Line Advice:

Avoid averages unless they are part of a larger statistical testing process.

Don’t set goals as “percent improvement.” Do the math yourself and calculate the actual value you are shooting for. Compare your actual results against that value and define the gap.

When there is a lot of variation in the number of opportunities for success (or not) during a day, a week, think about something that conveys “x of X opportunities” in addition to a percent. When you have that much variation in your volume, fluctuations in percent of success from one day to the next likely don’t mean very much anyway.

Look at the populations – what was different about the ones that worked vs. the ones that didn’t — rather than just aggregating everything into a percentage.

Be suspicious of round numbers that sound authoritative.

_______________

*These charts are simply independent random numbers with upper and lower bounds on the range. Real data is likely to have something other than a flat distribution, but these make the point.