Shouldn't lean focus on solutions, rather than problems?
Dear Gemba Coach,
Why is lean so focused on problem solving? Isn’t seeing everything as a problem negative? Shouldn’t we focus on solutions instead? Wouldn’t that be more positive and more creative?
Good question. Indeed, lean thinking is so problem oriented it doesn’t even allow for solutions – and has invented the ungainly word of “countermeasures” instead! Okay, so that is weird – what’s going on?
Let’s take a step back: what are we trying to do here? Solutions would make sense if we assume that processes are real, stable things and that problems in the process hinder performance. If we find a permanent solution, the process improves, performance increases et voilà!
But processes are not real – they’re just a way to describe what people do. And performance is somehow the result of the collaboration of the people in the process, of how well they handle the situation to come up with the right outcomes for customers and or themselves. Performance, really, is a reflection of competence.
Developing people is the key lean approach to performance, which means somehow imbuing people with increased competence so that they can better handle the situations thrown at them, and continue to help their customers with their problems – the customer’s real-life problems, not the problems in the process.
Monkey See, Monkey Teach
Developing people, therefore, means in practice that each person must learn new competencies as they do their job. But how? Allow me a digression at this point. Exciting new research in paleontology is showing that the critical divergence between our ancestors and other hominids might not have been in learning ability but teaching ability. After all, our chimp cousins learned tool use from observing each other but didn’t know how to pass this knowledge on from one generation to the next.
How do we teach adults to acquire new competencies? This is far from a trivial question. First, they’ve got to be motivated – they’ve got to be ready to make the effort to learn. Second, they need to be able to integrate new facts and habits within their existing experience, without which they will reject any new knowledge, much like trees might reject a new graft.
The core learning problem is that of transference: how does new knowledge transfer from the master to the student, and then from the student to the concrete situation they’re faced with. These two problems have stymied researchers for more than a century leading to continuous dismay about how to optimize school curricula for, well, learning. Here’s what we know:
- Teaching must be concrete for learners to be able to integrate new ideas into their existing mental models.
- BUT if basic, abstract, principles are not taught as well, the concrete learning does not transfer to similar-yet-different situations.
- This requires exploring new knowledge in a wide range of concrete situations.
In the end, problem-based teaching seems the best method to grow competencies in adults (in medicine as well) because it focuses on:
- Motivation: Responsibility for solving the problem rather than walking past it – the “child looking into the well problem” anyone will pull back the child, whether they know them or not.
- Diagnosis: The self-motivated effort to correctly diagnose the situation which mobilizes the person’s own experience in an attempt to acquire new knowledge, rather than as a defense against new knowledge.
- Exploration of root cause: Extrapolating the diagnosis to more basic principles or theory to try to understand the “why?” of the problem and not simply the bad luck of it. Here again, this deliberate effort from the learner is about mobilizing deeper knowledge structure – and thus gaining an opportunity to change them.
- Formulating a countermeasure: This is concrete try-and-see and the key to acting one one’s thinking. Countermeasure here is essential to avoid too radical, abstract “solutions.” For the learning to work, the countermeasure has to address the immediate concrete problem in a limited way and close the door to “ultra-solutions” (solutions that make the situation change so radically, the problem does not appear, but neither does new knowledge). The challenge here is not to make the problem disappear, but to change one’s response to it in order to better address it.
- Checking the impact: Not moving on until one has concluded whether the new way of acting impacted the problem or not (worked, didn’t work, indifferent results).
Real Teachers Don’t Teach
In this concrete teaching approach, the teacher (sensei in lean parlance) doesn’t do much teaching, but points towards concrete problems to be solved. If done concretely, this can turn upside down the formulation of the problem and open the way to new learning.
For instance, in a sophisticated assembly operation where about 10 operators were building 10 different machines from end to end, the management team was discussing the lean concept of visual management and wondering how to better control the work content of the operation by visualizing start time and end time. The sensei asked: What would it take to only build one product at a time?
The answer was: We’re already building one product at a time, can’t you see? You don’t understand, each operator builds one product at a time.
What would it take to build, collectively, one product at a time?
After thinking about it the management team realized this would mean breaking up the work content across the 10 operators to have a continuous flow of work that would deliver one product at a time as opposed to 10 products in parallel.
To the sensei, this is not a solution, but a countermeasure to the problem of overburdening the operators with hours long work content – far too much to hold comfortably in one’s mind without making any mistakes and rework. By breaking up the work content, operators will be able to focus on smaller chunks and better highlight the difficulties, thus leading to new problems and new discoveries about how to assemble on time without defects.
To the management team, this posed a concrete problem that could lead to a diagnosis, a better understanding of the fundamental concept of one-piece flow and attempts to do so would yield further knowledge about how to transfer continuous work to all other operations.
Cookie Cutter Solutions
Although focusing on problems might sound needlessly dour and somewhat boorish, the aim is not to make the problems magically go away by finding solutions (a hateful thing management says: If you’re not part of the solution, you’re part of the problem), but acknowledging we face problems all the time and harnessing them to teach in order to develop everyone’s autonomy to better deal with their own work.
Solutions imply that generic issues have a cookie cutter solution that can be applied across varied situations. This is simply not true (or rarely true). Finding countermeasures to typical problems tackles the transfer problem of learning to face a generic problem in a variety of situations to both better grasp the deeper principles (which will later facilitate problem solving in similar cases) as well as the differences between one case and the next to be more autonomous in real life. Teaching – and learning – is not simply about applying knowledge to one case, but transferring knowledge across cases!
There are so many lean management principles to know and tools to master at the start – is there an easier way to begin?
Dear Gemba Coach,
Isn’t there an easier way to start lean? For a beginner, it seems like such a mountain to climb – all these things to know, tools to master, counter-intuitive principles to grapple with. Can’t we make access easier?
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?