Category: People Development

Posted on

Lean Process and Product Development: The Role of the Leader

The LEI was kind enough to send a review copy of their new book, the second edition of Lean Process and Product Development. I have just started it, and am already finding gems. (note to the LEI – the Kaizen Institute is not my address. Thanks to Jon for getting the book to me.)

The original edition was a cleaned up manuscript that was published well after the death of Allan Ward, and bore only his name on the cover.

This edition adds Durward Sobek to the author line. Sobek was a student of Ward and today stands on his own as someone whose views should be respected.

I am not going to try to compare the two editions, rather look at this new book as it stands on its own.

Rather than wait and write a big long review, I am going to publish short posts as I come across key points of note – hence the subtitle of this post.

I am already seeing a tight link to the leadership model outlined in Toyota Kata.

In the 2nd chapter, as the authors discuss Value and Performance of development projects (as in how efficiently they create profitable value streams and create usable knowledge for future projects), I came across a compelling quote:

A general manager of Toyota’s Advanced Vehicle Development department was asked how he spent his time.

He replied he spent about 2 hours a week doing administrative work, and the rest of the time “on technical problems.” Before I remark about the “technical problems” consider the first bit. How much time do your department heads spend administering vs. contributing to the development of the organization?

And that leads to the second part. He says:

“But every technical problem is also a personnel problem, because the problems don’t get to me if my people know how to solve them. So all of the time I’m working on technical problems, I’m also teaching someone.

To paraphrase the next paragraph in the book, the solution to personnel problems is to teach.

So I’ll digress from this book a bit here, and read between the lines a bit. If we go back to David Marquet’s sketchcast video he talks about the necessity of creating an environment where your people need to discover the answer, or “you’re always the answer man, and you can never go home and eat dinner.” (This is really hard when you know the answer, by the way.)

So already, in the first couple of chapters, we are establishing an environment that doesn’t simply produce engineering designs. Those, I suspect, are an outcome of deliberate processes to build the organizational competence and clarity.

We’ll see. More to come.

Posted on

Reviving How To Make Things

Almost three years ago I wrote “Don’t Lose How To Make Things.”

In that post, I wanted to emphasize the risks of losing your expertise in the technology and skill required to make your product. Too many companies today seem to be bent on replacing those skills with financial ones.

Today I came across a fascinating article on Bloomberg’s site about how Toyota has come to the same conclusion.

You can read it here: ‘Gods’ Make Comeback at Toyota as Humans Steal Jobs From Robots.

In short, they have established workshops where workers manually produce parts that are normally made by automated processes.

A worker welds an automobile part in the chassis manufacturing department at a Toyota Motor Corp. plant in Toyota City.

The idea is to maintain understanding of how things are made so they do not lose the skill required to improve their production processes.

“Fully automated machines don’t evolve on their own,” said Takahiro Fujimoto, a professor at the University of Tokyo’s Manufacturing Management Research Center. “Mechanization itself doesn’t harm, but sticking to a specific mechanization may lead to omission of kaizen and improvement.”

One result?

In an area Kawai directly supervises at the forging division of Toyota’s Honsha plant, workers twist, turn and hammer metal into crankshafts instead of using the typically automated process. Experiences there have led to innovations in reducing levels of scrap and shortening the production line 96 percent from its length three years ago.

Toyota has eliminated about 10 percent of material-related waste from building crankshafts at Honsha. Kawai said the aim is to apply those savings to the next-generation Prius hybrid.

Today’s financially driven managers are unlikely to allow the space to experiment and learn. Instead, they want a deterministic process so next quarter’s results can be forecast accurately. It isn’t good to surprise the analysts.

At the same time, though, companies are pressing for things like “innovation.” That doesn’t happen in a breakthrough. It happens through the rigorous application of the skill of expanding knowledge. Once enough knowledge is accumulated, expertise develops and innovation follows.

Years ago, when I was working for a company making heavy equipment, one of our Japanese consultants (who had worked many years directly for Taiichi Ohno) urged our engineers to hand-form sheet metal parts – with hammers(!). We didn’t do it. But now I understand what he was trying to get us to do.

Posted on

What Is “Lean?”

I did a Google search on the terms [ lean manufacturing definition ]   . Here is a smattering of what I found on the first page of results. (I did not go on to the second page.)

On the lean.org site we get a page with about 10 paragraphs describing the general outcome, philosophy, and what it isn’t.

On a consultant’s web page we get a list of principles and terminology definitions.

The U.S. Environmental Protection Agency (EPA) says “Lean manufacturing is a business model and collection of tactical methods that emphasize eliminating non-value added activities (waste) while delivering quality products on time at least cost with greater efficiency.”

Tooling U defines “lean manufacturing” like this: “An approach to manufacturing that seeks to reduce the cycle time of processes, increase flexibility, and improve quality. Lean approaches help to eliminate waste in all its forms.”

Another consultancy has a PDF of “Lean Sigma Definitions” that includes Lean Manufacturing or Lean Production: “the philosophy of continually reducing waste in all areas and in all forms; an English phrase coined to summarize Japanese manufacturing techniques (specifically, the Toyota Production
System).”

Let’s Rewind a Bit

What all of these definitions have in common is they are attempting to describe some kind of end state.

Over the last 10 years or so we (meaning those of us who are doing top drawer research) have put together a pretty comprehensive picture of how Toyota’s management systems are intended to work. (I say “intended to” because we are always dealing with an idealized Toyota. They have issues as well, just like everyone.)

What we seem to try to do is try to create a generic context-free definition of what Toyota is doing today.

But they didn’t start out that way. Everything they are, and do, evolved out of necessity as they struggled to figure out how to take the next step.

Toyota didn’t engineer it, so I don’t think it is something we can reverse engineer. Toyota evolved it organically. They applied a common mindset (a dedication to figuring things out) to a specific goal (ideal flow to the customer) in a specific set of conditions.

So What is “Lean?”

Mike Rother makes a really interesting attempt at resetting the definition of “lean” as being about the drive and the mindset that resulted in Toyota’s management system.

Give it a read, then let’s discuss below. (Since you are going to see it – when he sent it around for input, I passed along a thought which he has added verbatim in the last slide. Maybe that will spark a little more discussion.)

 

OK, are you back?

I like this because I think anyone who adopts the mindset that they (and I mean “they” as a true plural here) must take it upon themselves to figure out what they do not know, figure out how to learn it, figure out how to apply it, all in a relentless pursuit of perfect flow will end up with a nimble, empowering, relentlessly improving, formidably competitive team of people.

Focus on the process of learning, focus on the people, and keep them focused on the customer, and you’ll get there.

In my experience, the differentiator between organizations that “get there” and those who don’t comes down to the willingness to work hard to learn it themselves vs. wait for someone to tell them the answers.

Thoughts? Maybe we can take the “most comments” record away from the “Takt Time Cycle Time” post.  *smile*

Posted on

Jeff Liker: Is Lean a Waste Elimination Program or Striving for Excellence?

Jeff Liker asks (and answers) the title question in a great Industry Week blog article by the same title.

One of the biggest obstacles we in the lean community need to overcome is our own inertia around “Lean is a process for finding and eliminating waste.”

In the article, Liker brings up a point that is often lost on us: Looking for the problems and negative things kills morale.

The “waste” that you see is the result of underlying issues and culture. Stop overproduction in one place, and it either returns or pops up elsewhere because the underlying reasons for it were never addressed.

Operations that are not operating at a high level of lean typically are lacking underlying process discipline, which leads to these problems and they proliferate daily as the company is in a constant firefighting mode. Trying to eliminate waste in the current system and culture is like identifying and fighting problems—it is debilitating and a losing proposition.

[Emphasis added]

I bolded that phrase for a reason.

We aren’t talking about a technical implementation here. We are talking about a shift in the underlying culture – the habitual ways people interact with one another, with the process, respond to challenges and problems.

Today we have, thanks to Jeff Liker and a few others, an excellent picture of an ideal version of Toyota. We know what it looks like.

Getting there is an entirely different proposition, as most companies that have tried this stuff know first hand. It is hard.

What is beginning to emerge, though, is that the thinking pattern that is learned through solving these problems the right way (vs. just implementing tool sets) is the same thinking pattern required to shift the culture.

It is hard. You have to do the work. But the way to get there is emerging.

Posted on

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.

Posted on

Toyota Kata “A3 Problem Solving”

Over the years, I’ve been exposed a number of efforts to “implement A3 problem solving” in various companies. I worked for some of those companies, I’ve observed others.

The results are nearly always the same.

Here are a couple of examples. Let me know if any of these match up with experiences you have had.

Example 1: The company had put many people through “Practical Problem Solving” training and was (ironically) trying to measure how many problem solving efforts were underway.

I was watching a presentation by one of these problem solving teams to management. Their A3 was on a computer, projected onto the screen. They were reporting their “results.” Yet there were large discontinuities in their problem solving flow. The actions they were taking simply did not link back (through any kind of identifiable cause) to the problem they were solving.

The management team listened carefully, applauded their efforts, and moved on to the next topic of their meeting.

Example 2: A different company had a form to fill out called an “MBF” or “Management by Fact.” From the labels on the boxes, it was clearly intended to be structured problem solving. By the time I worked there, however, “MBF” had become a verb. It was a solo activity, filling out the form at the desk, and reporting on it in a staff meeting.

Example 3: Well-meaning former Toyota team members, now working for a different large company wanted to “train everyone in problem solving.” They put together a “class” that presented the purpose of each block on their A3 form with the expectation that people would adopt the process.

All of these efforts had something in common.

They didn’t work.

Over the last few days, I’ve been privileged to be included in an email exchange about the relationship between A3 and Mike Rother’s Toyota Kata. My small contribution was apparently enough to get my name onto the cover, but I want to give a real nod in the direction of a Jenny Snow-Boscolo for instigating inspiring a really good exchange.

The result is here. I think this presentation does a really good job of summing up the relationship between Toyota Kata and Toyota A3. Thanks to Mike Rother for taking the initiative and putting it all together (more below)

One of the difficulties with gaining insight into Toyota’s management processes is that they really aren’t codified. This shouldn’t be a surprise. Look at your own company, and ask how much of the culture – the reflexive way things are done and interactions are structured – is written down.

(In fact, if it is written down, I would contend it is likely your actual culture has little resemblance to what is written about it. Those things tend to be more about what they wish the culture was.)

Culture, any culture, is learned through daily interaction. This is all well and good in cases where people are immersed in it from the beginning.

But the rest of us aren’t operating in that problem solving culture. Rather, we are trying to create it. And as the former Toyota Team Members from Example 3 (above) learned, it isn’t a simple matter of showing people.

Rather than two different things, we are looking at a continuum here. At one end is the culture described on Slide 9. There isn’t any formal structure to it, the process for teaching it isn’t codified. It is learned the same way you learn the way to get the job done in any company. They just learn different things than you did.

But in another organization there is no immersion. If there is anyone who is steeped in The Way, they are few and far between.

In these cases, we want to start with something more overt. And that is the purpose of having a rote drill or kata. It isn’t something you implement. It is a structure, or scaffold, to learn the basic moves. Just as mastering the musical scales is only a prelude to learning to play the instrument, the kata is the foundational structure for learning to apply the underlying thinking patterns.

So… if you are working on kata, it is critical that you are reflecting on your thinking patterns as much (or more) than you are reflecting on your improvements. It might seem rote and even busywork at first. But it is there to build a foundation.

Posted on

Navigating the Learning Hairball

Credit: A lot of stuff comes across my screen, sometimes more than once. I have seen this illustration several times, but don’t remember where it originally came from. If you created it, PLEASE comment so I can give appropriate credit.

Improvement is messy. Science is messy. Research and Development is messy. These are all cases where we want an outcome, are pretty sure what that outcome looks like, but there isn’t really a clear path to get there.

This illustration has illustrates two very different mindsets.

On the left is how many people believe the improvement / organizational development / learning process works. We set out a phased project plan to transform the organization. We carry out a set of pre-defined steps, and when they are completed, we are at the goal.

Sadly our education process is largely constructed on this model. Take the classes, pass the tests, the student is educated.

This thinking is appropriate when the outcome is something we have done before, like constructing a house. Even if this house is a bit different, the builders have rich experience in carrying out all of the constituent process steps. Further upstream, the designer carefully followed building and construction codes. In those cases, we are applying a rich body of experience (or the documented experiences of others) to reach the end goal.

These tasks can be scheduled and sequenced in a project plan. The steps are known, the result is known.

 

image

On the right is the hairball of learning and discovery.

We know where we are starting.

We know where we want to end up.

We are reasonably certain we can get from Point A to Point B. But we don’t know precisely which detailed steps or experiments will give us the results we need.

We don’t know for sure that the next result will be a forgone conclusion from the next action step.

Each step gives us more information about the next step.

In the world of continuous improvement, we live in an interesting paradox.

We often believe we are operating in the set-piece model on the left. We see a situation, we apply tools to duplicate a solution we have seen work in a similar situation before.

An interesting thing happens at this point. The Real World intervenes, and we discover that the situation was actually more like the right side. We thought we knew the right answers. We might have even been mostly right. But at the detail level, things don’t work quite as we predicted.

Now… if the system has been deliberately set up to flag those anomalies, and we are recording them and being curious to discover what we didn’t understand then we are in learning mode.

But all too often the experts who guided the original installation have moved on, leaving the people executing the process behind. The assumption was “It works, we can go to the next problem.”

The people in the process did what they were told, or guided, to do. We might have even asked for their input on the details. But that process rarely leaves them with additional skills they need to deal with anomalies in ways that make the process more robust.

So they do what they must to get things done. Mostly that means adding some inventory here, some additional checks or process steps there. Over time, the process erodes back to something close to its original state.

Why? Because we thought we knew everything… but were wrong. And didn’t notice.

This model applies to any effort to shift how an organization performs and interacts. We outrun our headlights and take on the Big Change because that company “over there” does it, and we just copy the end result.

What we missed was doing the work.

More about this later.

Posted on

Creating an Empowered Team

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

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

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

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

“What did you expect to happen?”

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

“What actually happened?”

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

“What did you learn?”

“That empowerment doesn’t work.”

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

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

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

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

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

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

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

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

GiveControl

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

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

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

See the illustration above.

Competence and clarity.

I am going to start with the second one.

Clarity

Or… where the hell are we trying to go?

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

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

Doesn’t work. Never has.

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

Competence

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

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

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

In Lean Thinking world, competence means a few things.

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

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

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

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

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

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

First, I gave them answers and explanations.

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

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

“Captain, I propose we submerge the boat.”

“What do you think I am thinking?”

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

“How would you know it is safe?”

In other words…

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

So here is a challenge.

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

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

Posted on

Active Control

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

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

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

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

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

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

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

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

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

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

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

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

“Waste is often disguised as useful work.”

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

How do we stop the cycle?

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

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

Here are some fundamental questions to ask yourself:

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

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

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

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

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

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

An Active Control System

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

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

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

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

The hard part is what is supposed to happen next?

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

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

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

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

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

As a minimum

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

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

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

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

Posted on

The Struggle

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

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

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

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

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

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

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