Learning from Managing to Learn
It has been about four months since the release of Managing to Learn, now already in its second printing. I’ve received incredible response from many quarters, some great reviews both on-line and in print, and some thought-provoking questions. Below are two exchanges you might find interesting.
Following are two questions from Dr. Jaap van Ede of www.procesverbeteren.nl, an “independent knowledge platform” in the Netherlands. The exchange was published in conjunction with his scheduled full review of MTL in the Dutch journal In Logistiek.
Dr. van Ede: I think it would have been better if the thoughts of coach Ken Sanderson would have been added to the story of trainee Desi Porter (then the reader does not have to switch between two stories and is still able to see what both persons are thinking).
JS: Certainly, simply stringing the story along sequentially would have been more conventional and is an approach I considered. And throughout the writing process, we were very concerned that the unorthodox two-column format might cause difficulties for some readers. However, testing some “rapid prototypes” of the two-column format showed that readers had less difficulty than we feared. Additionally, since publication, I certainly expected some readers to complain, but to my pleasant surprise the response to the format has been overwhelmingly positive. At any rate, I was aware that the format is highly unconventional and, of course, anything unconventional is also risky.
I became convinced that the risk was worth the potential reward after showing early drafts to test readers where I found that the format beautifully captured the tension of real-life dialogues that occur every day in business. Life, business problems, and people do not always come at us sequentially. There are always competing priorities, different organizations making different demands, two people trying to talk to you at the same time, fighting for your attention. Faced with those situations daily, we have to decide. Similarly, the MTL two-column format (which, by the way, we think is a unique innovation) asks the reader to make decisions, and provides flexibility to be read in different ways.
Dr. van Ede: Desi Porter seems to be the ideal A3-student. What can a sensei do if he is less lucky? It would have been nice if the book had also addressed this issue.
JS: This is an interesting observation, and this is the first time to receive this question. I am frequently asked the exact opposite: where can I find a Sanderson?!
In fact, I think that this is indeed the bigger problem, the lack of good “sensei” or mentors. As for the observation that Desi is an ideal student, yes, this may be true. But, my own experience is that young professionals such as Desi Porter will indeed respond if we – as the more experienced senior manager/mentor – reach out and try to provide opportunities for them to learn and grow. Yes, there is that small minority of individuals who will not respond. But, if we assume first that it is our role to mentor, I think we will have little difficulty in finding less experienced “Desis’” who will readily join us in embarking on a lean learning journey.
Senior Advisor, Lean Enterprise Institute
Next are two more comment/questions from an engineer who asked to be identified only as a lean and six-sigma practitioner at a large aerospace manufacturer:
Engineer: Thank you for writing the book Managing to Learn. I read it between Christmas and New Year's Day, and it was fantastic! Before the Christmas break, I had been planning to try to improve our procurement system at work, using value stream mapping as the primary tool. But as I read, I kept thinking that the A3 will be a better tool for managing the improvement. A value-stream map will probably be useful, but it will only be a part of the effort. The book also helped me to realize some deficiencies in our value-stream mapping process (primarily that follow through and on-going improvement are weak).
To the best of my knowledge, no one has used the A3 in the past where I work, but there are a couple others that will probably be willing to act as my mentor, or we may be able to use a consultant.
I would like to offer two struggles I had with the book, in hopes that if others have the same struggles, they might be improved with the next version. The first is with the set-based approach. It seems as though it would typically take some considerable time to test all the counter-measures that Porter proposed on page 79 of the book. I see that there was about a month and a half between the A3 on pages 84-85 and the one on pages 98-99. I expect that during this time, Porter was conducting trials, collecting and evaluating data, and then down-selecting the countermeasures to implement across the company. But I'm not sure I have that exactly right. The A3 on pages 84-85 already has evaluations of each of the countermeasures. Were the trials already done, or is the evaluation based on the expected results? The question is more or less rhetorical for the example of the book. The real question is what I should do for my future A3s. I expect that when I first propose countermeasures, I will also include a test and evaluation plan. Then when I move forward the analysis section will tell what did and didn't work, and the plan will show the countermeasures that are selected to move forward. If I'm missing something here, I hope you can let me know. Otherwise, there is no need to get back to me on that topic.
The second struggle I had was with relating the PDCA cycle to the A3 process. It seemed to me that the A3 used more of an IIIPTPIF (investigate, investigate, investigate, plan, test, plan, implement, follow-through) cycle. I did get parts of the connection between the A3 and PDCA, but mostly it seemed like a stretch to make PDCA fit within the A3. Maybe I'm just not seeing the forest for the trees here, but to see the PDCA cycle seemed more of a distraction to me than a driving force.”
JS: Thank you for your excellent observations and questions! Thank you for reading Managing to Learn so closely. Below are responses to the two issues you raise.
Regarding the first issue of how Desi worked through his set-based countermeasures, you observations are correct. There is an assumption that Porter was indeed “conducting trials, collecting and evaluating data, and then down-selecting the countermeasures” and you are correct that I do not show that process in the book as clearly as I might. This was partly a simply decision based on the fear that going too far down that path might fatigue and even lose the reader. I think your suggestion to show more of this process would indeed make MTL a stronger problem-solving book. I do not plan at this time, however, to add more detail there in later versions. But, on the other hand, a sequel is always a possibility!
Your second observation is fascinating, that Porter’s “scientific process” was more “IIIPTPIF (investigate, investigate, investigate, plan, test, plan, implement, follow-through) cycle” than PDCA and that “mostly it seemed like a stretch to make PDCA fit within the A3 …”
Let’s see, first let me say that I think you are correct that IIPTPIF probably captures more closely than a precise interpretation of “PDCA” the steps taken by Porter. However, my view is not that it is a stretch to make PDCA fit within the A3, rather than they fit together naturally.
My view of PDCA is that it is not its precision that gives it its power. I remember just a few months after leaving Toyota being asked by a client in my first regular consulting job, “So, where are we now in the P-D-C-A cycle? Are we in the P or the D or the C or the A?” I was dumbstruck. I looked at him, realized he was quite serious, and paused for just a moment to collect my thoughts. Similarly, I am often asked to compare PDCA with DMAIC, 8D, and other “problem-solving” methodologies. Let me try to explain how I look at it.
I recall an insightful discussion of the matter from a different angle many years ago with my boss at the Toyota Technical Center USA, Mike Masaki. Mr. Masaki was an engineer’s engineer and head of body engineering for Toyota, a very central engineering function within the company’s product development process.
In the late 1980s, he learned about the famous Taguchi Methods (Toyota didn’t use them or even know about them), ordered a full set of Taguchi Methods materials and assigned a young engineer to do a thorough study of the materials and the method. The results of the study were that while the Toyota engineers agreed that the Taguchi Methods contained many good tools (many of which Toyota did in fact use, under other names), everyone agreed that what they liked about Deming’s PDCA was the spirit of PDCA. They saw PDCA as a simple, elegant expression of the scientific method. Simple, and also flexible. You could say that there is a certain lack of “rigor” within P-D-C-A per se, or a flexibility. Inside “P” is the “Investigate” activity you mention. Within Toyota’s PDCA, that Investigate activity will continue as long as necessary, three IIIs as you express it, or 10.
There is, in fact, a mini PDCA cycle occurring inside each of the bigger PDCA activities. So, actually, you are working within all aspects of the PDCA cycle, all the time. (More specifically, I should add, whereas you preceded “Plan” with three rounds of “Investigate”, Toyota often explains that before you can “Plan” you have to “grasp the situation” and often describes the process as “CA-PDCA” – the hair-splitting can get pretty deep!)
Similarly with the A3. While I introduce a template with a set number of boxes in MTL, at Toyota an A3 would sometimes have four or five boxes, other times as many as eight or more. It was a flexible tool, embodying the PDCA method, but using it whatever way would best tell the story of the situation or solve the problem at hand.
More than answers, consider those some thoughts inspired by your excellent question. Thanks and best of luck at your company!
Senior Advisor, Lean Enterprise Institute
Time To Make Time
When the people in a lean system don't value time, everyone is cheated, says John Shook, in this fascinating reflection on the role that time plays in a close observation of work.
The Remarkable Chief Engineer
How can a system in which "we are all connected and no one is in charge" support purposeful and productive work? Toyota's famed Chief Engineer system has much to offer in this regard. John Shook explores how the leadership styles of, and ways of working by, the CE might provide something of a roadmap for all of us.
How Standardized Work Integrates People With Process
In this three part series on SW, John Shook argues that "the Toyota Way is a socio-technical system on steroids. A test for all our lean systems is the question of how well we integrate people with process (the social with the technical). Nowhere does that come together more than in the form of standardized work and kaizen."