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.

A Dubious Milestone for The Lean Thinker

It is summed up in this statement on my wordpress dashboard:
Akismet has caught 10,020 spam for you since you first installed it.

This contrasts with the 167 comments (including mine) that have been left by actual, thinking people.
If I were running metrics, I would look at the ratio of 167/10,020 and see 0.0166, or a pretty much exact 60:1 ratio of bots over people. Since I can’t do anything about the bots, it is up to everyone else to help out and leave more comments! 😉

I am working on some stuff from the new book from Lean Enterprise Institute, “Managing to Learn” so stay tuned.

A Firefighting Culture

In honor of October being Fire Prevention Month (at least here in the USA), I’d like to talk about firefighting.

“We have a firefighting culture.”

“We spend all of our time fighting fires.”

We have all heard (and sometimes made) these statements. But I would like to take a couple of minutes and look at what real firefighters do.

They don’t just run in and spray water everywhere in an effort to “do something.”

They study fire. They seek to understand how fires start, how they burn, how they spread. They understand the interactions between fire, air, the specific environment (building structure, outdoor terrain, etc).

They develop a plan to attack the fire. They make themselves reasonably sure that if they do (a), (b), and (c) that the fire will respond in a predictable way.

They execute the plan.

They watch the results. If the fire behaves the way they predicted it would, they continue with the plan. If something unexpected happens, they pause their thinking long enough to understand what additional factor may be at play; what they might not have known or considered. They seek to understand the situation whenever something is going differently than what they predicted.

They adapt the plan to account for the new information or the changed circumstances.

They continue to do this until the situation is under control, and the fire is out.

While doing these things, they work methodically. They verify success at each step of the plan – they do not move ahead of their confirmed progress (which would put fire behind them and block their escape route).

While theirs is a dangerous business, they do not, as a matter of course, put human life in jeopardy simply to save property. Heroics are reserved for saving the lives of others.

Once the fire is out, the fire investigators arrive. They seek to understand how this fire started. Where did fuel, oxygen and a source of ignition come together and how? What fire suppression mechanisms failed, and why? How, why, did it spread? Did containment fail? This information is incorporated into the knowledge base of the society in general in the form of regulations, building codes, electrical codes – countermeasures.

In short – firefighters relentlessly follow PDCA.

Now, I must admit that, occasionally, in the excitement of the moment, firefighters get ahead of themselves, or rush into something they don’t fully understand. We usually know when this has happened because there are somber processions and bagpipe music. But even then, they seek to understand what happened, why, and improve their process to prevent recurrence.

Now, the next time you say “All we do is fight fires” consider the above. My guess is that you aren’t fighting anything. Rather, you are running around, making a lot of noise, but tomorrow the building is still burning – just in a different place.

Don’t forget to check your smoke alarms and change the batteries!

Be sure to read the follow-on post here: /2011/01/17/firefighting-kata/

Researching “Lean”

It is fall, and with fall comes the annual spate of postings on various discussion boards by advanced degree students working on papers and dissertations about “lean.”

In these postings, most of them are using some kind of survey instrument, and many of them are multiple choice. The latest one I have asks questions around which tools have been implemented, what kind of results they have achieved, etc, etc. It is fairly typical.

What I find a little disconcerting is that it is evident from the survey content that many of these people have no idea at all what they are researching. They haven’t done a literature search. They aren’t up to speed on breakthrough material – even the stuff that is 10 years old. The research topics themselves are often “old stuff” that is well understood and well established out there.

More disconcerting, I suppose, is that it also seems that there is a large body of people who think that having a survey filled out by a population of unknown self-selecting people who happen to read an online forum with the world “lean” in it somehow equates to surveying experienced experts.

I don’t want to get too down on academia. We practitioners need them. Academics take their very capable and sharp tools, ask tough questions, and publish all kinds of great reference material that helps the rest of us understand things we wouldn’t otherwise.

BUT the meaningful research all has one thing in common – it is based on actual boots-on-the-ground field work. The data is gathered by physical observation, not just asking people what they think.

This is true to the spirit of genchi genbutsu – “Go and see for yourself” which, in the Toyota culture at least, is the only way to have credibility that you know what you are talking about.

Why Doesn’t Daily Kaizen Happen?

More than one organization gets stuck in kaizen events. By "stuck" I mean that kaizen events are the only mechanism for improvement. A good indicator of this is "waiting for a kaizen event" to make an improvement that everyone agrees should be made.

At the same time, I see leaders who understand that these kinds of improvements should be made on a daily basis, but those leaders are frustrated because that doesn’t happen.

So why does this happen?

There are a few things that have to be in place, but even with a workforce that understands improvement and where this is going, even with shop floor leaders who understand how to do it, that doesn’t seem to be enough.

So here are some things to think about.

You block out time during the day for your start-up meeting, end-of-shift cleanup (a different topic). You block out time for preventative maintenance (you do, right?). You block out time and resources for the things you expect to get done.

Do the low-level work groups capture, in real time, the little issues that disrupt smooth work? Those are your daily kaizen opportunities.

Do you block out time for daily kaizen? If you don’t, then you are saying "Do kaizen when there is nothing else to do. Your daily kaizen time should not count as "available minutes" when calculating your takt time.

Do the Team Leaders and Supervisors expect the work teams to work on those problems during the kaizen time?

The bottom line: Don’t just wish it would happen. Look at what is necessary for success (skill, time, leadership, tools, expectations), make sure those things are available. If actual events are not what you planned, then study and understand why not and fix it. Daily kaizen is no different than production. You have to plan for it.

Listening to the Customer vs. the HiPPO

Microsoft has an internal initiative to start running controlled experiments to determine what is actually better for users. I have no data (as I have no inside scoop from Microsoft, even though they are right down the road), but there is general opinion out there is that one of their latest efforts turned out to be less than impressive to the user community.

The mascot of this initiative is a hippo.

PERHAPS, and again, this is only speculation, when they were putting in all of the snazzy page flipping and rotating cube features, they were paying too much attention to the HiPPO and not enough to the actual customer.

What is the HiPPO?
The Highest Paid Person’s Opinon.

Who do you listen to?
Your customers? Do you actually go into the field and watch them use your product?
Do you use it the way they do, in their environment, to understand their experience?

Of does your head of engineering or sales claim to speak on their behalf when you are deciding on product features?

Bloodletting: Why Controlled Experiments are Important

Bloodletting: Why Controlled Experiments are Important

I want to start this post with the last paragraph of this article:

Next time someone tells you that they are sure their idea will work, consider running a prototype in a controlled experiment, and make a data driven decision!

Now – the article itself is in the context of Microsoft software development, but this is what "lean thinking" is all about.

In the Toyota Production System, processes and the organization are deliberately constructed so that a kaizen experiment in one area is unlikely to affect another – at least not before there is ample warning and opportunity to reverse the change.

Every production cycle itself is conducted as a controlled experiment testing the hypothesis that the process:

  • Can be conducted as specified.
  • Delivers the specified results.

Of course – and here is the key point – it is only an experiment if someone actually examines what really happens. And this is the fundamental difference that is captured in the quote at the top.

A truly lean process has built in checks that check, each and every time, whether the idea works. Any time an idea doesn’t work, there is an expectation that the process will be stopped and understood.

Continuing to blindly produce, without knowing if each and every process is working as planned, without knowing if the result is as planed each and every time is being sure it will work. It is bloodletting.

Don’t bleed your process, or your company, to death with things you "know will work."

Span of Support vs Span of Control

One of the popular buzzwords floating around out there right now is "servant leadership." Like all buzzwords, it is easy to say, and easy to subjugate.

One of the best terms I have heard that helps set the thinking is "span of support." Normally leader-to-lead rations are discussed in terms of "span of control." By saying "span of support" instead, the entire concept is turned on its head.

That makes it much more clear that the job of the leader is to ensure his or her people have what they need to succeed, to help them clear problems, and develop them professionally.

Watch out for drug names that look, sound alike

Watch out for drug names that look, sound alike – Yahoo! News

One of the most common errors made in the health care industry is medication – giving the wrong stuff to the patient. There are a lot of root causes, and this article highlights one of them.

I certainly understand that the commercial pharmaceutical industry wants to establish and maintain brand awareness. And I am equally certain that they don’t really consider it "their problem" if "someone doesn’t pay attention" and prescribes the wrong medication; dispenses the wrong medication; administers the wrong medication or takes the wrong medication.

This is one of the problems with a complex system – where a problem originates in one part, but is only felt in another part.

Ultimately the solution is fairly simple. Assign an alpha-numeric code, not to the brand, but to the formulation, including the strength / dosage. Use that code for all bar coding, RF tags, database records, prescriptions, etc.

If it would help, combine that code with colored labels, backgrounds, shapes, etc. Anything to help visual distinguish one product from another.

This is, of course, not a 100% bullet-proof solution. But humans are really poor at distinguishing similar looking words from one another. We don’t see letters, we hear the sounds. This is an appropriate case where technology, which is well suited for this kind of thing, can be a big help.

Will it eliminate all errors? Of course not. Mislabeling or mixing mistakes are also common. But this would attack the problem cited in the article at its root. Then the companies can name their products anything they want, and we also eliminate all kinds of overburden on the already overworked attorneys.

Toyota Profit Slips 28% as Truck Sales Fall

Toyota Profit Slips 28% as Truck Sales Fall – NYTimes.com

This story in yesterday’s online New York Times has a couple of interesting points.

Toyota said its net income fell to 353.7 billion yen ($3.2 billion), in the quarter, compared with 491.5 billion yen in the period a year earlier.

So they, like everyone else, are being hurt by the plunge in big truck sales.

But note that their profits are down. This is different from their losses are up.

their overall results were hardly comparable to the $15.5 billion loss reported by General Motors and the $8.7 billion loss by the Ford Motor Company

Just as a "check" of the financial results, let’s look at market share:

The automaker improved its market share in the United States to 17.4 percent in the quarter, even as its sales volumes declined.

So, yes, their sales are down, but they are down less than everyone else’s.

Now, to be clear, Toyota has issues. Who doesn’t? But, year on year, their management system is delivering the thing that is most important to them: Consistency.