Dear Gemba Coach,
In your experience of teaching lean, what do you find most difficult to teach?
Thank you for this intriguing question – I need to think about it. Surprisingly, when companies embark on lean programs, what I find most often missing is an understanding of pull. But that’s not the hardest concept to teach. Once people have understood the centrality of pull to give meaning to day-to-day work, reveal problems, and get people fixing issues day after day, they grasp the idea of only producing what is being asked for by customers easily enough.
Come to think about it, what I find hardest to teach are standards. In most companies I know, standards are confused with company policies or procedures, not personal knowledge about the ideal way of doing this or that.
Understanding vs. Learning
For instance, if we take the teaching class as a gemba, students find it hard to distinguish understanding from learning:
- Understanding is about getting a mental picture of “I get it”; I can see how this can be so – it makes sense, somehow.
- Learning means recognizing the situation in real life and knowing how to address it.
Typically, the brightest students are not necessarily the best learners. People who are good at “getting it” are not necessarily good at “trying it.” For instance, they might say something like: “Oh, I see. If kanban cards dictate what needs to be produced at every moment, the team leader’s role is essential to make sure the team is able to respond to the cards, solve or flag problems if it can’t – and , yes, I see that the hierarchy needs to be a chain of help to support the team leader – this is how the JIT and jidoka pillars come together.”
Yet, at their own workplace, they will strive to implement kanban without ever thinking about teams and team leaders. (This happens often.)
When students are enthusiastic about a book they read, I ask them “What idea from the book are you working on in your own day-to-day practice” … and rarely get any answer.
On the gemba, I can think of many cases where we have a pull system going and where problem-solving is happening on a daily basis. Clearly, these companies perform better than they used to and better than competitors, but when, during a gemba walk, the CEO asks to see standards, we’re frequently greeted by the same embarrassed silence.
People are willing to spend time on problem-solving – particularly if the CEO asks for it and is interested during gemba visits – but very rarely on writing down the conclusions of their problem solving or kaizen efforts. They feel this is a company matter, not an individual one. Taylorist thinking that experts define the process and workers apply it is never far behind – someone should gather all that knowledge and put it in a system. As if.
Responsibility for Standards
The hardest part of lean is finding people who take responsibility for their own (or their own team’s) learning. In the end, any company is a collection of people doing stuff, and competitiveness is all about how better each person does their stuff and how better they work with each other to make something for customers.
Taking responsibility for your own learning means starting a diary in some shape or form, whether a notebook, a word or Excel file, or LinkedIn posts, and start collecting the technical things one learns in the course of resolving problems or improving work processes, in the manner of the many amateur scientists of the XIXth century who would collect bugs or pebbles and then share their findings.
Standards start with the individual drive, commitment, curiosity, etc. to collect knowledge and discard wrong ideas. As these specific points get collected and shared and compared with similar problems in other circumstances, then they can become collective standards – but only then.
A friend, a lean officer, recently asked me the difference between kaizen and problem-solving. I spouted the dogma without much thinking, you know, “Kaizen is improving a standard whereas problem-solving is closing the gap between the real situation and a standard.” I realized that this answer was both exact and completely useless. Why was she asking me about the difference between kaizen and problem-solving? A more useful answer would have been: “Start collecting all the meanings of the word ‘kaizen’ you can find and make up your own mind.”
Lean always works in the earlier phases of orienting teams towards real customer demand, solving obvious problems, and eliminating obvious waste. Just start tracking output and come regularly to see how you can help a team with its problems and you’ll see performance improve visibly and … stall. At some point, teams must start formulating their own standards, and visualizing the gaps with these standards to discuss why:
- The standard wasn’t applied in this context because of …
- The standard is plain wrong in this situation …
- There is no standard for this unexpected case ….
But this requires teams to take spontaneous ownership for their own learning, which, in turn, requires the right kind of incentives and managerial support to help them do so. Standards and the taking care of one’s own standards remain what I find more difficult to teach, and, so far, I haven’t found a great way of getting better at it (I’ve tried several) so any suggestion is welcome!
