But when should we use design thinking or lean thinking?
Dear Gemba Coach
I read your latest and very interesting Gemba Coach column comparing design thinking and lean thinking. But when should we use each?
Hmm … I’m going to go out on a limb here and give a very personal answer – no doubt many design thinkers will disagree. Lean thinkers as well probably.
To make a long story short the two main differences between design thinking are about where to look for solutions and what path to follow:
- Design thinking starts with the mind and applies solutions to the world. You start by defining the problem and gathering people’s opinions, you formulate a design, and then you apply it. Lean thinking starts with the world: you observe and improve in order to understand the problem with others, so that you and they progressively figure out what the root cause is (through repeated kaizen) and get agreement on where the calculation has to change, and then you come up with a new design in your mind – taking into account their ideas.
- Design thinking looks to design a complete, static, systemic solution. Lean thinking is about exploring through repeated try-and-see, try-and-see until a path appears to resolution. If one promising avenue doesn’t pan out, you try another until you’ve got a clearer understanding of the territory, your path to a better outcome, and the limits of your considered countermeasure. Design thinking is about the shortest path to the complete solution. Lean thinking is about progressing step-by-step until we’re familiarized with the problem and the solution emerges.
As a lean guy I’ll go back where lean starts – at the Gemba. I was yesterday visiting Alliance-MIM, in a greenfield plant built three years ago. I’ve known the CEO for a long time and he had turned around his company in his old brownfield plant when his major (and huge) client went bust and suddenly he had to rebuild an order book for very technical parts from scratch.
He is a passionate metallurgist building additive parts rather than machining them. Traditionally, metal parts are cut out of a bar of metal, which his hugely wasteful. He makes parts by starting with an iron and plastic mix powder, injecting the part through a mold in a plastic injection press, cooking the parts in high-tech ovens in order to get rid of the plastic and bind the metal atoms with additional elements and gasses, creating a specific microstructure and compositions, and then finishing, calibrating and polishing the result. Here’s JC Bihr presenting lean and green as his strategy.
It's not an obvious process because it involves two batch stages: injection (change of mold) and ovens (trays of parts). In the brownfield plant, he turned the situation around through quality first, and then the flexibility of the injection process. As he went looking for new applications, from medical to aeronautics, he suddenly multiplied the number of molds by an order of magnitude, and so the need to reduce injection batch size drastically. He also learned to mix the trays in the ovens, which was a horrific technical problem, and thankfully the guy is a real genius when it comes to metals.
He says it himself: lean saved the company. But although he had set up a truck preparation area and was building customer orders in several goes, trying to get closer to producing every part every day (reducing the every-part-every-interval), he’d never really got the hang of kanban, even though his production manager was experimenting repeatedly with cards between processes. The old plant was separated in two buildings and parts had a courtyard to cross … it was not easy.
When the company started growing again, it could no longer fit in the old buildings and the CEO decided to build a greenfield plant.
He used a 3P approach, and what I considered design thinking. He gathered his top people and they started drawing alternate maps of the best way to optimize flows. They clearly explained the flow problem to many people, and then worked through three criteria:
- What we want to achieve: as fluid a production flow as we can, with the easiest work possible;
- What can realistically be done: how do you organize injection presses and huge ovens in a way that makes sense, considering the issues of molds and pipes and tricky gasses being pumped through the floor;
- How can we make sure this will work in practice and has space to grow in the future; with any high-tech sensitive process, this surfaced yet another huge batch of constraints.
In the end, having done all the prep work, building the plant was relatively smooth and on time, production was interrupted for a shorter time than anticipated, and well, it worked – everyone got engaged and overcame the unexpected issues, such as the outside covering of the building blocking mobile reception and other total surprises.
Score one for how I understand design thinking: clearly explain what you’re trying to do, put people first, bring them on board, and come up with a better design solution.
And, then, in the new plant, the production manager got started with kanban in earnest. Here is the production manager, Johan Guvier, discussing the leveling board with the rest of the management team.
The first thing that appeared was that with a huge – and variable – product mix, with new molds coming in almost every week, the product/process matrix wasn’t stable. It also became obvious that it was possible to create some cells in a different way than envisaged with the design – but now pipes were sunk in the ground.
Then, following the lead-time on the kanbans, it turned out that issues were not where they’d previously appeared to be.
So, following the problems revealed by the kanbans, the CEO and production manager started solving one-by-one all sorts of issues, starting with difficulties people had with the new plant, training, exploring, scratching their heads, moving stuff around. Step-by-step improvements.
The resulting – and evolving – design is nothing like what was envisioned at first. Kanbans don’t lie, and reality, or “friction” as it was called in XIXth century strategic thinking, strikes back:
- Some minor, overlooked, details go wrong creating big unexpected problems;
- Some things we simply don’t know and have to discover when they bite us;
- Everyone has an opinion and whenever we assume people understand things the same way we later discover they have widely differing interpretations.
Lean thinking with visualizing the process, focusing on abnormalities, clarifying standards, marking progress gets you much closer to dealing with reality than any design thinking method that I know (and I used to draw systems thinking feedback maps and computer simulations for a living, so I know something about designing smart models).
With Dan Jones, Jacques Chaize and Orry Fiume we tried to capture that vast gap in thinking by describing lean thinking as 4F:
- Find problems by visualizing the flow and looking at waste;
- Face the biggest challenges by setting quantifiable goal posts;
- Frame these challenges in ways everyone can grasp, the more visual the better;
- Form organic answers from people’s initiative to shape a collective response.
As opposed to traditional thinking which is essentially about 4Ds:
- Define the problem on paper;
- Decide what to do on the main choice points;
- Drive the execution through an action plan;
- Deal with the situation when unexpected consequences turn up.
The main difference between design thinking and lean thinking is neither about creativity or people involvement – both approaches seek both. It’s about the source of information. The most basic psychological law uncovered by the last 30 years of cognitive and behavioral research is that what you pay attention to becomes important with respect to everything else. Anything on top of your worry list feels incredibly important, because it’s on top of your worry list, not because it is important.
Ìn traditional thinking, we define what we worry about out of what is in our heads. In lean thinking, we worry about kanban cards, which makes them very important, and the lead-time associated with each card, the abnormalities and delinquents, which makes real-life problems stand out, and involving people in solving them becomes very important. As a result, we attack different issues, at a very different granular level (like making metal from powder, not cutting it from iron bars) – a granularity that can’t be attacked with engineering and engineers, but needs cooperation between hands-on operators and engineers. It’s a completely different way of approaching the world when you use kanbans as a discovery method and learning what just-in-time teaches you, step-by-step.
The resulting solutions are just radically different, as we can see from how Toyota turned around the NUMMI Fremont plant in the eighties, from the worse performing GM plant to the best, and how Tesla has turned back the very same plant, now that they’re in it, in a quality and delivery mess that simply doesn’t get the production out.
To answer your question, I doubt that we can ever stop using design thinking – this is our default mode. In lean we use design thinking in what we call “helicopter thinking” – looking at the big picture, with tools such as material and information flow analysis and so on. But at the very granular detail of reality, we use “look with your feet, think with your hands” lean thinking by following the kanban cards and always trying to get closer to one product by one product, one customer by one customer, one team member by one team member and treat everything with respect to their individuality. Therefore we always use both. Start from lean thinking, write down the big picture with overall designs and models, bring it back down to the kanban level and so on.
When you think of a practical solution, ask yourself: what general principles are at play here? When you’re thinking in generalities, ask yourself: what should we do in practice for the next step?
Is my crazy new boss right that applying standardized work is the foundation of lean?
Dear Gemba Coach,
My new boss is a lean fanatic crazy about standards. He’s created a new team to audit standards and is telling us that applying standardized work is the foundation of lean. It’s creating a lot of resistance, and I don’t know what to make of it.
Can 5S apply to coding?
Dear Gemba Coach,
We’re exploring lean in software development. Can 5S apply to coding?
Isn’t there a better way to manage inventory than just-in-time?
Dear Gemba Coach,
This is 2019. Isn’t there a better way to manage inventory than just-in-time by now?