I will be the first to tell you that this is probably repetition of a fairly narrow theme you have seen here before. But I think of different ways to frame it, or get different thoughts, so I share them.
“Problems first” is one of the mantras used by Phil Jenkinson, the CEO character in The Lean Manager by Michael and Freddy Ballé. Now that I have had a few weeks to let it sink in and synthesize with my mental models, I am seeing a concept that is so fundamental I would think it would be hammered into students in every management and leadership course taught in the world.
Of course, though, it isn’t.
Instead it seems alien in most company cultures.
Yet without a “problems first” culture, the leaders really have no idea – none at all – what they should be focusing their attention on. How could they? They don’t know what their people are struggling with until it is too late. By that point, a small unresolved problem has grown to the point where it cannot possibly be ignored, and now it must be dealt with. Task teams are formed, initiatives are launched. Action item lists are made and presented every week, and after enormous expense and effort, the illusion of control is returned. And so many companies are run just like this.
I am pretty sure that anyone reading this knows exactly what this feels like. Let me call it a “hidden problems” culture for now. Maybe I will think of a better term later.
Enough about what it isn’t.
Ironically, a lot of companies in the pursuit of “being lean” actually go blindly through the motions of “problems first,” but so in a way that raises questions about their understanding of this concept.
Let’s look at a simple action item review at a staff meeting.
Typically it looks like this:
For each action, the responsible person reports on the status, whether or not it is “on time” (usually against an arbitrarily assigned due date), and any “problems.” The manager asks if any help is needed, and perhaps assigns more actions to someone else to assist.
One common management tool for these things is a “Stoplight Chart” where actions are assigned color codes of Green, Yellow, or Red, usually depending on progress against the deadline (how late they are).
Red items get the most attention in the meeting (as they should, more about that in a minute), but that attention is usually in the framework of review and reporting.
At the end of the meeting, the senior leader has a good feel for what is happening (or what is not happening).
Contrast this with a world-class automobile assembly line.
Just like the actions items, every task has a deadline. Only in this case, the timing is much tighter – measured in seconds, not days. The assembler knows that if he gets more than 3-4 seconds behind, for any reason at all, he cannot possibly catch up and complete the work cycle on time. He is going to be late.
He pulls the andon cord, to let the team leader know there is a problem.
Key Point: This is not a report of a problem. This is transfer of the problem. The assembler is responsible for carrying out the work as it is designed. If he can’t, for any reason, then exceptions are transferred to the team leader.
The team leader can deviate from the standard work sequence to complete the job, but not the timing. If he cannot clear the problem by the end of the takt cycle, that section of the line will stop, and the andon will go red.
This is not a report of a problem, this is transfer of the problem. The team leader is responsible for assuring the work can be completed within the takt time. If he can’t, for any reason, then exceptions are transferred to the supervisor.
The supervisor is now responsible for clearing the problem and getting things moving again. If he can’t, then within a few minutes, another section of the line will be stopped and the responsibility for clearing the problem transfers to the next level in the chain.
And so it continues.
Of course this increasing level of responsibility does not mean that the others walk away. They are clearly working very hard to get the problem cleared. But each level of escalation brings more resources to bear on the issue.
Note that I haven’t talked about root cause and problem solving yet. Although the escalation procedures are designed to help gain better understanding of the underlying cause, the first priority is to get the problem cleared so that production can resume without compromising safety or quality in any way.
There may be a temporary countermeasure put into place to do this – some short term action that, while it might introduce some extra resources into the process, allows safe, quality production to proceed long enough to get to the underlying cause. One test of understanding that cause can be to remove this temporary crutch and see what happens.
OK, back to the staff meeting.
What is different about that?
The main thing is that typically the problems are being reported, but not escalated. The responsible person may have to come with an action plan to clear the issue, but it is still Management by PowerPoint, and the senior leader’s role is approval vs. involvement. If the senior leader does become involved, it is often driven by a perception that the responsible person is incapable rather than a process of professional development.
What would this look like if it were managed exactly the same way as the assembly line?
What if that monthly review were treated the same as the fixed stop position?
A couple of ideas come to mind.
“Green” means “on track, as originally scheduled.”
“Yellow” means “behind, but we have a plan to get back to green.”
“Red” means behind, and we don’t know how we are going to recover.”
How would those meanings change the tenor of these meetings?
“Problems first” is more than just a discussion about problems. It is a culture that is focused on finding them, clearing them, and solving them, and doing so with the same priority that comes with production.
This started a rather deep email exchange with Michael Ballé that goes far deeper into the book and the thoughts behind it than any review I could ever write.
With Michael’s permission, here is that exchange, with minor editing mostly for readability and flow.
My words are in blue.
Michael Ballé is in black.
Text [in brackets] are my additions to help context.
Michael:
Mark,
Here’s the acid test:
Would you agree that Jenkinson play a different role from Jonah [in “The Goal”] ?
(hint: he is the lean manager :))
Michael
Mark:
Michael –
Actually, no, I don’t think Jenkinson plays a dramatically different role than “Jonah.”
Perhaps if the story had been written from Jenkinson’s viewpoint, with insight into his thoughts and worries about Andy, rather than a third-person view of his actions and words, I would agree. Then it would be about Jenkinson AS a lean manager.
But what we have is Andy Ward’s experience of Jenkinson. Thus, I don’t get any particular insight into what Jenkinson is actually thinking about how to get his message across to Andy except in the moments when he shares his thinking in conversation with Andy.
For example, Jenkinson (and Amy and Bob) are driving the concept of the problem solving culture from the very beginning. But Andy isn’t “getting it” until late in the story.
What was Jenkinson’s internal response to Andy’s misguided approach? What mental PDCA did Jenkinson apply when he saw the right results being gained at the expense of the social structure in the plant?
Thus, this comes across as a story about Andy Ward learning through his interactions with Jenkinson (and Amy and Bob Wood), and his experiences in trying to apply what they were telling him, rather than a story about Jenkinson’s approach to leading and teaching.
So the story is (to me) much more about Andy *becoming* the lean manager than Jenkinson “being one.”
The real difference between Andy Ward’s experience and that of Alex Rogo (his counterpart from The Goal) is that Andy’s boss is participating directly in Andy’s success vs. just issuing an ultimatum. Thus, Jenkinson embraces the role of the teacher as well as the boss.
Yes – that is exactly the message – that “leading” in the TPS is teaching. But I think [The Lean Manager] is much more about Andy learning it than Jenkinson teaching it.
The characters of Amy and Bob Woods seem to be there to add credibility since a CEO really doesn’t have this amount of time to spend with a single plant manager in a large global company. But they are so well aligned with Jenkinson’s approach that they are surrogates for him.
Thus, Jenkinson is the “teacher” in a story about Andy’s insights and development as a leader.
THANKS for asking the question.
It really made me think.
Mark
Michael:
Good debate.
One of the writing issues we’ve had was that Freddy and one of his CEO friends felt Jenkinson was underdeveloped whereas Tom [the editor] and I felt he was already far too omnipresent compared to Andy Ward. The basic challenge for the book was to share the experience of what it feels like to be a plant manager stuck between the hammer (CEO) and the anvil (real life in the plant).
Jenkinson was conceived to be this Batman-like scary character. He is a teacher, but not a very good one. Basically, his one redeeming teaching feature is his patience, but, hey, the guy is a CEO. I’ve worked with several, and then I’ve spent most of my time working with the plant managers so its the latter’s pain I wanted to share. Having said that, all your points are correct, and indeed, Freddy would agree with you.
More seriously, and I hope I can convince you …that [Jenkinson’s character is not a “Jonah”] because it’s a fundamental point I’m trying to get across. As you say, the fact that Jenkinson is Andy’s boss makes it TOTALLY different from the Jonah situation. Obviously I didn’t manage to get this across well enough, but having to learn from someone who holds the sword over your head is a vastly different issue than having found a great teacher (I’d agree with Woods/Jonah), no matter how cantankerous.
This learning-from-boss issue has to be my top of the list reason why lean is spreading so slowly. So I’d argue that beyond literary devices (how many lean novel plots can there be?) this is indeed a core point of the book.
Where I’ve obviously not written this well enough is that Jenkinson IS teaching, but in a boss kind of way, which is a very different position. In particular, I’ve been very mindful (maybe even heavy handed) of the fundamental asymmetry between roles, and the whole issue of how to deal with a boss’ comments.
By the way, Jenkinson is also doing what he can with the people he’s got (can’t replace them all, right?) For instance, you’ll notice that he gets very different responses from each of his plant managers. Jenkinson’s modus operandi is to show a lean problem to the plant manager, draw a line in the sand about where he wants him next, and push him/support him to get there; As people are different, each plant takes a very different path to lean its operations and requires a different mix or arm-twisting and lecturing.
The reason we never get any direct “look” into what Jenkinson really thinks (although we do many other characters) is that I wanted to reproduce this “boss” aura – no one ever actually knows what the boss thinks. We’ve discussed this quite a bit at the time of the writing, and your comments are spot on so I’m really interested in your opinion.
[a follow-on note]
Jenkinson was actually built on what I saw my dad do when he was CEO (I was helping him at the time with expliciting the “System” – I’m a sociologist). So Jenkinson does five [six, actually] things:
1) He forces. At several points in the book, he tells people: that’s the way it’s going to be. In the German plant, in the French plant with the impromptu kaizen, with the strike, etc. Basically, he forces his managers to commit and/or do something right away IN FRONT OF THEIR TROOPS. This is a specific technique – and not an easy one.
2) He gets them to go further in their thinking. At several points, Jenkinson works with Andy to push his questioning further (not always explicitly “why?”, but it does happen. Freddy, who used to be feared because of 1), was surprisingly in the HOURS he spent doing just that. It’s equally terrifying when you’re on the receiving end because, at first, subordinates are fishing for the answer they think the CEO wants to hear, and not thinking – which makes for a lot of frustration both ways.
3) He forces people to work together, particularly when they don’t want to. Actually, Amy does this in Andy’s plant at first with the production plan issue, but Phil forces the Neville/Andy link, and later the Engineering teamwork.
4) Phil encourages “problems first” at several occasions, which is trying to tell his guys that they come to him with problems rather than let them fester, and that if he learns of the problem from someone else first, that’s bad.
5) He lectures – although this is against his own expressed principles – as he states in the car at the beginning of the book. Phil is not so enamored with the sound of his own voice as the author, but we’re still all human, right?
One more thing Jenkinson does on several occasion:
6) “Stay on target, stay on target” – Andy keeps being distracted by all sorts of things, internal politics, problems in his plant, etc. Jenkinson realigns him at almost every conversation 🙂
The two insights we have in Phil’s thinking are:
– when do I pull the plug (close the plant, fire the plant manager/regional manager/sales VP, etc.)
– dealing with the politics of senior management
In writing the [business novel] genre You’re stuck between expliciting the thinking (the lecturettes, love the word), and sharing the experience through an action scene. Then there are the limits of the author’s writing talent – I had to really sweat it before trying work within the plant as opposed to out of it (The Gold Mine), because trying to describe a working plant environment is something of a writing challenge.
Michael
Mark:
Michael –
A couple of questions –
Who is the “ideal reader” – the target audience – for “The Lean Manager?”
What are the explicit teaching points the story is intended to present to the reader? What does this ideal reader take away?
What should the target reader do differently after reading the story?
What aspect of the story gives him that insight?
Did you have those things in mind as you wrote it? Or did the emerge with the story development?
I see Andy as the central character of the story. It is he who undergoes the personal transformation, and the storyline revolves around his interaction with the other characters. As you intended, is a sympathetic character that many people the in the same position will identify with.
Thus the learning from the book is transmitted through Andy, based on his experiences.
I see Jenkinson as a (primary) supporting character, who in combination with the others, shapes Andy’s experience, and through that, shapes the reader’s experience. But in the end, he is mainly a teaching character.
Yes, he is also the boss and needs the results. He leads by example. He teaches “forcing teamwork” by doing it. He makes his intentions crystal clear, does not do hollow posturing, and can play the political resistance against itself. But to Andy, he is sensei.
A good student will be motivated by wanting to please the teacher. In this case, it is also an economic / career imperative, but in the end, it is about a motivated student.
The key points of what to teach certainly come out in the process, including the fact that Andy learns a few things the hard way in spite of being told (like the teamwork thing).
But overall, it seems to be about “How to be taught” by a true lean manager more than it is “how to teach like one.”
If the key point is to teach a senior executive HOW to be a “lean manager” then I guess I’d have written it from the teacher’s perspective rather than the student’s.
If I were a CEO or senior executive, I’d like to know what Jenkinson was thinking when Andy was getting bogged down in distractions. If the target audience for the story is a senior executive or CEO, then I would think the CEO character has to be the sympathetic character, with the frustrations and problems that these guys can relate to. Then they can see he isn’t “Batman” in a comic-book city, but he is dealing with the same problems they are.
John Shook made an attempt at that in “Managing to Learn” but the scenario was too limited to really create any dramatic “ah-ha” moments.
I think Dr. Bahri’s self-experience (Follow the Learner) was a unique perspective of learning-by-doing, but, again, the scenario is too limited for most people to see beyond a medical or dental practice.
So – after re-reading my own note above, and going back to your earlier note regarding your debate about Jenkinson’s character development vs. his “omnipresent” relationship with Andy
– I guess I’d say that:
With Andy as the point-of-view character, then Jenkinson’s development is appropriate.
But if Jenkinson is actually the title character, then I can see where Freddy and his CEO friend felt that he should be more developed. The difference is that, to get that development, the perspective of the story has to shift from Andy to Jenkinson as well. Then the “omnipresence” drops away as an issue because it is about Jenkinson teaching rather than Andy being taught.
One possible follow-on story could be this shift to the teacher’s perspective. Perhaps there is a new acquisition and Jenkinson assigns Andy to mentor the manager there through a turn-around as Andy’s next development assignment. Now Andy is the teacher, (with Amy’s help, or through the A3 process with Jenkinson), and we see the teacher’s perspective as he is trying to keep the student focused on the right things in spite of the noise and chaos that, perhaps, Jenkinson is throwing at it with his demands for performance.
Andy must simultaneously understand “the main problem” in the plant, and get his student to understand it without just telling him the answers. Maybe he sees the guy as a hopeless concrete head, and Jenkinson has to force him to be patient and stick with it.
What does a competent operations manager need to learn to be able to teach someone else? How does he learn it? What is the development process for that?
Then we would have a story of not only how to BE a lean manager, but how to teach one to teach another.
Thoughts?
Mark
Michael:
The books are about 1) teaching and 2) sharing an experience. It all flows from here – I never had a target audience in mind.
The Gold Mine was all about describing TPS from the point of view of a smart guy, who’s got the power to affect changes, but has got to learn all this stuff – that was Jenkinson then. The experience I tried to share then was “The Curse Of Knowledge”.
To Jenkinson most of TPS is new and counterintuitive and every time he’s picked something up, there’s more to it (and I still experience this fifteen years later), because you don’t know what you don’t know.
And for Bob Woods, the impossibility of expressing what you’ve figured out over years to someone, hence the annoyance and grumpiness (not “Jonah” 😉 ). Add Amy, who thinks she’s getting it because the tools make sense to her, but she doesn’t understand the wider business picture nor why older people have trouble thinking that way and you’ve got The Gold Mine. Now, the trick is in
1) sharing an experience and
2) conveying the concepts, so sometimes I get it right sometimes not.
Pat Lancaster of Lantech fame, made the same type of comment [about The Gold Mine] you did: “Why didn’t you write it from the plant manager’s perspective?” To convey the absolute panic of the moment you’re about to pull the plug on the MRP. The comment stuck, and eventually that became The Lean Manager.
The gimmick in [The Lean Manager] is that BOTH Jenkinson and Andy are “the lean manager” – Jenkinson is the closest I can make it to a lean boss outside Toyota (those I’ve known anyway) and Andy is learning that stuff – with the added twist of the asymmetry of relationship that defines authority relationships.
The Gold Mine was about TPS, and this one is about Toyota Way.
My overriding problem as a consultant on the shop floor when I talk to senior execs is: “Are we on the RIGHT problems?” The problem with consultants (me included) is that they seldom understand enough of the business to focus on the right things (not a problem to Toyota consultants with suppliers, because, well, auto is auto).
So I like the idea of Amy consulting with some company and getting them to fix the shop floor and yet having no results on the business because the real problem is in engineering – where she’s got everything to learn (enter Woods & Jenkinson). If I do that, definitely “teaching the stuff” becomes an issue (since this is my specific expertise, I’ve resisted going there so far not to pollute the message too much with my socio-techno stuff)
Will have to let this one simmer for a while.
In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.
I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest (more for the next book).
The only way I know how to fight on the field of ideas is by writing books and then getting them into people’s hands. So now that it’s out, I’d like to get it in the hands as as many people as I can to try and change the zeitgeist… Not my favourite activity!
Best,
Michael
I really wanted to share this exchange with you because it highlights a couple of the main problems that are encountered in any attempt to implement real change.
To quote again from Michael’s note:
“In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.
I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest.”
And, in the end, there it is.
Ironically, if you are even reading this, you already know it.
The Lean Manager is a success story, driven by the people who are actually responsible to deliver the results. While Michael and I may quibble about whether or not Phil Jenkinson is a “Jonah” character in the sense of The Goal is a discussion about literary structure rather than the core message here. What all of these books have in common is that it is the leaders who drive successful change.
The “slow progress of lean” comes in situations where the implementation is delegated to staff with the charter to “do it to someone else.” And, in my experience (having spent a painful amount of time as that staff), that situation is far more common out there.
I have more to go on this, but I am going to leave it for another day.
Before I get into it, I will break the rules of blogging and acknowledge a time gap here. I did finish the book shortly after I wrote part 2, in fact, I didn’t want to put it down. So now I am going back through and bringing out some key points, intermixed with some other stuff that has caught my interest lately. Anyway – back to what you came for…
Steve Spear has described the TPS as a “socio-technical system.” Put in less formidable terms, it is a system that uses the structure of the work, the work environment and the support systems (the technical part) to create an organizational culture of problem solving.
Jenkinson, Andy’s boss in the book, describes it:
“You need to organize a clear flow of problem solving, explained Jenkinson one more time. “Operators need to have a complete understanding of normal conditions, so that whenever there is a gap, they know it’s a problem. Go and see is not just for the top management, It’s for everybody. This means operators as well, in particular how they learn to see parts and see the equipment they use. How can all operators recognize they have a problem? [emphasis added]
The simple statement, and following question posed by Jenkinson sums up a great deal that is left out of lean implementations. I see it everywhere, and will be commenting on it more shortly.
We talk about “go and see” (or “genchi genbutsu“) as something leaders do. I think this is because traditional leaders aren’t naturally out in the work areas, on the shop floor, in the hangars, etc. We don’t think about the workers because they are there all of the time.
Yes, they are. But what do they see? Do they see disruptions and issues as things they are expected to somehow work around and deal with? Or do they see these things as something to call out, and fully participate in solving?
And if they do see a problem, what is the process for engaging it?
Just saying “you are empowered to fix the problem” does not make it so. When are they supposed to do it? Do they have the skills they need? How do you know? Is there a time-based process to escalate to another level if they get stuck? (Or do they just have to give up?)
And indeed, as the story in the book develops, Andy turns out to be taking a brute-force approach. He is directing staff to implement the tools and to solve problems. But in spite of nearly continuous admonitions from his boss and other experts, he is not checking how they are doing it. He has put a “get-r-done” operations manager into place, and while the guy is getting “results,” in the long haul it doesn’t work very well. Yes, they end making some improvements, but at the expense of alienating the work force.
It is only late in the story (and I won’t get into the details to avoid playing the spoiler to a pretty good plot twist) that Andy finally learns the importance of having a process that is deliberately designed to engage people.
Commentary – it is amazing to me just how much we (in the “lean community”) talk about engaging people, but never really work through the deliberate processes to do it. There are explicit processes for everything involving production, administration, etc. but somehow we expect “engaging people” to happen spontaneously just because we believe it is a good thing.
The message in this book is loud and clear. This is about leadership. The tools are important, yes, but only (in my opinion) because they are proven techniques that allow people to become engaged with the process.
But the tools alone do not require people to get engaged.
Permission to make input is necessary, but not sufficient. If you want people to be engaged, you have to deliberately engage them. Otherwise you are just asking them to become nameless cogs in “the system.”
In my review of Kaizen Express back in May, I took LEI to task for two things – First, I didn’t feel Kaizen Express contributed anything really new to the body of knowledge. I would have been satisfied if it had more clearly explained what had been said before, but it didn’t do that either. Second, and more importantly, I felt that Kaizen Express, and the LEI in general, were propagating the conception that the tools were what defined “lean” and that “the tools” were “the basics.” I disagreed on both points, and still do.
I am now about halfway through The Lean Manager, and I believe this book is addressing those issues – and hopefully challenging some of the thinking within the publishers. In other words, in its content, this book is everything that Kaizen Express isn’t. Get it. Read it. Do what it says, and you will actually be implementing the basics.
What makes this different? Instead of revolving around technical descriptions of the tools, this book clearly shows the proper relationship between the tools and the two most important aspects of what makes the Toyota Production System work:
Leaders (and how they lead and what they lead – and it isn’t implementing the tools)
People (yes, other books pay lip service by mentioning shop floor engagement, but The Lean Manager is all about shop floor engagement)
The authors start to hammer home the point in Chapter 2, Everybody, Every Day. In one of the many lecturettes they use to convey the key points via their characters, Amy, a corporate consultant, sums it up:
“Everybody, everyday solving problems, that’s the only answer to the Pareto dilemma. You’ve got to visualize two flows in the plant. One: the product flow[. . .]. Two: the problem flow to the person who finally solves the problem. [. . .] you shouldn’t funnel all problems to your key technical people. You should protect them to work on the really difficult issues. What you have to organize is the problem solving in the line!”
And with that, the rest of the story follows – this fictitious plant manager under fire in this fictitious company sets out to do that.
The subsequent chapters (so far – remember, I haven’t finished the book yet) are Go and See, which hammers home the importance of the leaders – all of the leaders being present, not just to witness problems, but to ensure they are being solved by the right people, in the right way. Further, they must break down any barriers which impede that flow. And it’s not just the leaders. Ultimately, the entire shop floor is organized so that everyone is immersed in genchi genbutsu every time a task is carried out or work is performed. This becomes the check in PDCA.
Chapter 3 is titled Managing is Improving and begins the confront the psychological and organizational aspects of the changes that are now coming to a head in the story. This part requires the most creativity on the part of the authors, as it is an entirely human process. Because it is a human process, not a technical one, it is impossible to write a technical manual on how to do it. It requires knowledgeable, dedicated leadership that is humble enough to stake out a position that might be wrong, knowing that doing so improves the chance of learning something.
And that has been the issue in our industry. It is far, far easier to describe the tools in excruciating detail than it is to confront the leadership and organizational change issues. And because the technical descriptions predominate the literature (including, and especially what has come out of LEI for the last 10+ years), it is far easier to believe that “implementing the tools” is something that leaders can delegate to specialized technical staff.
This book, so far, is (rightly) turning that thinking on its ear.
I just started reading this book, and my initial feeling is that it is a winner. Rather than producing a batch review of the whole thing at the end, I thought I would employ “one chapter flow” and share my impressions with you as they are formed. As I write this, I honestly do not know where it is ultimately going.
I am excited about this book because it is challenging the decades-old paradigm of kaizen events run by specialists (while simultaneously trying to justify the change activity to the people who hired them in the first place). In its place is a leader who knows what he is doing, and appears to be starting to lead by asking tough questions.
Even with that initial endorsement, this book appears to be following the standard formula established by Eli Goldratt in The Goal.
Manager finds out factory is being closed. News is devastating to his personal life.
The Jonah character emerges and teaches him how to save the operation.
He applies what he learns and saves the day.
While there is nothing wrong with this structure, it is wearing a bit thin, at least to me. So I hope that the authors are going to find an interesting twist that surprises me. Still, because this is a novel with a point, vs. an attempt at classic literature, I’m not going to spend much time on the literary style.
The two main characters (so far) are Andrew Ward, the manager who finds out his plant is being closed, and Phil Jenkinson, the new CEO, with the double role of bringing the bad news (closing the plant) as well as filling the role of the Jonah (or sensei in this case, I suppose).
In the opening chapter, Jenkinson’s style is authoritative, bordering on confrontational. Without knowing the culture of this fictitious company, I can’t say whether his blunt, direct approach is from necessity or because he simply doesn’t have the skills to ask tough questions without pushing people back. I’ll hold judgment on that part. My hope is that the book doesn’t teach this approach as how it has to be done, because in my experience, it doesn’t have to work that way.
The message, though, is crystal clear. The old way isn’t cutting it. Leaders, not staff, are responsible for results (safety, quality, delivery, cost). Leaders are expected to know the hot spots in their operations. Leaders are expected to be involved in the details – not to micro manage, but to develop the capabilities of others. (That last one is a bit of an extrapolation on my part.) “Lean” is not a program, not projects run by a staff of specialists, it is how we will manage the company.
The notable quote from this chapter comes in a shop floor lecture given by Jenkensin and nicely sums up the relationship between process and results.
“Results… are the outcome of a process. What we want are good results from a controlled process because they will be repeatable. Bad results from an uncontrolled process simply mean that we’re not doing our job. Good results from an uncontrolled process…only mean we’re lucky. Today, bad results from a controlled process just says that we’re stupid: We expect different results from doing the same thing over again.”
Based on that, I sketched out this little matrix that captured my response and the key points.
But the technical nuances aside, this story is clearly developing into one about leadership. The key issues, so far, are:
Safety, quality, delivery, cost, are line leaders’ responsiblity, with assistance from technical staff – who are also experts.
Though it is certainly a culture shock, the leader is teaching by asking questions.
The various character’s reaction to the confrontive authoritative style is predictable. I am uneasy, at this point, with that approach being held up as an example of the best way to get this done. But it is only Chapter 1.
“We’re trying to shift from collecting data for judgment to data for improvement.”
I agree with Mark’s assessment: “Brilliant.”
Metrics are a “Check” in Plan-Do-Check-Act.
The purpose is not to determine if people are “doing their jobs” but to assess if the plan is working as predicted.
“As predicted” means that not only is there an objective, but there are discrete actions which everyone agrees will cause the objective to be reached.
Note the words “everyone agrees.”
For that to happen, not only are objectives handed down, but the plan to reach them is discussed. The boss is keenly interested in exactly how his people plan to accomplish their objectives, and he has bought in after he is satisfied they have done thorough work. Think about that for a second. The boss now has his own “skin in the game” on not only the objective, but the way to get there.
There isn’t any space, at this point, for judging people based solely on hitting the numbers, because the boss has already agreed that the plan should work. The question now comes down to how well the team did putting together a plan and gaining consensus, and how well they executed. If the numbers aren’t hit, everybody has to reflect on why the plan didn’t work, what they didn’t foresee, and what they need to do better next time.
Management-by-measurement, on the other hand, is an abdication of leadership. It becomes an adversiaral rather than collaborative exercise and becomes a contest of politics and blame-shifting. This is why, I think, Deming finds the merit system and individual performance bonuses so destructive.
During my visit to The Netherlands, I had the pleasure to spend a couple of hours with Dennis Goethals, Managing Director and CEO of DesignOnStock, a furniture manufacturer in Tilburg, The Netherlands. What I saw and heard were all of the critical elements I have seen in organizations that pull this off in a spectacular fashion.
It starts, as always, with leadership. DesignOnStock, like every other success story I have experienced, has a leader who dedicated to his personal learning and understanding – at a level way beyond the common, but hollow, statements of “committed.” He is down on his shop floor, exploring the flow, looking for the next problem, and working the organization through a solution.
The results? He can deliver a custom order in 1/10 the time of his competitors. In these hard times, his business is increasing because he can offer quick turn-arounds to his customers who don’t want to keep a lot of inventory in anticipation of sales. They can sell one, order one, and have the replacement in a few days.
Rather than trying to recall the details myself, I asked Dennis to share his story as an interview.
How did you first get into the furniture manufacturing business, and what was your experience there?
Dennis: I studied Economics at Erasmus University in Rotterdam. My father had a small upholstery company. When he got sick, we agreed I would come and we would work together. My experience was that the furniture making industry is very traditional. No real partnership between companies. Very small companies in the whole industry. (the biggest in Holland is 350 people, on average 10-20 people per company). As I am an entrepreneur I thought this is the perfect industry to work in. High prices, some volume and not so much really strong competition. We worked like crazy and in 4 years time we grew from 5 to 25 people and from 300.000 usd to 6.000.000 usd. Sales was not our problem, we had great difficulty organizing our production. So much difficulty that at some stage I decided to sell the company and move the factory to Turkey.
Ed. Note: To fill in a gap in the timeline here, Dennis formed a partnership and opened another factory in Tilburg which was being set up traditionally when he then encountered “lean manufacturing.”
When did you first encounter “lean manufacturing?”
What was your initial reaction?
Dennis:Steven Blom introduced Lean manufacturing to me on 6th of December 2006 at 11.30 in the morning. I thought it was the most brilliant thing I had ever seen in my life! I realized I knew nothing about production, only what I had seen at other companies. And I was amazed not everybody is doing this.
What kind of problems did you have to overcome as you tried to implement flow?
How did you go about solving those problems?
Dennis: We had 2 big problems implementing flow:
First, when you implement flow it becomes very clear what everybody in the production line is doing. We had to replace some operators who didn’t like the idea of the ‘flow’ of their work to be visible. We ended up replacing almost 1/3 of the workforce because they didn’t want to leave the idea of batch production. This was very hard to do, letting people go is always difficult. But for us this was the only way.
And second, when you implement flow you have to make sure that the supply of parts is well organized, otherwise your line is down most of the time. We started to use kanban to order our parts to solve this. In ordering materials for your production line, kanban is the most brilliant thing I have ever seen.
What has this done for your business and your competitiveness up to this point?
How have you been effected by the global economic conditions?
Dennis: It has been an amazing experience. We reduced our lead time from 30 days to 3 days. We reduced inventory 60%. Our product quality has increased, our profit has tripled. We are the only company in the Netherlands who can ship a custom build sofa within the week! Due to the economic crisis a lot of our customers have cash flow issues. We are the only player in the market who can generate cash within 2 weeks. A lot of customers focus on selling designonstock.com products to improve their cash position. We increased turnover by 10% and due to further cost reductions we increased revenue by 60%.
Where do you think you are now on the “lean journey?”
What are your next steps?
Dennis: We have just begun our lean journey. The first thing we did was to implement one piece flow. This was the big breakthrough. Now we are fine tuning the tools you need to do one piece flow. I think we can double the output without increasing our workforce. We will do a lot of work ‘upstream.’ In his visit Mark explained this to me and this has brought a lot of new energy to us. We will try to further reduce inventory, simplify our system and we will have a very big focus on visualization and standardization in the months to come.
Do you have any advice for people who are wondering if this will work for them?
Dennis: I would use the Nike slogan: Just do it! When you first start to hear about lean, WCM (World Class Manufacturing), one piece flow, kanban etc. it all sounds a bit strange. Start with something really small. Like buy your groceries with a kanban system. That is how I learned it. This is a way of thinking, not a system you implement and then go back to business as usual. When you really get this, it will change all!
To conclude I would like to quote Lao Tze: Show me and I will look. Tell me and I will listen. Let me experience and I will learn.
—-
I would like to offer thanks, again, to Dennis for taking his valuable time both to show me around his plant, and to respond with his own words for the story of his experience. What I appreciate most, I think, is that he is not resting on his accomplishments. Rather, he sees what he has done so far only as a foundation.
One of the things I often hear when we start talking about mistake-proofing and standardizing operations is that we are taking away people’s “creativity.”
“Creativity” in this case is usually the challenge of figuring out how to make a broken process function, or figuring out how to make the product work when, as designed, it doesn’t. “Creativity” means knowing what Julie actually keeps a stash of the parts that are always short, and knowing how to interpret vague, contradictory or obsolete drawings and work instructions. Nobody can look me in the eye and honestly say that a workplace like that is fully respectful of people.
Honestly, the very last thing I want to do is take creativity out of the workplace. But on the other hand, how much creativity is totally wasted on things that should be simple and straightforward?
As long as people’s mental energy must be expended to simply get the process to do something useful, there is none left for them to figure out why is doesn’t work and fix it.
The illusion, I think, is that once things are standardized that there will be nothing left to do.
Nothing could be further from the truth. There is plenty of work to do.
First, “standardizing” is simply setting down what we believe is our best shot at what should work. Once reality sets in, there are nearly always things nobody thought of – opportunities to learn. Capturing those moments is impossible if there is no consistent baseline in the first place.
And, just for the sake of argument, let’s say that the process, as designed, works pretty well. The question must then be asked: “Are we able to provide our customers exactly what they need, exactly when they needed it, on demand, one-by-one, perfect quality, in a perfectly safe environment?” If the answer to that question even includes a hesitation, then it there is work to be done.
Respect your people. Simplify the things that should be simple. Let them focus their creativity on something that matters, not on how to get through the way without screwing up.
In his book Built to Last, Jim Collins explores the characteristics of companies with sustained performance, and introduced the term “BHAG” for “Big, Hairy, Audacious Goal.” (or something close to that 😉 ).
Last week I had the honor and pleasure to spend a day at the Verbeeten Institute, a radiation oncology clinic in Tilburg, The Netherlands. It was clear they have been working very hard on improvement, built on coaching from Blom Consultancy, who were my hosts there.
Every Tuesday, the medical staff gathers for lunch and host a presentation on a topic of interest. Last week, that was me.
Though I had a fair idea where I wanted to go, I didn’t have a structured, prepared speech. I wanted to get started, and then see where the audience led things.
I started off with a somewhat tailored version of my “Project Apollo story” to emphasize the difference between Kennedy’s BHAG challenge and the higher level objective of “world leader in space exploration.”
Then I asked a question – what would be a BHAG for Verbeeten that they could use to drive themselves toward their goal of “World Class Care.” One of the audience members, from the very back, said “First treatment in one day.”
This was pretty radical. The current process of initial consultation, CT scan, preparing a detailed treatment plan, and getting the patient in for his first treatment can take 20+ days today, though the actual patient involvement in the process is only a few hours, actually less if you start sharpening your value-added pencil.
As we started to get general agreement that this might be a good thing, one of the doctors asked a really interesting question.
Why?
In most cases, there isn’t any compelling clinical reason to try to accelerate this process, and in some cases there are pretty good reasons not to. So Why? was a pretty damned good question to ask – why go to all of the trouble. Why does it matter?
Setting aside, for a minute, the logical arguments of an improved patient experience, let’s explore that a bit.
What it comes down to is, not so much the goal itself, but what you have to do to accomplish it.
It makes the organization push itself through thinking, innovation, and into territory that, as things are right now, is unachievable.
In other words, you have to get really good. You have to become intently focused on everything that is distracting from the core purpose of the organization. You have to excel at execution.
The only way to get there is to learn to define what results you want (a “defect free outcome”), what steps are required to achieve it, carry them out, respond immediately when something unprogrammed or unexpected happens, and seek to understand – at a detail level – what wasn’t understood before.
Napoleon Hill is quoted as saying “A goal is a dream with a deadline.” So long as the goal aligns with a sense of higher purpose, and people can emotionally get behind it, they are a great help in simplifying the message and keeping everyone focused. Deming famously walked about “consistency of purpose.” This is one way to show it.
We touched on a similar issue here a few months ago. But it is always worth coming back around to people because because in this system (actually in any system) there are always two issues with people.
People are the most fallable part of the process.
The process cannot operate without them.
The reflex is often to go into total denial about #1 and expect people to be vigilant and perfect every time. “Weed out the bad apples, and everything will be fine.” Of course that doesn’t work.
In John Shook’s example, he traced through Ohno’s classic “5 Why” example.
1. Why did the machine stop?
There was an overload and the fuse blew. 2. Why was there an overload?
The bearing was not sufficiently lubricated. 3. Why was it not lubricated sufficiently?
The lubrication pump was not working sufficiently. 4. Why was it not pumping sufficiently?
The shaft of the pump was warn and rattling. 5. Why was the shaft worn out?
There was no strainer attached, and metal scrap got in.
Then Shook asks a really interesting question:
Why was no strainer attached?
Why not indeed? Isn’t that somebody’s job?
And now, as he points out, we have transitioned from “technical” to “people.”
Maybe the standard work for the maintenance worker or machine operator didn’t go far enough. Or maybe the standard work did specify changing the strainer but the worker failed to observe the standard. How was the standard developed, how was it communicated and trained? How easy was it to “forget” to change the strainer?
Coming, as I do, from mostly “brownfield” environments, the existance of standard work in the first place isn’t something that we can take for granted.
Nevertheless, Shook is making a critical point here. It does not matter whether there was no standard work, or whether the standard work broke down for some reason that we do not yet know (another “Why?”). This is still a process problem. We must start with a working assumption that the team member cares, and is doing the very best job possible, given the expectations, the resources, and his understanding at the time.
I am aware of a couple of cases where engineering change implementation pulled up short of actually observing the new installation and looking for unforeseen problems. One of them was quite subtle, and actually took a few weeks to find the basic cause, much less the root cause.
Another resulted in a bolt snapping during final torque. Messy to fix, but better in the factory than in the field.
These are additional cases where technical problems resulted from process breakdown, and in both cases, it was a case of unverified or blindly held assumptions, and not following through with the customer process.
Shook concludes with two really important points, and I can’t agree more. First:
…the work design must also include the “human factors” considerations that make it possible to do the job the right way, and even difficult to do it the wrong way.
I like to say “Make the right way the easy way” if you want things done in a certain manner.
Which brings us to Shook’s final point: You have to look at the total package – the human and the technical as an integrated system. You can’t separate them because. You can’t “take people out of the process.” All you can do is construct the process to give people’s minds the most opportunity to focus on improving the work rather than burdening them with making sure they get it right.
Always work to support people to do the right thing in the right way. If the organization carries a belief that it is necessary to force or “incentivize” people to do the right thing, then there is a people problem, but it isn’t with the workers.
.
,