Tag: Leadership

Posted on

The Structure Behind Leader Development

Chapter 3 of The Toyota Way to Lean Leadership is titled “Coach and Develop Others.”

Where in Chapter 2 the authors were outlining the individual leader’s responsibility for self-development, now they are describing the environment and the process of supporting and focusing that drive.

Rather than just outline the chapter, I want to dig into some key elements of the context that Toyota creates for their leaders.

First is the expectation that leaders lead.

Leading vs. Delegating

Chapter 3 has a great story that exemplifies the key differences in management styles that I alluded to in the post about Chapter 2.

In that story, NUMMI has equipment reliability problems in the body shop. Mr. Ito, the President has instructed Convis to have each engineer prepare and present a one page report for every breakdown lasting over 30 minutes. The telling moment is Convis behavior in the presentations:

While Ito was critiquing the [A3] presentations and reports, Gary [Convis] simply stood to one side, marveling at Ito’s insight and amused at the struggles of the engineers’ efforts to learn this way of thinking.

This quote nails the core issue we have to deal with in any company that wants to succeed with lean production.

Convis was newly hired from the U.S. automobile industry, and was acting exactly as he was trained as a manager. He was acting as every manager in the USA is trained.

He has delegated the process of training the engineers to Ito, who he sees as the technical expert. Convis viewed his presence here as overseeing how well his engineers are responding to that training.

Ito, though, had other ideas.

After a few sessions, Ito asked Gary how he was coaching the engineers through the process before the presentations. Ito pointed out that there was still a lot of red on the reports, and if Gary had been teaching the engineers properly, there would be less red ink. […] problems with the reports were a reflection of Gary’s leadership, and he was more responsible for any failures than the engineers were.

Zing.

You can’t even cite “If the student hasn’t learned, the teacher hasn’t taught” here because the delegation paradigm was so strong that Convis didn’t realize he had responsibility for being the teacher.

Convis, of course, “got it” and began seeing the red ink as his failure, rather than the engineers’. The drive for self-development kicked in and worked. And of course, in the process of struggling to coach the problem solving process, he had to struggle to learn it well enough to do so.

Personally, I see the idea of delegating and then passively overseeing improvement and people development is a cancer that is difficult to excise from even the most well intentioned organization.

I have seen this with my own eyes – senior executives struggling with how to “implement lean.” What was their concern? What metrics they could use to gage everyone’s progress through reports to corporate headquarters. They simply saw no need to get personally involved in learning, much less going to see, and certainly not teaching, the messy details. Not surprisingly, that company still struggles with the concepts.

Of course it cascades down from there. The various sites’ leaders follow the example, and delegate to their professional staff people. The staff’s job? To come up with “the lean plan” and “drive improvement” while the leaders watch. At some point, someone in charge of the operation actually has to do something different, but that, it seems, is always the next level down.

I am not going to get into what stops leaders from stepping up to this responsibility or what do to about it because that would be a book in itself.

It doesn’t help that, with the revolving-door of leadership we often encounter, each new leader comes in with the old mindset. OK </rant> and back to the book. Smile

The Technical Support

This expectation of leaders leading does not operate in a vacuum. Toyota processes are deliberately set up to remove any ambiguity about what the next challenge is by surfacing problems immediately

In the words of Lean Leadership, these problems are framed as challenges for leader development.

In a much earlier post, I objected to our western euphemism of “opportunity” when we meant “problem.” My objection was treating this “opportunity” as an something that could be taken on, or not.

A challenge, especially in the context of leader development, isn’t optional. A top level athlete grasps the meaning of a challenge. He is driven to take it on and push himself to meet it. He improves in the process. It isn’t about the record, per se, it is about what he must develop and pull from within himself to get there.

Just as the world-class athlete has a stopwatch on every lap, the assembly line is set up to verify the timing of every cycle. Any discrepancy is immediately apparent to both the team member and the leaders. If the work can’t be done, the line is stopped and things are made right. Then we figure out why. And everyone learns.

TPS […] creates a never-ending stream of opportunities for on-the-job development and increased challenges. Toyota sensei do not need to create artificial training situations […]. The daily process of producing cars generates all the development opportunities and challenges that are needed.

If your organization has trouble finding problems, it isn’t because they aren’t there. It is because your processes are blind to them. That is why “No problem is a big problem.”

The key is that when we talk about “implementing the tools of lean” we are doing nothing more than setting up the baseline process to present the challenges for leadership development. That’s it. It is the difference between playing a casual game and deciding to keep score.

You can’t improve without keeping score, to be sure. But keeping score alone doesn’t cause things to get better. If anything, it increases people’s frustration because they see they are coming up short, but don’t have the support or opportunity to do anything about it.

What happens then? They start seeing problems as “normal” and start blinding the system. They add padding to cycle times to “allow for variation.” They decouple processes and put in extra inventory. They start running two at a time, then four, and return to batching.

If a problem remains hidden below the surface long enough, it can stop being perceived as a problem and become part of normal operating procedure.

OK, so I’ve beaten that to death yet again. It is critical to structure the work so that we can see whether things are going as planned or not.

But it is just as critical to have the problem solving processes engaged immediately. If those processes don’t yet exist, you have no hope of your so-called improvements sustaining for long.

That’s not all. There is another standard that is just as critical – if not more: A standard for problem solving.

The A3

We just got done exploring how critical it is to have a process that is totally transparent. Why? So we can clearly see any difference between how it is and how it should be.

The purpose of the A3 is to provide that level of visual control to the problem solving process itself.

And yes, problem solving is a process. It follows standard work. It is perhaps the most critical thing to standardize. The only way to gain skill at something is to practice against a clear standard. It really helps to have a coach watching your every move and calling out small adjustments, things you need to pay more attention to the next time you do it (which should be immediately).

The A3 is the game film, the slow motion camera, the visual control of how problem solving is being done. It is not sufficient to find the solution. It is more important to develop a consistent approach to problem solving across the entire organization.

But outside of Toyota and a few companies that are starting to grasp what this is about, the A3 is, sadly, one of the more recent fads in the lean community.

An A3 isn’t something you tell someone else to do. It is a visual control, just like the moving line, that works only in the context of direct observation and participation by all parties involved. In the above story, Ito was setting an example, and expecting Convis to follow it. Once that started happening, Ito’s participation shifted from coaching the engineers to coaching Convis as he coached them.

Just as the tools of takt time, standard work, pull systems, etc. do not stand alone and “make you lean,” neither does filling out A3 forms. Even if you have “the tools” and a problem solving process, it doesn’t help if they are not intimately linked together.

All of these things are designed for 1:1 interaction. They are messy testaments to the fact that problem solving often loops back to previous steps as more is learned.

The Big Picture

This chapter provoked a lot of thought for me, and I have tried to share some of that. When / if you choose to read the book, I hope you have your own thoughts, and even share them here or in the forum (that could use some life right now).

Fundamentally, Chapter 3 is about the phenomenal support Toyota provides those leaders who have the self-motivation to learn.

  • Every operation is structured to provide challenges and opportunities for them to develop their skills. There is no shortage of things that obviously need improving.
  • Every leader is positioned to teach and mentor those who are willing to step up to the challenges that are there.
  • The problem solving process itself is structured as standard work so that a prospective leader can practice against a standard and improve skill through repetition and coaching.

Aside from a couple of case studies and examples, this chapter is a bit of a synopsis of Toyota Kata. I continue to bring Kata into this discussion because there is obvious overlap in topics, and I see these two books complimenting each other. Kata gets into the nitty-gritty of how problem solving and coaching happens. Lean Leadership is providing a context and case examples of the entire ecosystem.

More to follow.

Posted on

The Annual Operating Wish

As we approach the end of the calendar year, many companies are starting to work on their Annual Operating Plans Wishes for next year.

Why do I say wish? Because all too often these plans dictate what they wish would happen. Throughout the year, performance is “measured” against the plan. Positive variances are rewarded. Negative variances are, well, not rewarded.

To make things more interesting, each department: Sales, Production, Purchasing, etc., is responsible to meet the plan independently of the others. That makes sense, it is the only way they can be “held accountable.”

So when sales fall short in 1st quarter, production keeps producing. They have to. Otherwise they wouldn’t meet their AOP numbers.

To make things more interesting, if the sales mix changes from the original plan, and there is a raw material shortage that prevents shifting the production to match sales, production just makes whatever the can, whether it is selling or not.

It is pretty easy to think this through to a process of running overtime on weekends to build a product that was sold at a discount to “make the numbers” in the AOP.

The hilarious thing is that I have yet to meet a manager, at any level, who does not agree that this is exactly what happens, and that it is a poor way to run the business.

Yet we keep doing it over and over.

OK, so what to do about it?

The most important thing to grasp is that “the plan” is just that. It is not a fact. It is a working hypothesis, a prediction. It is wrong the day it is made. (If you can perfectly predict the future, why are you reading this?)

The purpose of making a plan is to identify the unexpected. If the sales mix and numbers start to depart from the plan, the entire system responds. This isn’t every department for themselves. (or shouldn’t be) This is about running the company to maximize total margins.

That means working together as a team with one plan, not a separate one for everyone.

Posted on

‘Tis The Season for Management by Measurement

It must be that time of the year. I see traffic in the online forums asking about how to set key performance indicators for lean staff people so their performance incentives can be set.

If anyone were to ask my advice here, it comes down to one word:

Don’t.

Two reasons.

First, we have overwhelming evidence that these incentives not only don’t work, but they actually make performance worse in the kinds of work you are asking these people to do.

The Overjustification Effect

Dan Pink on motivation

All of this is consistent with what Deming told us decades ago, yet we keep doing it.

The second reason is inconsistency and misalignment.

Having the continuous improvement staff operating to separate metrics disconnects their efforts from line management’s. They become responsible for improving the operation while the line management processes are… what?

The message to the shop floor team is pretty clear here. They can read an organization chart. Do what the boss says, then, if we have time, and if the improvement guys can make the case, then maybe listen to what they have to say.

If you must have management-by-KPI, then the performance measurement for continuous improvement must be exactly the same as the line manager being supported. Why?

The question I would ask is “Who is responsible for the performance of the organization?” If it isn’t the line leader, then why does that position exist?

It makes no sense whatsoever to have the lean implementer working to a different agenda.

Our management traditions of de-aggregating and delegating are not serving us well. We need to take a systems view and realize that everything is inter-related. Further, we need to grasp that B.F. Skinner’s (dubious) research on rewards-based-behavior simply does not apply to management. Never has. Wishing otherwise isn’t going to change it.

Posted on

The Tough Decision: What Not To Do

Today’s Dilbert strip highlights a situation that is only funny because it happens so often:

The idea that a company can focus on 25 key areas, or 125 key performance indicators (yes, I said 125 because I have seen it myself) is obviously ludicrous.

Of course a manager has a legitimate concern to ensure people don’t take their eyes off things that are important to focus on something else.

But the leader’s role here is to ensure there are processes and systems in place that anchor the routine things. Further, those processes and systems need to be designed to alert the appropriate people when something goes out of control, or past a boundary.

Without having any routines the manager has no choice but to make everything something to focus on.

Because there is no standard process, everything must be managed as an exception.

This stresses the organization because in reality they can only micro-manage a few things at a time. It is left up to the people to decide what isn’t going to get done. The bosses response at that point is going to be negative no matter what they accomplish. “Respect for people” does not play here.

Leader’s toughest job is deciding what we are not going to work on right now. It isn’t as tough as it seems because if a focus or challenge is selected well, it actually organizes the problem solving effort to pull just about everything else in behind it.

Let’s take an example from a previous post: On time delivery.

If we say “We are going to emphasize “on time delivery” as a theme or challenge this year, what kind of things might people end up working on?

  • Having every operation start on time.
  • Sources of delay.
  • Quality issues (which cause delays)
  • Safety issues (also cause delays)
  • Visual controls and good response to problems (to get on top of problems quickly)
  • Equipment reliability.
  • Setting a good operational takt time.

The list goes on. But by having a decent challenge, the local area can focus on the things that are impacting their ability to deliver on time. It isn’t necessary to make a laundry list of everything that could cause a delay and measure it from the top of the organization. If you do, everyone’s energy is dissipated working on problems that they don’t necessarily have.

Of course this is all based on having a leadership process that gets down to the work area, grasps what people are actually working on, and coaches them through the process of aligning their efforts and solving the right problems in the right way.

Hmmmm… so does that mean that the #1 thing to focus on if you want consistent on-time delivery might be leadership development?

I guess I need to get back to the Liker and Convis book.

Posted on

Leadership: Deal With The True Constraint

I am starting to read a review copy (courtesy of McGraw-Hill) of Jeff Liker and Gary Convis’ new book, The Toyota Way to Lean Leadership. (The hot link goes to my Amazon page.)

In the spirit of one-piece-flow, I am to share key thoughts as I go rather than save everything for a thousand word review at the end.

One of the first points that comes out – in the prologue no less – is the acknowledgement that people development is a constraint to growth that you ignore at your peril.

One of the results of Toyota’s breakneck pace of growth in the first half of the last decade was that they were still making North American decisions in Japan.

They were doing this because, in the authors’ words, “…Toyota did not develop enough leaders, or did not develop leaders that it trusted sufficiently, in the North American operation to allow decisions making and problem solving to be as close to the gemba as they should have been.”

But rather than say “we grew too fast,” the President, Akio Toyoda sees the limits and the relationship:

“The problem was that the pace of growth was faster than the pace of human resource development… It is not the growth pace itself, but it is the relationship between the pace of grown and the pace of [people development].”

When traditionally trained managers think about constraints to growth, they typically think about things they can buy. “People” as a constraint comes in only as a hiring problem.

But it takes time to develop “people” into a team that thinks and moves in unison. Today’s leaders, up to this point Toyota included, underestimate both the time and the effort it takes to do that.

Any good sports team knows what it takes to build a team. So does the military. We understand the science, the psychology. But perhaps because it is difficult and sometimes messy to deal with people (and it is certainly impossible to reduce the effect of good teamwork to a stoplight report and a spreadsheet), “people development” gets delegated to HR, or people are sent to classroom training and given “certifications.” Doesn’t work, never has.

Akio Toyoda was acknowledging an uncomfortable truth – that they had fallen behind on people development and they had continued anyway, without pulling the metaphorical andon and addressing the issue as soon as it came up.

This simple insight hits at the very core of what we, as a community, need to address, and what the flag-bearing institutions in our community still need to fully embrace.

“Continuous Improvement” means “continuously improving people.”

While just about every “lean overview” I have ever seen uses some form of lip service to the concept of “people based system” everything then goes straight into describing the technical characteristics of everything but how people are developed.

What I like is that in the last couple of years the mainstream books are starting to address this topic in a meaningful way. This, of course, isn’t the first of Jeff Liker’s books to hit here. And Toyota Kata is really the first to address the mechanics of people development as thoroughly as we have addressed the mechanics of kanban.

I am liking what I am reading in this book so far, and I’ll be working to correlate what I read with other works out there plus my own experiences. This should also tie in nicely with points I want to continue to make on Bill Constintino’s presentation.

Stay tuned.

Posted on

Support vs. Involvement

I spent last week teaching three sessions of Job Instruction. One session at the end of night shift starting at 5am, the second session catching the start of day shift at 7am, then the third session for swing shift at 1:30.

What is cool, though, is there is a senior member of the site leadership team in every session. They are not just observing, they are active participants.

Next week those leaders, with input from the team members in the class, are going to caucus and discuss the ramifications and how to deploy this method across their operations.

This is critically important because just teaching a few dozen people a skill and expecting them to each apply it independently doesn’t work. The company has to also develop the ecosystem that it can flourish in.

But this has been the pattern from this company from the beginning.

The Operations Manager has been leading the operations kaizen teams, working hard along side the team members to develop disciplined, effective pull systems. This is a high-variety product mix, with lots of different routings, so there were some real challenges to overcome. I was really impressed with their application of what would normally be very advanced thinking.

Results? Over the last six months, their metrics have taken a clear turn upward. You can see the inflection point on the graphs. Their company sister operation is starting to take notice. Good things all around.

A plant manager once shared a conversation he had with his CEO. The teaching is important, but what makes it work is willingness to be taught.

When we talk about management involvement, this is the crux. This team has been curious, willing to try and explore things – in front of their team members – and willing to keep at it until they figure out how to make it work.

That’s what it takes.

Posted on

Mike Rother: Time to Retire the Wedge

Note – this post was written pretty much simultaneously with a post on the lean.org forum.

Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”

Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.

The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.

Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.

There are some interesting assumptions embedded in the “wedge thinking.”

The first one is that “the standard can be ‘held’ by the people doing the work.

That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”

With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.

Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)

This is the approach of control. The standard is fixed until we decide to change it.

Taiichi Ohno didn’t teach it this way.

Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.

Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.

We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.

The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.

Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.

The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.

I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.

It is time to actively refute the model.

If you own your corporate training materials, find that slide (it is in there somewhere) and change it.

If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”

“What, exactly do you expect the team member to do?”  That sparks an interesting conversation which reveals quite a bit.

Posted on

“Find the Bright Spots”

One of the problems facing all of us – from pundits to practitioners alike – is “too much information.” We look at a complex state, like the way Toyota operates, try do describe it in great detail, break it down, build models, and say “OK, make it look like that.”

So one of the most common questions is “Where do I start?”

The platitude is “start with 5S” but in reality, that doesn’t really work very well either. It doesn’t really drive a cultural and behavioral shift. If you have to audit people into compliance, that’s how it is working for you.

What we know today is that TPS is much less about how it looks than it is about what people do.

I have seen a handful of other companies who have managed to get a true continuous improvement culture running (at least for a while). There is something very different about them vs. a standard “lean implementation.”

Yet these companies have the same caliber of people, the same resources, the same baseline problems as everyone else. They operate in the same environment, and yet operate differently.

A key point in Switch is “find the bright spots.” That is – look at who has success in the same environment, and grasp what few factors are actually making a difference.

Perhaps, rather than “looking for waste” we ought to be looking at what few things make a big difference. Just a thought.

Posted on

Why Don’t They See This Is Better?

“Resistance to change” is a common theme of discussion among practitioners on various online forums, as well as in emails I get from readers.

One thing I see fairly often is that a practitioner will be suggesting a visual control or a specific application of a “lean tool” as a “better way” in the process being examined.

“They can just look it up on the computer,” say those holding on to the status quo, “why do we need to put up a board?”

Why indeed?

So the practitioner tries to make a logical case, and often comes away frustrated. “Leaders aren’t supporting the changes” is a common lament at this point.

But let’s break down the problem and see if there is more we can do.

We are often debating whether or not a particular solution is better than the current way.

But in our “implement the tools” approach, we tend to make “lack of a specific solution” into a problem.

Whoa. Let’s back up a bit and see if we can head this off.

Do you have agreement on a clear target objective, one that all parties can describe? Do you know how the process should be performing?

Note I said “should” not “could.”

“Could” is potential.

“Should” is an unmet expectation. Big psychological difference there.

If everyone agrees that the status quo isn’t getting it done, and also agrees on what they want to achieve instead, then the next question is “OK, what is stopping us from taking the next step?”

This shouldn’t be an abstract exercise. As you watch the people in the process try to reach a higher performance level, look for “What just got in our way?”

You need to help the leaders, and your other constituents see it with their own eyes. Don’t expect them to take your word for it. You wouldn’t take theirs without your own observation.

If everyone can see, for example, that a team member gets too far behind to recover before anyone else notices, or that a machine is experiencing stoppages or excessive changeovers, for example, then you can start discussing solutions.

Perhaps the team leader needs to make quick status checks periodically, in a way that is not intrusive.

What is stopping him?

Well, that’s difficult right now, because everything is buried in the computer, and often updated in batches after the work is done.

Hmmm.. What could we do to make things more visible, in real time? Is there a way we can set up the work area so the team leader (and the worker, and anyone else just happening by) could readily see there is an issue here?

Now, and not before, is the time to start discussing solutions. But you can’t just make the logical argument. You have to get agreement each step of the way.

That might very well take longer than you want it to. People are funny that way.

But the bottom line is this: “Lack of your pet solution,” no matter how many books and name-brand authors refer to it, “is not a problem.”

We create a lot of our own resistance by running into things, and leaving fires behind us.

Posted on

Measuring Improvement

One of the most common (and frustrating) problems for the staff lean practitioner is being asked to “measure the savings” resulting from specific improvements.

(This problem is related to, but different from, trying to measure “lean progress” or the status of implementation.)

There are two issues in play here.

First is the level of understanding in the leaders who ask for this in the first place. Frankly, it isn’t their fault. Authors, consultants, and practitioners have been “selling” the concept of “lean production” as a stand-alone thing to do for decades.

It is really easy, in the initial excitement of grasping the potential, to just try to push the tools and promise that great savings will result from simply implementing them.

The initial literature was all about describing the performance of benchmark companies (like Toyota, though there were others), describing the visible tools and saying, in effect, “if you just implement these tools, you’ll get this kind of results.

But making these changes can be expensive. The obvious costs are consulting fees, time (perceived to be) taken away from production work. Therefore, there must be a sufficient ROI to “justify” making the changes.

For the practitioner, the countermeasure is to try to shift the focus to establishing a business objective first.

This shifts the conversation from “justifying improvement” to “what problems must we solve to hit the objective?”

The financial evaluation then shifts from "justifying moving beyond the status-quo” to evaluating alternative solutions to the problem.

If you ask directly, most managers will have things in mind that they would like to do better. The challenge is to get those things framed in enough detail that some value is created for actually getting there.