Shifting Perspective from Getting Results to Developing People

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

Taken from an actual conversation.

“What is your target condition?”

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

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

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

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

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

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

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

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

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

“What result did you expect?”

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

“What actually happened?”

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

“What did you learn?”

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

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

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

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

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

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

(he adds it to the list)

“Any other obstacles?”

“Um… I don’t think so.”

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

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

“Yes.”

“OK, what is your next step?”

“I am going to assign the priorities myself.”

“What result do you expect?”

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

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

pause…

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

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

“Yes.”

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

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

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

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

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

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

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

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

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

pause…

“What else might be in the way?”

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

“Write that down. Anything else?”

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

“Write that down. Anything else?”

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

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

pause… “yeah.”

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

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

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

“Yes.”

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

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

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

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

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

“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.

Where Toyota Kata Doesn’t Work

image

I’ll admit right up front that the headline is worded to attract search engines.

If that’s how you got here, be prepared to think.

Can You Prove That This Works

This is something I hear a lot:

“I can see where _____ applies to your example. But my process is __(different somehow) ___.

Fill in the blanks.

Other versions are:

  • “I can see how that works in manufacturing, but ____.
  • “How does this apply to _____?”
  • “Can you show me examples in (something that is an exact match to what I do)?

Anyone in the business of process improvement has heard versions of this excuse for years. It always comes up. “I can see how that works for cars, but we make ____.” is an older version.

One of my favorites came via a friend working with a Japanese supplier to Boeing. They told him “We can see how this would work in American culture, but we don’t think it works in Japan.” Yes, we were teaching Japanese management techniques to the Japanese, and they were telling us it doesn’t work in Japan.

So… this style of “Prove to me that this applies to my specific situation” is something we’ve all heard again and again.

Science

If you manage to read all the way to the bottom, you will see that I readily concede that I cannot prove that “Toyota Kata” or learning problem solving based on scientific thinking works to improve any process out there.

To be able to prove that, I would need knowledge of all processes, past, present and future, and have to make the case that, in each and every one of them, I have indeed established that it works.

What I do have is personal knowledge of application in a very diverse circumstances, which adds to the collective experience of thousands of people who are working to apply these methods and principles. So far, we haven’t found that case where it can’t work. We might someday, but haven’t yet.

The assertion that this thinking is universal is a refutable hypothesis. You can, with some effort, establish rigorous proof, through repeatable experimentation or direct observation of a counter-case that my theory needs modification.

But before we get to that part (at the end), let’s go through some more common instances of this line of thinking.

The Instance of Product Development

Here are a couple of things to think about.

Let me ask, “How do you do product development?”

Typically (HOPEFULLY!) I’ll get some version of:

  • Understand what we are trying to achieve – performance specifications, customer needs, etc. that today’s product cannot provide.
  • Assess the baseline capability and identify gaps between what we need to do, and what we can do with technology, manufacturing capability, etc.
  • Based on that, establish the first, or next, of what are likely a series of intermediate goals converging on the requirement.
  • Iterate through cycles of trials, tests, experiments, learning, etc. to converge on a design that meets the requirements.

Now, to be clear, there are LOTS of variations on this, and lots of ways to manage the execution of this thought process. Some are dramatically more effective than others, but at the core there is a rigorous application of the scientific method.

What is the alternative? Guess at something, build it, and hope it works? Even that approach is going to (hopefully) have you going back and assessing what you learned when it doesn’t work.

So what, exactly, is it about the methodology we are teaching with Toyota Kata that is any different from the above?

  • Understand the challenge and direction.
  • Grasp the current condition.
  • Establish the next target condition.
  • Iterate from the current condition toward the target condition using a rigorous scientific approach that drives learning.

Why wouldn’t you want to apply that method to R&D? What do you do, if you don’t do this?

And, to be even more clear, I think I can make the case that all of the exotic product development methodologies – “Production Preparation Process (3P),” “Agile” and it’s cousins, “Lean Start Up,” “Design for Six Sigma,” “Set Based Concurrent Engineering,” all of them, are simply methods to cycle through the this learning process faster, cheaper, and more robustly.

Toyota Kata is nothing more than a tool to teach the thought pattern. Don’t lose sight of that.

Here’s the kicker. What we are doing, in reality, is working hard to figure out how to apply robust product development thinking to production processes, not the other way around. This stuff started in R&D. The Wright brothers used this process between 1899 and 1903 and beyond to the first practical airplane in 1908. Wilbur’s diaries and letters are essentially a PDCA cycles record.

Scientific Process Engineering

In spite of the little rant above, most engineers take a lot of care to design the product. They study and understand the details of its function, and carefully make modifications in a controlled way so they can test the effects of what they are doing.

On the other hand, it is relatively rare to see the same rigor applied to designing the production process. Many times it is allowed to come together ad-hoc. There is often deep understanding of the core value-adding process steps – how to do machining, welding, painting, etc. But the design and management of the movement of material and information from one process step to the next? Not so much.

Why wouldn’t you want to learn how to apply the same rigor in designing the production system that you apply to designing the product itself?

What is the alternative? Actually I know what the alternative is. Set financially derived metrics, and a high-stakes rewards system for hitting them. Then leave it to managers to figure out on their own. While you’re at it, divide the system into functional areas and set those managers up to compete with each other’s performance. It is a robust system with a reliable, repeatable outcome. Maybe not the outcome you would seek intentionally, but reliably predictable nonetheless.

So how about giving a thought to applying scientific design principles to your production flows? It can’t make them any worse.

Back to Engineering

In a large engineering department, most of the activity isn’t research and design work that I discussed above. It is production work. The products are drawing changes, bills of material, quotes and estimates, CNC programs, engineering change notices, resolution of production problems. This is all vital engineering work, but it is production.

Each of those products is assembled from components. The “material” might be information, but if you decompose outputs into their constituent components, you see sub-assemblies coming together from smaller bits, and in turn, assembling into the bigger “thing” whatever it is.

This is a factory. It just makes useful information rather than hardware.

The irony is (1) There typically even less attention paid to how things are done, what struggles people have to get the information they should have gotten, but didn’t, etc. then there is in even the worst manufacturing floors. And (2) There is often little realization that even people sharing the same cubicle often are working to different interpretations of the requirement, much less methods of doing the work.

So here’s a question:

Are you (as a manager) expected to improve the lead time, quality of output, productivity… any of those things… in your department?

If the answer is “No” then great. I’m glad to hear that things are working perfectly for you… though you might want to spend more time understanding what people are really dealing with, because “No Problem” is often a BIG problem.

For most, though, the answer is “Yes.” They are expected to deliver some improvement in throughput, quality, productivity, etc. Note that these are all production system measurements. That makes perfect sense, because, as I said, these processes are production.

OK… you’re on the hook to deliver improvement of some kind.

How are you going about improvement in your process?

Indulge me a bit, and let me ask a couple of questions.

  1. What you are trying to achieve with your improvement?
  2. How is your process performing today in comparison to that? Do you know what it is about the process that is driving that current performance?
  3. What are you working toward, right now, as the next step to reach your goal?
  4. What kinds of things are you going to have to fix or change to get there?
  5. Which of them are you working on now?
  6. Can you share a bit about what kind of things you are trying in your improvement effort? How are they working for you?

I realize that Toyota Kata might not apply, but if you are actively working to improve anything, you likely have answers to some form of those questions (hopefully).

Of course, those are a variation on the Toyota Kata coaching questions, aren’t they?

It’s just that we usually don’t ask and answer questions like this explicitly. Maybe the effort would be a little more focused and clear if we did. Because all we are trying to do with Toyota Kata is make the scientific thought process more explicit so it is easier to teach. The idea is to get more people learning and understanding how to think that way, which I believe is generally a good thing. Most people would agree, at least with that last part.

I Still Need A Specific Example

Here’s where I sometimes scratch my head, especially when I get this question from someone with a technical education, and often a graduate degree on top of it.

When you went to those universities, did they teach you with examples that exactly matched the job you are doing today? Likely not. Yet you have figured out how to apply those principles to what you are doing.

In those classes, seminars, case studies, they used problems and examples to help you understand the principles.

Then they expected you to take the specific instance of those principles from the examples they used, turn them into a general case, then figure out how to apply those general principles to a different problem, case, or set of circumstances.

In the end, that is really all they were teaching you: How to figure out how to apply a general principle or theory to a specific case or problem. They likely didn’t accept an exam answer that said “You didn’t show me an exact example of this problem.”

It’s Still Science

I will totally concede that there may well be specific instances where the general principles of scientific thinking wouldn’t work to improve a particular type of process. And in those cases, there is certainly no benefit to working to learn how to apply, and teach, scientific thinking.

I say that because I believe in the scientific method, therefore my assertion that “These principles are universally applicable” is a refutable hypothesis.

I welcome the discovery of a specific case where they don’t apply. But the other side of the scientific method is I cannot prove the non-existence of that case.

If, on the other hand, you can establish that you indeed have the proverbial “Black Swan” on your hands, let’s take a look. The burden, though, is on the person suggesting to refute the hypothesis to provide compelling evidence.

Can you please explain what it is about your specific process that defies application of scientific thinking to understand it better, and improve it? What specific characteristics would a process have that makes it so unique that you are stymied in any attempt to apply what you have been educated and trained to do as a scientist or engineer?

I am really curious, and welcome exploring that together, and perhaps modifying my theory to adapt to any true anomalous situation.

That’s science.

Coaching with Intent

As I continue to explore the concepts in David Marquet’s Turn the Ship Around, I am finding increasing resonance with the concept of intent. I’d like to explore some of that in relationship to lean, “Toyota Kata” and organizational alignment.

For a quick review, take a look at the sketchcast video, below, and focus on the part where he talks about “we replaced it with intent.”

I think the critical words are “You give intent to them, and they give intent to you.”

Think about that phrase, then think about how we normally talk about “intent.”

OK, are you back?

In my experience, “intent” has traditionally been a one-way communication. “This is what we need to get done.”

A few months ago I was in a plant, discussing this principle. One of the managers expressed frustration saying “I think I was very clear about what I expected…” (And he was) “but then when I checked he had done something totally different. How does this work for that situation?”

What was left out of that conversation?

…and they give intent to you.

Let’s put this in Toyota Kata terms.

What is the relationship between the “Challenge” and the “Target Condition?”

Think about how the target condition is developed.

Start with the challenge – this is the level of performance we are trying to achieve – the “mission” in military terms, the overall intent of what we are trying to get done.

Once the direction and challenge (the intent) are understood, the improver / learner’s next task is to get a thorough understanding of the current condition. How does the process operate today? What is the normal pattern? Why does it perform the way it does? This should be focused in context of the direction / challenge / intent.

Then the learner (NOT the coach!) proposes the next target condition.

Depending on the level of skill in the learner, the coach may well be assisting in developing all of this, but it is the learner’s responsibility to do it.

Imagine this conversation: as the learner / improver is discussing the target condition, he relates it back to the challenge as a verification for context.

“The overall challenge we have is to _______. As my first (next) target condition, I intend to _____ (as the learner relates his next level of performance, and what the process will have to look like to get there).

Adding the words “I intend to…” to that exchange has (for me) proven to be a powerful tool when learners are struggling to embrace / own their target conditions. Those words establish psychological ownership vs. seeking permission.

The same structure can be applied to the next step or experiment.

“What is your next step or experiment?”

I intend to (fill in your experiment here).”

Going back to the sketchcast video, remember the part where he says:

“Captain, I intend to submerge the ship.”

“What do you think I’m thinking right now?”

“Uh…. hard to tell… I’m guessing you want to know if it’s safe.”

“BINGO! Convince me it’s safe.”

“Captain, I intend to submerge the ship. All men are below. All hatches are shut. The ship’s rigged for diving. We’ve checked the bottom depth. We’re in the water that’s assigned to us.”

In not only stating intent, but going through the checklist, the “learner” demonstrates that the intent will be carried out competently, or not.

We are asking the same questions when we ask about the next experiment, what outcome is expected. Logical follow-on questions could include seeking assurance that the experiment actually addresses the stated “one obstacle” being addressed (this is the right thing to do) and that learner has a plan to carry out the experiment that makes sense, knows what information he intends to collect, what observations he needs to make, and how he intends to do these things (that it is being done competently).

At an advanced level, a good answer to “What is your next step or experiment?” could (should!) include all of these elements – enough information to convince the coach that it is a good experiment, seeking the right information, in the right way.

It becomes  “to address that obstacle, I next I intend to (take these steps, in this way, with these people) so that (fill in expected outcome). I intend to measure here and here, and verify my results by…”

Of course as a coach, if you have a learner who is unsure how to proceed, or looking to be told what to do (which is quite common in organizations that have to overcome a command structure where the boss is the problem solver), how do you need to phrase your coaching questions to get the next level of responsible language out of your learner’s mouth?

If they are waiting to be told what to do, how do you get them to offer an opinion?

If they are offering an opinion, how do you get them to offer a recommendation? Is it well thought out? “What result do you expect?” “How do you expect to achieve that result?”

If they are offering a well thought out recommendation, how do you get them to express an intent? What do you have to hear to be convinced that intent is well though out?

I want to be clear: This is advanced stuff, but it goes hand-in-glove with the coaching kata.

And, to give credit where credit is due, it is all the work of David Marquet. I am just adapting it to the kata here.

Often Skipped: Understand the Challenge and Direction

I’ve been practicing, teaching (and learning) the Toyota Kata for about four years now, and I’m seeing some pervasive patterns that are getting in people’s way of making it work.

The one I’d like to address today is skipping over “Understand the Direction.”

As designed by Mike Rother, the Improvement Kata has four basic steps:

image

Graphic © Mike Rother  (click on the graphic to download the Improvement Kata Handbook)

This fact (that there are four steps) is often lost on beginning practitioners. They tend to associate “Toyota Kata” only with the “Five Questions” of the Coaching Kata, which guide Step 4 (above). On the surface, that is understandable, because we hear the coaching cycles a lot more frequently, and they are a hallmark of the kata principle.

But we (hopefully) wouldn’t think of jumping right into the Five Questions until the answer to “What is your target condition?” is something more definitive than “To improve this process.”  (We only used to do that, right? hmmm.)

One of the reasons to set a clear target condition is to get away from general “waste safari” improvement efforts, and focus the improver’s attention on what must be done to get to the next level.

Without a sense of direction, it is easy for the improver to see every improvement opportunity (or none of them), and get locked up trying to find a way to fix them all.

It’s frustrating for everyone, because little progress is made, and those improvements that are made have a tough time finding their way to any higher level meaning.

Someone, long ago, pointed out to me that the geometric figure “frustum” seems to have the same Latin root as “frustration.” This is the graphic that comes to mind:

image

Though the concept of a clear target condition is fairly easy to get across, organizations seem to get locked into a cycle of Steps 2, 3 and 4 without ever going back to Step 1, except in the most general terms.

Here’s what I think happens:

When an organization is just getting started, we’ve commonly told them to pick an area to practice, based on quick cycles and other practice criteria, and get to learning the improvement kata, striving toward a general challenge like one-by-one flow.

That pattern of seeking improvement opportunities gets engrained, and it is hard to shift off it and start to set clear direction and challenges. Further, it is very similar to the “old way” of planning kaizen events where the goal is to “implement lean tools” … like one-by-one flow.

Setting that direction also seems to run counter to the idea of empowered workers are in the best position to know what to work on. (It doesn’t, in fact direction is required for this to really take hold.)

In another sense, though, the Challenge for one level is, in reality, the Target Condition (or at least a major obstacle) for the level above. If I am asking the VP-Operations what his target condition is, I am going to hear things that sound a whole lot like a Challenge for the next level down.

And if the senior leaders don’t have a clear sense of where they are trying to take the organization next… what is their scope of their responsibility?

What to do differently?

(It might help if the leadership team themselves got a coach.)

1) Be clear that your initial sessions are practice drills. You are not yet playing the game, or even a scrimmage. You are flipping tires. Be conscious that this is a transitory learning stage.

2) Establish a target condition for proficiency you are striving for in your practice. Check it weekly against your current condition. This is the job of the advance / steering team.

Challenge Light

For the first pass, it isn’t necessary to dig headlong into hoshin planning, and in many cases, you can issue a compelling challenge with a theme.

Look at what is bugging your customers about your current operation, and challenge yourself to fix it.

For example, one client had lead times and response times that were getting longer and longer, so the challenges issued by the leadership team revolved around lead time and removing “sources of delay.”

Another company had rework and quality escapes going out of control. Their first step was to “grasp the current condition” and identify where these problems were happening.

image

Each dot represents the origin of a defect or rework. (The colors don’t mean anything, they ran out of red, then orange, then yellow dots.) (You can see exit cycle run charts taped up there as well.)

This gave them a quick picture of where to focus their attention, and which leaders they needed to challenge, and then coach, through the process of improving their quality.

Note that for these guys, integrating the flow of material and information though the plant isn’t a target condition, or even a challenge yet. It is in the vision, but the first priority is simply to ship what the customer ordered, and then to only make the product once to do so.

By the way, profit is measurably up, rework instances have been cut by about 3/4 from the starting point, and they are well on their way.

Competence and Clarity: Toyota Kata at Sea

A friend, and reader, Craig sent a really interesting email:

As I was practicing the coaching Kata with one of the First Mates on the factory trawler, whenever an issue arose (usually with the leader blaming an employee) he began asking factory and engineering leadership “what needed to be communicated?” or “what needed to be taught?” He found it encompassed every problem on the vessel and I loved that he made it his own and communicated in manner to which lifetime fishermen could relate.

What I found really cool about this is how it is exactly the same conclusion reached by David Marquet, both in the sketchcast video I posted earlier, and the titles of two chapters in his book. The reasons leaders feel they must withhold authority, remain “in control” ultimately come down to competence – what must people be taught, or clarity – what have we failed to adequately communicate. Maybe it’s being at sea.

In other words, if people know whGiveControl.pngat to do (clarity), and know how to do it (competence), then leaders generally have no issues trusting that the right people will do the right things the right way.

The Improvement Kata  is a great structure for creating and carrying out development plans for leaders (or future leaders) in your organization.

The Coaching Kata is a great way to structure your next conversation to (1) ensure clarity of intent: Does their target condition align with the direction and challenge? and (2) develop their competence, both in improving / problem solving, but also in their understanding of the domain of work at hand.

 

 

 

David Marquet: Turn The Ship Around

A while back, Mike Rother sent around a link to a sketchcast video of a U.S. Navy submarine skipper talking about the culture change aboard his submarine, the USS Santa Fe. I posted and commented on it below, in “Creating an Empowered Team.” If you haven’t watched it, do so now so you have context for the rest of this post.

Since then, I found other presentations by Capt Marquet (pronounced, I have learned, “mar-kay”), read every post on his blog, then bought and read his book Turn the Ship Around.

His message is compelling, and I have been digesting and integrating it for a couple of months now.

The Empowerment Movement

Back in the late 80’s and early 90’s there was a big push for “empowerment” and the idea of “self directed work teams.”

Supervisors and managers were re-titled as “coaches.”

Work teams were told they were expected to self-organize to accomplish the work at hand.

I suspect this was yet another case of “benchmark and copy” – observing the attributes of high-performance organizations and trying get the same results by duplicating the description. “They have self-directed work teams, so let’s tell our work teams to self-direct.”

In the classic words of Dr Phil… “How’s that workin’ for ya?”

I have worked with, and in, a few organizations with a very bad taste for their past experiments with “empowerment.”

The Difference between “Involved” and “Committed” Leadership

Obviously some organizations have succeeded at creating work environments where work teams know what has to be done and do it. If that weren’t the case, there wouldn’t have been anyone to benchmark and copy.

Capt Marquet’s book gives us a first experience account of a leader who resolved to change the climate of his organization. Admittedly, he did so out of perceived necessity. (Read the book to get the full story!)

Today, though, when leaders say they are “committed” they usually mean they are willing to fund an effort, allow someone else to carry it out, get updates, and give encouragement. That might work for starting a subsidiary, but it doesn’t work for changing “how things get done.”

What we are talking about here is developing the competence and capability of the organization, step by step, individual by individual, as the primary daily work of leadership.

Capt Marquet describes his struggles, setbacks, how hard it was at times, and the long-term reward of his efforts – unprecedented promotion rates or personal successes among his former officers and crew in the 10 years following his time in command. His primary role was developing people. They happened to be the crew of a nuclear powered submarine.

Over the next few posts, I am going to explore the correlation between David Marquet’s leadership development model and Toyota Kata. Stay tuned.

In the meantime, read the book. It’s an easy read and worth your time.

Mike Rother Overview of Toyota Kata

This is a 5 minute edit of the presentation Mike Rother made at the UK Lean summit.

It is a succinct summary of interaction between a coach (leader) and learner (someone working on improving a process).

My thoughts are below the video…

OK – here are some things I have learned with these methods “in the wild.”

Most organizations I have been working with can’t take on 1-3 year challenges and stay the course for that duration. The horizons are too far for them to see what is possible within that kind of time frame and stay the course.

I have been trying 3-4 month time horizons for initial challenges in organizations where everyone is learning the basics at all levels. That gives them an opportunity to practice with a horizon that is less likely to be derailed by a sudden change in direction during that time. Eventually, as they develop capability, they can extend the time horizon and morph these practice challenges into something more formal, linked to the business plan.

Middle managers like to leap onto the coaching questions much too early – before they are capable of actually coaching. The coaching questions are seductive because they are written down and structured.

The PDCA process is much more nuanced, but it must be mastered before attempting to coach. Why? Because the coaching process is application of PDCA toward the learner’s development.

While it is OK to round-robin coaching and actual process improvement, everyone has to work together to reflect and learn.

In addition, those middle managers tend to try to leap into coaching before they have an internally set non-negotiable sense of “True North” – driving toward better and better flow.

When a middle manager is taking on the role of the “learner” there is a great temptation for him to delegate tasks to others, and get reports. This is status quo, and does nothing at all to develop capability.

Like everything else we do in the West, or at least in the USA, we try to get there fast by skipping the basics.

Make no mistake – you don’t “implement Toyota Kata.”

You use it as a structure to build foundational capability and new thinking patterns.

Those patterns are only developed through practice, and deliberate reflection on the management process itself.

I have also seen an organization that is “getting it” pretty quickly. The difference is that they are all overtly in “we are just learning this” mode, and willing to make mistakes and learn from them vs. trying to appear to be competent from the get-go.

Mike Rother has other videos on YouTube as 734Mike.

“True North” – Explicit or Intrinsic?

compassOne of the factors common to organizations that maintain a continuous improvement culture is leadership alignment on an overall direction for improvement – a “True North” – that defines the perfection you are striving for.

Steve Spear describes Toyota’s “Ideal” as:

An activity or a system of activities is IDEAL if it always produces and delivers:

(a) defect-free responses (those that meet the customer’s expectations),

(b) on-demand (only when triggered by the customer’s request),

(c) in batches of one,

(d) with immediate response times,

(e) without waste, and

(f) with physical, emotional, and professional safety for the supplier.

(From The Toyota Production System: An Example of Managing Complex Social / Technical Systems, Steven Spear’s PhD dissertation, 1999, Harvard University)

You (and I) can quibble about some of the semantics, but overall, this is a pretty good list.

Mike Rother (not coincidently, I am sure) puts up something quite similar in Toyota Kata:

…Toyota has for several decades been pursuing a long-term vision that consists of:

  • Zero defects
  • 100% value added
  • One-piece-flow, in sequence, on demand
  • Security for people

Toyota sees this particular ideal-state condition – if it were achieved through an entire value stream – as the way of manufacturing with the highest quality, at the lowest cost, with the shortest lead time. In recent years, Toyota began referring to this as its “true north” for production.

As I have tried to emphasize the importance of a leadership team having a clear sense of “True North” I have noticed that many of them get bogged down in trying to develop and articulate a concrete statement. (This is partly my fault, and I am revising my training materials to reflect what I am writing here.)

What I am realizing is that this is more of an “attractor” than a rule set. Let me explain through a bit of digression.

When we see something, we have an immediate emotional response. Generally it is attraction toward something we see as good (or are curious about); or avoidance of something we see as fearful or dangerous.

We construct a logical reason for that emotional reaction several tenths of a second after that emotional reaction is firmly anchored. Thus, our logic follows, rather than driving, our responses to things. This happens so fast that we are not usually aware, but two people seeing the same thing can respond very differently based on their individual background and experience. I don’t want to dive too deeply into psychology here, so I’ll pull back out of this.

“True North” sets the direction of process improvement because there is high alignment on what kinds of process changes are attractive vs. those which should be avoided. When I say “attractive” I mean “we want to actively move toward them” meaning the organization will expend energy, ingenuity, and resources to do so. This is how continuous improvement is driven.

If I am right, then “True North” is more of an “I know it when I see it” kind of thing than it is a carefully articulated statement.

If I look at other businesses who are (or have been) pretty well aligned with their efforts, I can see the same kind of thing.

For example, though I doubt that it is articulated internally in this way, it has been pretty clear to me “Windows Everywhere” has been something that sets (or set) overall direction within Microsoft. (I’ll admit I don’t have as strong a sense of this as I did in the late 1990’s when my social circles included a number of people who worked there.)

A local hospital does articulate theirs, but it also makes sense: “No wait, no harm.”

Most organizations I have dealt with, though, don’t have a good sense of long-range perfection. They are mired in the details of today, tomorrow, this quarter.

They might have some kind of “vision” or “mission” statement, but often those are paragraphs that are carefully constructed to address constituencies (“Satisfying our customers while delivering maximum shareholder value and being a great place to work, blah, blah”)

Those “visions” though are rarely actively used to guide conversations or decisions, much less continuous improvement.

Since I believe this is a gap these teams need to close if they are to shift toward a continuous improvement culture, I need to improve how I am getting this across to them.

So… the next thing I am going to try is to rework my “True North” instruction and do a better job of framing it as something to actively move toward rather than something to try to logically articulate.

“True North” may be more of a feeling rather than a logical test.

This means that the job of the teacher / practitioner / change agent is to hold on to that “True North” during your coaching until the leaner “gets it” and starts actively seeking solutions that move in that direction.

Learning vs. Knowing (or not)

PC once again left a provocative post in the Lean Thinker’s Community, and gave us a link to this Tim Harford TED talk that drives home the point that learning and improvement is more about rapidly discovering things that don’t work than about designing things that do.

Trial and Error

Tom Wujec makes the same point in the Marshmallow Challenge. In that video, Tom talks about how 5 year old kids out perform most adult groups in a problem solving / learning game. While the adults engage in a single cycle of “know-build-fail” the kids engage in multiple cycles of “try-fail-learn-try again.” In the improvement world, we call this process PDCA.

Harford’s key point is that learning only happens through a process of trial of large numbers of ideas, followed by the selection and further trials on the best ones.

Hmmm… that sounds a lot like the 3P process of “Seven Ideas” as well as “Set Based Design.”