I’ve never been a big fan of lean lingo. It may sound expert-like, but I’ve always found its use to do more harm than good.
One example that I have witnessed firsthand was during a checkup visit to a manual assembly department in which I had helped implement the beginnings of a lean management system. I worked hard in implementing visual management, problem solving and coaching the front line leaders in recognizing waste, problem solving, and the concept of single piece flow.
During the visit to the floor, a supervisor came to me, distraught. She said that they hadn’t been getting the results they had seen in previous weeks. In her estimation, she was doing all the right things: observing work, recognizing wastes, problem solving, etc…but the workers just weren’t very good. She said, with irritation dripping in every word, “I’m always telling them, no, not like that, single piece flow! But they just don’t listen! They were trained on it, they know this stuff!”
The reality was that her team did NOT understand the term “single-piece flow” from their training session. They were not ignoring her, they simply didn’t know what she meant, and the result was that she mistakenly concluded her people were not very good.
Does that sound familiar? Time and time again, we as lean practitioners struggle to develop structured problem solving across an organization. We see people reluctant to problem solve or, when we do see a brave few step forward, struggle and stumble their way through their first attempts. I have trained, coached, led, recognized and rewarded people through many problem-solving efforts but I still see otherwise motivated and talented employees intimidated by it.
I believe problem solving at its core is something that is natural, intuitive and something that most people do to some extent in their everyday lives with no knowledge of lean. We have been problem solving for millennia. Imagine being the person who solved the problem of keeping warm in freezing temperatures (countermeasure: fire) or the person who solved the problem of wasting too much energy moving things (countermeasure: the wheel or the pulley or the lever). Illustrating another point, these are problems that we continue to work on (countermeasure: passive solar heating, countermeasure: robotics) – a testament to our species’ natural inclination towards continuous improvement.
So if humans are natural problem solvers, why do organizations across the globe struggle to implement structured problem solving?
The success of every lean methodology is multifaceted, but for structured problem solving there is one detail in particular that I find is often overlooked and prevents it from flourishing across the organization – A3 report language.
Typical problem solving reports use steps like “problem statement,” “root cause,” “countermeasure,” and “standardize.” Although these words are less foreign than “kaizen” (continuous improvement) or “gemba” (literally: the real place), they can best be described as technical terms, words that are part of the lean language. At some point in time, every individual in a lean organization will be looking to the A3 report as a guide. The terms are not easy to remember, not easy to relate to, and thus not easy to embed in an individual’s thinking.
The possible reasons we use some of these lean terms, myself included, are many. It could be because many of us come from an engineering background where technical terms are common. It could be because lean was developed in a Japanese company. On a much bigger scale, we may use a whole plethora of business lingo to fuel our egos; trying to appear more competent or intelligent with our peers. Or maybe we just do it because that’s what others do or that’s what we were taught. As John Shook writes in Managing to Learn, “The story and format of the A3 should be determined by the specific answers or context of the questions as they relate to the problem or project.” Lean lingo is irrelevant.
When it comes time for a novice problem solver to write down their work, sections titled “develop countermeasures” and “root cause” do not easily convey to them the thought process we are expecting them to follow. A good process is one that a trained person can execute reliably; a great process is one that anyone can execute reliably. Many companies during a lean transformation, my own included, have spent considerable time and resources in training people in problem solving. At the same time, people love to point to training as a problem. It’s not long enough, it’s not often enough, its content is wrong, it’s delivered inconsistently, trainee’s not paying attention….the list goes on. I am not at all opposed to training but we are doing a disservice to those we teach by requiring them to learn and speak the “lingo.” Lean methodologies are not secret techniques, yet it seems as though we use secret words to go along with it.
The fact remains, using the simplest words possible to convey meaning, even at the cost of using more of them, will make your subject accessible to the broadest group possible. If we believe problem solving should be inclusive across the organization, and that problem solving is a natural human process that just needs to be developed into a standard set of steps, then we need to disregard terminology. We need to use words that are easy for everyone to understand if we want everyone to adopt lean thinking.
