Category: People Development

Posted on

Managing To Learn (the book) – my first impressions

Managing to Learn bookManaging to Learn by John Shook is the latest in the classic series of books published by the Lean Enterprise Institute.

It is subtitled “Using the A3 management process to solve problems, gain agreement, mentor, and lead” and that pretty well sums it up.

Like many of the previous LEI books, it is built around a straightforward working example as a vehicle to demonstrate the basic principles. As such, it shares all of the strengths and shortcomings of its predecessors.

In my admittedly limited experience, I have seen a couple of companies try to embrace similar processes without real success. The main issue has been that the process quickly became “filling out a form.” Soon the form itself became (if you will pardon the term) a pro-forma exercise. Leadership did not directly engage in the process; and no one challenged a shortcut, jumping to a pet solution, or verified actual results (much less predicted them). Frankly, in these cases, it was either taught badly from the beginning, or (probably worse) the fad spread more quickly than the organization could learn how to do it well.

I must admit that with the recent flood of books and articles about the “A3” as the management and problem solving tool of lean, that we will see a macro- case of the same though throughout industry.

Managing to Learn tries to address this by devoting most of its emphasis on how the leader teaches by guiding and mentoring a team member through the problem solving process. The reader learns the process by following along with this experience, vs. just being told what to put in each block of the paper.

To illustrate this in action, the narrative is written in two tracks. One column describes the story from the problem solver’s viewpoint as he is guided through the process. He jumps to a conclusion, is pulled away from it, and gently but firmly directed through the process of truly understanding the situation; the underlying causes; developing possible countermeasures and implementing them.

Running parallel to that is another column which describes the thoughts of his teacher / manager.

Personally, found this difficult to follow and would prefer a linear narrative. I am perfectly fine with text that intersperses the thoughts and viewpoints of the characters with the shared actions. But given this alternative choice of format, I would have found it a lot easier to track if there had been clear synchronization points between the two story lines. I found myself flipping back and forth between pages, where sentences break from one page to the next in one column, but not the other, and it was difficult to tell at what point I was losing pace with the other column.

To be clear, Shook says in the introduction that the reader can read both at once (as I attempted to do), read one, then the other, or any other way that works. I tried, without personal success, to turn it into a linear narrative by reading a bit of one, then the other.

The presentation format not withstanding, Shook drives home a few crucially important points about this process.

  • It is not about filling out the form. It is a thought process. Trying to impose a structured form inevitably drives people’s focus toward filling out the form “correctly” rather than solving the problem with good thinking.
  • He emphasizes the leadership aspect of true problem solving. The leader / teacher may even have a good idea what the problem and solution are, but does not simply direct actions. Instead, the leader guides his team member through the process of discovering the situation for himself. This gets the problem solved, but also develops the people in the organization.

There are also a few real gems buried in the text – a few words, or a phrase in a paragraph on a page – that deserve to have attention called out to them. I am going to address those in separate posts over the next few days.

In the end this book can provide a glimpse of a future state for leadership in a true learning and problem solving culture. But if I were asked if the message is driven home in a way that passes the “sticky test” then I have to say, no. I wish it did, we need this kind of thinking throughout industry and the public and government sectors.

Thus, while this book is very worthwhile reading for the engaged practitioner to add to his insight and skill set, it is not a book I would give someone who was not otherwise enlightened and expect that he would have a major shift in his approach as a result of reading it.

The bottom line: If you are reading this in my site, you will probably find this book worthwhile, but don’t expect that having everyone read it will cause a change in the way your organization thinks and learns.

Posted on

Dealing With High Turnover

Jim left a great post on The Whiteboard way too long ago.

His problems seem to sum up to these statements:

Every valve is hand made one by one in batches through several processes.

…about a 10% turnover rate…Consequently we are always training new people…the supervisor needs to make sure the worker understands the job

My inclination is to somehow explain to the owners how their employee turnover rate is hurting their production and quality.

He titled his post  Hitting The Moving Train which seems appropriate on a number of levels.

Keeping in mind that I have not done my own "go and see" so I don’t have facts from the ground, only what is reported, a couple of immediate things come to mind. Other readers (especially the couple of dozen of you who never leave comments!), feel free to chime in here.

Short term: Stop the batching. Or, more specifically, flow the batches. The key point here is that just because you run batches doesn’t mean you can’t run one-piece-flow. (Pardon the double negative.)

What does that look like here? For each batch of valves, understand all of the assembly operations, set up an ad-hoc flow line that sequences all of the steps, then run them all through.

This does a couple of things, first and foremost, it gets them off the shop floor and shipped a hell of a lot quicker because now they are DONE. The downside is the supervisor needs to teach more than one person his particular sequence steps, but it eliminates all of the routing, traveler paperwork, tracking, prioritizing, and other stuff associated with having those 50 incomplete valves sitting out there. Scheduling becomes "Which jobs are we going to set up and assemble today?"

What about the parts? Don’t start assembling until you have all of the parts.

"Wait a minute, what about just-in-time?" One thing at a time. Let’s not launch a job until we have the capacity and capability of actually doing it for now.

Next, (Intermediate Term): is make the supervisor’s job a bit easier. I am assuming that, since he is training the workers, that he understands the tasks. But does he have formal training on how to break down work into steps and instruct in a way that someone remembers how to do it? Rather than reading a book about it, I would strongly suggest contacting the TWI Institute and getting, first, a handle on Job Instruction. This is, essentially, standard work on how to break down a job and teach someone to do it. The method has been taught unchanged since mid-1944. Not surprisingly, it is bread-and-butter at Toyota… and their material is pretty much verbatim from the 1944 material.. and it is the origin of standard work as we know it.

As jobs are broken down, the inherently critical tasks should emerge. These are the things which must be done a certain way or the thing just won’t go together (bad) or will go together, but won’t work (very, very bad). Those key points are where to start instituting mistake-proofing, successive checks, etc. This will start driving toward stomping out the quality issues.

For each quality issue that comes back to bite, take the time to really understand how it was even possible to make that mistake, and focus a problem solving effort on that key point to (1) incorporate it into the teaching and (2) mistake-proof and successive-check that particular attribute. Defects discovered in the plant are bad enough. Defects discovered by your customers are another story. Do what you must to keep the defects from escaping, then work on preventing them. Don’t cut out inspection just because it is muda.. unless you are 110% certain that your process is totally robust, and any problem that does occur will be caught and corrected immediately. Anyone who thinks Toyota "doesn’t do inspection" has never seen the last 60 or so positions on their assembly line… nor have they seen the checks that are continuously being made during assembly.

And finally – the turnover issue. A couple of things come to mind. First, with the right attitude and approach, the things described above can make this a lot more interesting place to work… especially if the Team Members are involved in finding the solutions to escaping quality issues, etc.

The same goes if supervisors continue to hone their leadership skills. Employee turnover is typically caused as much by the relationship with the first line supervisor and working conditions in general as it is by wages, etc. Southwest Airlines would not exist were that not true. Neither would a couple of other companies I can think of. Go look at "The 100 Best Places to Work" and see that relatively few of them cite "the highest pay and best benefits in the area." This isn’t to say that they do not offer fair, competitive compensation. But compensation, in general, is a relatively poor indicator of job satisfaction. Far more important is a daily demonstration that someone cares and is committed to the Team Member’s success.

If they really like TWI Job Instruction, they might be attracted to Job Relations – standard work for supervisors (first line leaders) for people issues. The TWI Institute has also just launched a new program called Job Safety. This isn’t one of the original TWI classes, but it was put together by experts I know and trust, and from what I have read, it follows the same reliable method format.

With all of that, perhaps the owners will be convinced that a competitive compensation program is a way to say "Thank you" to a great team that busts their butts to keep the customers happy.

Posted on

Who’s Your Coach?

In a few weeks, the best athletes in the world will assemble in Beijing for the 2008 Summer Olympics. Just being there means these individuals are performing at a level that the rest of us can only watch and appreciate.

Each of these world-class top performers has a coach.

Ironically, their coaches are not capable of performing at the same level as the athletes themselves. If they could, they would be competing, not coaching.

To be sure, some of the coaches are former world-class athletes. But most of them are “just” world class coaches. They have the skill to watch the athlete perform, to compare what they observe against a standard of perfection and to see very subtle things which might make a difference in the athlete’s performance.

World class athletes all know they only perform at a world class level because they have world class coaches. It is the coach who takes them from “very good” to “Olympic contender.”

A coaches credibility is based on his ability to observe and teach. His success is built on the success of the people he coaches.

For business leaders:
Do you believe you can perform at a world-class level on your own?
Is your insight into your own performance good enough to pick up nuance and detail that could make a huge difference?
Do you believe that, because you have more experience, that no one below your level could teach you anything?
Do you believe that, because you have been successful, only someone who has had more personal success could teach you anything?
Do you measure “competence” by hierarchy level?

Who is your coach?

Posted on

Anchoring a Problem Solving Culture

More than a few organizations I know are starting to understand the importance of establishing a culture of problem solving. Hopefully they are shifting from a tools implementation model to one which emphasizes how people respond to the daily friction generators.

In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.

The organization must reset its definition of “a problem.”

I started to get at this mindset back in January with the post “Chatter as Signal.”

In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.

Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.

When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”

The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”

Maybe the term “problem” is unfortunate.

A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”

In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.

The organization must have a process for immediately detecting and responding to problems.

It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.

But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.

Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.

Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?

But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?

The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.

The organization must have a process for managing problem solving.

When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.

Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages

However it is done, however, the organizations that do it well:

  • Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
  • Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
  • They manage their talent. The organization I talked about in the “Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
    • Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
    • Don’t jerk them from one thing to the next without allowing them completion.
  • They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.

They deliberately and systematically develop their problem solving skills at all levels.

It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.

Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.

This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.

This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.

As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.