FEATURE – The role of experts in lean thinking is often the subject of heated discussions. Here, Michael Ballé tells us about the common mistakes lean experts make, and explains why – before helping others – they should help themselves.

Words: Michael Ballé, author, executive coach and co-founder of Institut Lean France

Let's go to the gemba. We're visiting a site that is part of a corporate group of about 20 large industrial plants. This site outperforms others on any measure, so we're curious to see what we'll find out.

As we walk around, the site manager takes the time to greet every person he meets with a "hello" and a few words. People respond openly, often engaging in good-natured banter. In each cell, the site manager starts by showing us the team's latest efforts. He also points out everything that is far from perfect, but, hey, Rome wasn't built in a day and the team is trying hard. He then introduces us to the team leader and they go straight to the kaizen board (this site uses Art Smalley and Isao Kato's Toyota Kaizen Methods as their base manual).

They don't discuss the method much, but dive straight into the improvement. What is the technical issue they've discovered they hadn't seen before? What countermeasures are they testing out? Are they working on this in engineering? This is an engineering discussion, not a process one. Plant director and team leader are trying to better figure out the part being assembled and how it is assembled.

In fact, as a lean expert, you have a sudden insight into what they're doing: they are shifting their focus from post-hoc inspection (discovering the defect at quality control) to self-inspection (how to measure the quality of work as we do it), to back-and-forth discussion about source inspection (how to avoid this problem from happening in the first place). Textbook lean. Or so you think, as you make your first lean expert thinking mistake: rather than dive into the technical issue and try to see the process point (where the tool hits the part) and how this affects product performance, you've now misled yourself into looking at the scaffolding, the lean process itself, as the man who ignores the moon but stares at the finger pointing at the moon.

In the next area, the production manager is excited to present the andon he's put together with simple switches and a TV flat screen. So, you and I – the lean experts –have a lot of opinions, experiences and advice to share. The plant manager and area production manager are interested. They listen, they discuss, they challenge. They decide on some changes to the andon – they need to try this out in a bit of a different way.

We return from the gemba to the plant manager's office and happily list all the lean tools we've seen implemented on the shop floor. It's an impressive list. We wonder:

• How can we spread this to other sites?
• What sequence of implementation has the plant manager followed?
• How closely is he following the corporate road map?

He looks dubious and tries to answer our questions, talking about some of his larger scale issues (many have to do with his troubles with group inter-company logistics) but eventually just shrugs. You and I are not stupid, we can hear that we're talking more and more and he, the guy with the actual responsibilities and results, is talking less and less.

We're making the second bad lean expert mistake: rather than focusing on this site (and considering sites one by one) we're excited about how what we see here can improve the program as a whole. We're also excited to see whether we could appropriate this guy's results to bolster our program in other sites that are not progressing as fast. But in our tunnel vision we lose track of, first, what the andon is actually changing in this site's manager's experience – what is he discovering about his own processes thanks to the andon? – and second, the fact that maybe the way he came to setting up the andon has nothing to do with our corporate programs and road maps – what if he learned it by chance, in any other unlikely way? Rather than listen to his learning path, we're trying to make his path fit our plan both to get validation for what we do and to use his success as political ammunition.

But what a great gemba walk! Andon? These guys are setting up an andon? Can you believe that? Why are none of the other sites doing the same? We don't expect any answers, of course. These questions are rhetorical. But we're wrong. There is an answer.

Throughout the visit, we've completely missed the point, you and I: the camaraderie we've witnessed during the visit, and the attention to detail is the real story – not the lean scaffolding they've used to support it.

There is no road map. There is one plant manager who's understood that teamwork and kaizen spirit will get his guys to move together, owning their work and delivering superior performance because they feel responsible for their customers. He would have probably done just the same without the tools, but the tools help people to have shared conversations, like the IP protocol of the Internet. Every kaizen board in this site has the same format not because of the discipline the manager has imposed but because they've created a simple format everyone can read from one end of the site to the other. The visual boards are not the end result of the conversation, but the beginning – a statement from the team on how they handle technical problems so that management can perform the fundamental three tasks of a gemba walk:

1. Getting everyone (management, team, functional experts) to agree on the problems that appear;

2. Spot who takes responsibility for solving which problem;

3. Find out how to help them when they hit obstacles beyond their control.

Certainly, if you listen hard enough, you can see that the site manager is building higher-level hypotheses about what he needs to fix in his plant to make it deliver more results. But he's not that clear about it. He's mulling it over. He's muddling his way through these issues on the gemba, by trying different things with different teams. He's turning pot after pot, rather than designing the perfect one. This is exactly what lean is about: running small, bounded experiments that get us closer and closer to an understanding of the best way of doing something.

As lean experts, you and I fall prey too often to motivated reasoning (a fancy way to explain wishful thinking): reducing the gap between what we'd like to happen for our own wins in terms of lean program adoption and what the site manager is really doing in the gemba by looking at all he does in the light of the program. This leads us in the completely wrong assumption – and third bad lean expert mistake – that he implements lean tools and then they work. This is simply not how he went about it. Let's look at how andon came into being here:

The site manager didn't impose the andon. His guys gave it to him. He discussed it with his production managers until one of them said, hey, why not? Would it look like this? They gave it to him because of the camaraderie and the kaizen spirit – not the other way around. And the andon, in all likelihood, will surface a whole new range of issues no one had expected (such as look at how work is done when there is no evident problem as opposed to only intervene when the fire has started to burn – to learn to look for the "buds of problems").

Lean expert, eat your own dog food. Do a bit of self-analysis: are you interested in technical learning about how to make better products for customers through a deeper understanding of detailed technical problems, or are you looking for reassurance that the tools work when applied with discipline?

Our job is to help the operational managers build the process measurement tools to see what their deep technical problems are, and how to solve them. We're there to help them build the telescope (pull system) and the microscope (stop-at-defect), but also to stand shoulder to shoulder with them as they use these tools. Would the telescope have had such a future if Galileo and his followers had not been interested in finding heliocentric systems?

The scaffolding is useful, and the building can't go up without it, but it remains nothing more than scaffolding. The point of all lean tools is to discover how to better improve performance for customers by finding out where our processes are wasteful because of our own technical shortcomings – and then learning to fix them. As lean guys, we have to be as interested in the technical learning as in the tool we can use to gain it, if not we badly miss the point and hinder operational managers rather than help them. The program is to support individual learning, not to force compliance with ritualistic activities to make corporate look good. Our aim is to develop managers, one by one.

Let's face it, the natural, common-sense list you and I prepared of all the lean tools the plant manager uses is pure poison, because we'll never resist the temptation to go to other plant managers in the organization and say: "Why don't you do ____"?

Rather than worry about a list of tools to implement, how do we ask ourselves the harder questions: how can we help a plant manager to grasp the twin spirit of kaizen and teamwork? Before we have the arrogance to think we can help others, how do we heal ourselves first?

_{THE AUTHOR}

Michael Ballé is co-founder of the Institut Lean France. An associate researcher at Telecom ParisTech, he holds a doctorate from the Sorbonne in Social Sciences and Knowledge Sciences. Michael is a best-selling author and an engaging speaker, and managing partner of ESG Consultants. He also works as a lean executive coach in various fields, from manufacturing to engineering, services to healthcare.