How can we reconcile the lean principle of respect for people with our disrespectful atmosphere?
Dear Gemba Coach,
I appreciate your frequent discussions about the value of respect in order to be lean. Unfortunately my company has embarked on a lean program that is anything but respectful. Competent people are stigmatized as “concrete heads” whenever they disagree with anything the lean coaches come up with, even when their prescriptions make absolutely no business sense. What used to be a good atmosphere for work is now poisoned by resentment and distrust. How can that be compatible with the “respect” message of lean?
Ouch. I wish I could say you’re in a unique situation, but unfortunately, I have heard of many firms where this does happen, and have even seen a few during Gemba visits. So you’re probably observing something very real, and I’m sorry that you have to go through it.
Let me start by clarifying “respect” as I understand it, and then see if we can diagnose what is happening in your case, with possibilities for countermeasure, no matter how remote. In lean, respect means “respect for the development of the person to his or her fullest ability” (at least over here in Europe). This doesn’t necessarily involve being polite (although this is independently good, I guess). Respect is mostly about the boss’ good intentions towards you, even if somehow this intention is shown awkwardly. One inside Toyota joke is “my boss has shown me too much respect today.”
Regardless of whether Toyota still remains an exemplar for the lean movement, I find the company endlessly impressive for something it emphasizes to this day: when its executives discuss production issues, they always talk about operators. “What is the mission of the operator?” “What is the standardized work?” (which is not to say the procedure, but the “how” of operator movements to succeed at the job), “What are the difficulties of the operator regarding his or her job?”
This may sound obvious to you, but believe me, I’m on the shop floor constantly with CEOs, figuring out how to lean their company. And while its relatively easy to involve frontline management, getting them to see operator’s difficulties remains a real challenge. Recently I was in a construction site where the CEO was looking at the “problems, cause, countermeasure, status” list that every project manager has to update on a daily basis. I was reminded that the need to see causes from the worker’s eyes is always a struggle to explain.
For instance, in this renovation project, operators had demolished more of a wall than they should have (which creates rework in having to rebuild unnecessarily). The project manager had written “incorrect reading of the plans” as a cause. On the Gemba, walls to be demolished were marked with a large blue “D” without any visual indication of where to start or where to stop. A long discussion ensued about the fact that once the worker starts hitting a wall, they keep hitting: knowing when to stop isn’t intuitive and has to be clarified. Out of this conversation, the CEO and the project manager came up with the idea that they could ask the worker to spray demolition areas, thus confirming in advance what to hit and what to spare. In this case we see that the tool (spraying) is at the heart of an activity (learning to identify where to demolish and where not to), which is essentially development of the worker.
Trawling for Files
This experience drove home the point that that taking the value-adding perspective is possible, but never easy. You have to work at it. LEI CEO John Shook opened my eyes to this approach when we were discussing Toyota’s sense of “respect.” He emphasized that respect was all about removing the difficulties that keep the operator from doing the job properly. Take note that this does NOT mean adding more control, more checks, more training. This is not to say that controls, checks and training are not a necessary part of achieving quality, of course. But they are still waste—waste that should be seen, and which needs to be understood at a root cause level, so that eventually the need for this wasteful activity can be eliminated.
Failing that, weird things happen. Recently I was in an aerospace factory watching a lady assemble high-tech parts. I stood there for about 40 minutes during which she assembled seven products. The actual work took a matter of minutes. She spent the rest of the time trawling for files on her computer to find the right paperwork, walking across the room several times to get printed sheets out of the printer across the hall, filling in the traceability forms, disappearing for several stretches of unexplained time, and so on. Meanwhile, her bosses were busy doing “lean” by building line-side feeders – which held several days of incoming parts. From the lean perspective, this is disrespectful in two ways. First, the operator is there to add value not do paperwork. Second, the outrageous layer of cost added to the product is endangering her job – if I’m going to be that inefficient, better do it in Asia.
This takes us to a wider implication of respect: beyond solving immediate difficulties for operators, the role of the leader is about creating a sense of peace-of-mind so that operators can focus on the work at hand and not worry about what will happen to them next. The fundamental lean deal of “mutual trust” goes something like: you contribute through your ideas to productivity improvement, and in exchange we do everything we can to create a safe and serene working environment. Part of “respect-for-humanity” is accepting that people are people, quirks and all, and that pressure on their personality is muri: overburden. I remember coming across the presentation of an ex-Toyota engineer who defined performance as the sum of personalities x competences x motivation. Personality is a plus, not a minus in the lean ideal.
Learning to Learn
What is it then about the “concrete heads”? Are some personalities incompatible with lean, or at the least, the core value of respect animating this approach? Lean is based, to cite John Shook again, on learning to learn. Performance increases when competent people coordinate better to come up with leaner processes and, in the process, improve their abilities. Leanness of processes is nourished by constantly improving individual know-how, skill and judgment. Consequently, experienced people who refuse to learn are a problem, and will feel pressured. That’s is true. Usually, they leave on their own accord. Ideally people should not feel pressure to achieve specific things but to learn.
In practice, how can you distinguish one from the other? The boundary is quite clear – the lean program requires of you one of two things, either:
- Apply “best practice”
- Participate in learning events.
Simply applying best practice is not lean. It’s straightforward Taylorism. That was one of Taylor’s big ideas: get an engineer to observe workers, figure out the “one best way,” and then get everyone else to apply it. This approach can achieve gains to be sure, yet they are limited. This practice completely ignores the fact that other workers might be operating in different specific local conditions. Taylorism is just dandy when we’re talking about moving a coal heap, but as soon as the job is more technically demanding – let alone knowledge work – the “best practice” idea is destructive of local knowledge and judgment, and many competent people will fight compliance with good cause (which is what seems to be happening in the case of your firm). Best practice thinking is NOT lean thinking.
In contrast, lean thinking is about participating in lean events, using the lean investigation tools, to figure out how to improve performance locally. Good practices from other areas are investigated, certainly, but as a source of inspiration rather than a recipe to be blindly followed. In lean jargon this is called “yokoten” which Jeff Liker once explained to me as “copy + kaizen.” The point of lean learning events is to engage people in solving their own problems and, by seeking root causes, deepening their own understanding of their job and how to better satisfy customers. The lean deal is that no one will ever force you to apply any practice you’re not comfortable with (after all, you’ve got good reasons), but you will be expected to participate in the learning events and draw conclusions on how you do your job, yes.
I have met many middle managers who were dismissive or clearly resistant about participating, running, or even drawing shop-floor conclusions from learning events. They said they were too busy with the here-and-now crisis, or felt that their authority was challenged by workers expressing their opinions or difficulties, or that some managers simply refused the learning effort.
When you encounter resistance, the first thing is to ask is whether you are facing good people resisting applying “best practices,” or are they resisting participating in the learning events? It gets tricky of course when people feel the learning events are not producing smart results, and that is absolutely a fair game for discussion. More than that, this question calls for conducting the Plan (figure out the problem) Do (the learning event) Check (try it for real, see if it works) Adjust (if it’s silly) or Adopt (if it works) cycle of lean.
Ultimately, the difference from crypto-Taylorist lean programs and respect-for-people lean programs comes down to the CEO’s intentions. If the CEO has bought into the fact that they need to personally:
- Go to the Gemba
- To figure out how company policies create difficulties for people that stops them to add all the value they could
- Ask people to tackle problems one by one to get them to learn
- In order to study their initiatives and draw policy-level implications to lean the entire company, so that the CEO can learn from all staff’s initiatives
Then the chances are the learning cycles will occur in some form or shape. On the other hand if the CEO has delegated the task of writing all the best practices (or worse, carving them in stone through IT workflow systems) to a specialist group and then making people apply the new rules through the lean program “deployment,” then, yes, this will both destroy mutual trust and not get business results (actually, often worsen business performance).
Deal with It
Unfortunately, influencing the CEO is seldom an option. They are the way they are and we have to deal with it. What you can do is get fully involved in the learning events part of the program and use your experience to leverage the competence around you and come up with clever answers to the question asked. If you’re in a “apply the best practice” theory, you can also try to steer the debate to value – what are the real hard cash results expected from the action. Lean tools tend to steer the debate towards more rational answer. Counter-intuitively, the antidote to silly lean is more lean: learning to use the lean tools properly to come up with sensible countermeasures. For instance, the purchasing manager of a division successfully changed the “apply best practice” approach of centralizing all supply chains based on poorly thought out VSM precisely by drawing out lead-time analysis and asking for value.
My yardstick for a successful event is whether the analysis has led to deeper technical thinking, and whether the participants better understand their own technical issues. This often hinges on obtaining the trust of the most technical competent people, who are not necessarily the most open characters – after all, they know what they know, so why should they accept to be challenged or even listen. On the other hand, kaizen workshops dealing with non-product related issues (internal organization, office, etc.) are often a distraction – where the non-technical minded can rule because knowledge doesn’t matter that much. Solving our real problems together is also a good way to generate mutual trust.
There is no easy answer to your predicament, other than learning to own the lean tools by using them yourself, and in so doing to come up with sensible countermeasures. And in the process, beat some sense into the program!
How can there be standards -- or kaizen -- in a service job when no two instances are the same?
Dear Gemba Coach,
I’m in a service job and I struggle with the idea of standards. I read that there can be no kaizen without standards but how can you have standards when no two instances are the same?
I don’t get kanban -- I don’t work in production so how would it apply to one-off work?
Dear Gemba Coach,
I feel that I still don’t get kanban. I don’t work in production, and I fail to see how stock replenishment would apply to one-off work.
Can lean be used to turn around a company?
Dear Gemba Coach,
Can lean be used in a turnaround situation? Does a burning platform make it easier or harder?