Why isn’t there more emphasis on lean engineering?
Dear Gemba Coach,
Why isn’t there more emphasis on lean engineering?
That’s an excellent question. I was recently wondering the same with James Morgan, the co-author of The Toyota Product Development Process , who is now a senior engineering director at Ford. We share the understanding that at the root of every corporate revitalization (Ford, Apple, etc.) we find the product, the product, the product. Why managers don’t seem to get that is a mystery to me.
In point of fact, if I had to sum up 20 years of practice in one piece of advice it would be: “focus all your energies on making the best product you can, and let everything else take care of itself.” On the gemba, I believe that the very first step of lean is quality first, safety always. When I help CEOs with lean transformations, the first port of call is looking at customer complaints to see firsthand what customers tell us about the product. Furthermore, I don't believe in processes in the abstract. A process only makes sense if we understand what the product does for customers, and how the process delivers this value.
The results are there to prove the point. To prepare for my webinar and workshop on “the business case for lean” I asked several CEOs to sum up their results over the past three years: 61% sales increase, 62% cash improvement, 74% margin increase for one. Plus 93% turnover with 173% EBITDA improvement for another while maintaining its cash position regardless of sales growth (total inventory was reduced from 600 days to 80). And this with industrial companies working in France where industrial activity is in free fall. Lean being lean, neither of these CEOs feel very successful day to day – “problems first” does tend to cloud the view – but the results are amazing. Such results are possible, however, because they did not start by improving productivity or cutting costs. Rather, they started by improving their products and selling more (in both cases there was no additional sales push, indeed, in the second case, which is high-tech metallurgy, there isn’t even a sales structure). These examples are not lucky flukes. They reveal the potential of lean if one fights the right battles, first defined by Toyota as “in order to make things, you’ve got to make people.”
Lean Engineering's Promise
Engineering is the largest piece of this equation. Engineering is where both customer satisfaction and costs are largely set. Sure, production can either enhance both with kaizen by mastering processes and eliminating waste, but structural success of a product and its production costs are determined by engineering decisions and skills. Toyota did not take the number one spot on the podium solely by reducing its manufacturing costs. It took over a market dominated by historical giants by offering cars people bought. In this sense, the promise of lean engineering is even larger than anything we’ve ever done on the shop floor. So, indeed, why so little material about it? I suspect there are three main reasons for the lack of interest, despite the mammoth potential gains.
Firstly, it’s easier to look for a lost key under the light because there, we can see. Since the publication of The Machine That Changed The World (which does go in-depth on the engineering aspects to Toyota’s success) books about lean manufacturing have increased exponentially as the field developed. On the engineering front, after Durward Sobek’s breakthrough PhD thesis (to my knowledge, still unpublished) and Jeff Liker and James Morgan’s seminal book, the few lean engineering books (with a few notable exceptions, such as Michael Kennedy’s work) that I’ve seen aren’t about how Toyota does engineering, but more about how to apply known lean manufacturing principles to the engineering field. This has had the unfortunate effect of focusing efforts on “optimizing” engineering resources (read headcount reduction in engineering) by “lean” project management, rather than learning how to make killer products.
One common explanation is that shop floor processes are easier to see than engineering processes, which is true to a point, but I really believe it’s a matter of focus. When the CEO decides to focus on his or her products, the lean techniques are there precisely to, as usual, visualize activities, formulate problems, seek root cause and study countermeasures. Essentially, you find what you seek, so if your problem is reducing engineering headcount, you’ll achieve that, and probably break the company in the process. Conversely if you seek to design product magic for customers, you’ll probably do so as well, and grow the company accordingly. A large reason of why there is not more research on Toyota’s lean way to design products is that there is little demand for it.
A second part to this answer was driven home by Dan Jones who pointed out to me that although Toyota is seen unequivocally as the world master and exemplar in process mastery, it is not so in product development because most people confuse design with style. Toyota cars have been historically rather boring to look at and no one would spontaneously think of it as the furthermost product development company (as opposed to, say, Apple). I won’t dispute the fact that Toyotas are not the most exciting cars to look at, and yet, as Jeff Liker often points out, Toyota is still the unrivalled master of value for money customer surveys.
The deep lesson Toyota has to teach us is that the foundation of its ability to deliver value lies on its skill at understanding value. The issue is to correctly spot what customers are willing to pay for rather than what they say they like – and experience shows these are two very different things. I have the good fortune of knowing the French counterpart of Toyota’s chief engineer on the Peugeot-Toyota joint venture in Kolin and he has become a die-hard fan of Toyota’s lean approach to engineering which he has captured in a nutshell as “people build great products, not systems or organizations.” From an engineering perspective, we currently believe that Toyota has three things to teach us:
- Understanding value from the point of view of customers: customers want everything and nothing according to when you listen to them and who you talk to. Toyota has a unique way of narrowing down the value proposition to hit the sweet spot where the core of the target market for a specific vehicle finds something competitors don’t offer. This is largely done through the chief engineer function where one individual (think of it as the designer) is asked to formulate a concept for the product that will be the best fit-to-fact on customer value for the targeted segment. This is more an art than a skill and it requires both technical mastery and openness and insight in customer usages and preferences, and is developed over a lifetime. Few companies have singled out the chief engineer function, and fewer companies deliberately grow them. And yet, this is one key aspect of conceiving products customers will fall in love with.
- Feeding back production experience into engineering design: through the use of standards and checklists, Toyota has the unique ability to capitalize on production experience at the design phase, and thus come up with robust designs. The impact of this know-how is huge. First, customers experience far fewer problems with new products because there is less wild, untested innovation in them. Secondly, the development process is far less costly because fewer mistakes in the early phases need redesign in the later, more complex phases (cost increase as changes are made later: after tooling, changes become very, very expensive).
- Capturing innovation value from the supply chain: by squeezing suppliers relentlessly, many producers shoot themselves in the foot as, in modern supply chain, much of innovation capability lies with suppliers. I’ve personally been on the gemba of an automotive supplier who came up with a much loved customer feature, but who was pressured so brutally on costs by the OEMs that they had stripped their engineering department to the bone, and as a result, had endless problems to stabilize the innovative product – which meant disappointing customers as well as final assembly muda (by rejecting parts in percentages). Toyota’s fine distinctions in relationships with their suppliers and collaborative approach with key partners enables them to innovate robustly, and continuously as suppliers come up with credible suggestions for new features or improvement to existing ones.
More Work to Do
As to the feeling that Toyota is not an innovative company, all I can say is that I recently drove the new plug-in Prius. Maybe it’s just me, but unplugging the car from the main, driving around in heavy traffic all day with an overall gas consumption of that of a motorcycle – and this in perfect silence – was a very emotional experience. I started fantasizing of a town where every car would be like that: a different world. Toyota has, in actual fact, produced a string of killer products, from the Lexus (the drive of a Beamer with the comfort of a Caddy) to the iQ (the size of a Smart with the feel of a sedan). I remain that convinced the company is as strong an exemplar for engineering as it’s been in manufacturing.
Yet, probably a deeper and more lasting reason why lean engineering isn’t taking off as lean manufacturing has, is Finance’s current dominance in management thinking. I’ve seen what happens when a finance guy gets the top job in a company, or, indeed, in a plant. I’ve lived through excellent companies being purchased (for their cash and EBIT results) by finance-driven equity firms. All your average financial manager cares about is reducing costs. Separating revenue (a marketing problem) from costs (an operational problem) is the kind of nonsense that already drew pages of scorn from Taiichi Ohno, but that has become implicitly accepted as obvious in most companies I come across. Revenues and costs are generated by the same physical processes and splitting one from the other simply leads to dumb mistakes. Furthermore, return on investment thinking frames every issue as a project, and completely disregards the fact that both revenues and costs are created day to day by how people tackle commonplace situations. Results are made in normal conditions, not exceptional ones. What is more, looking at numbers leads financiers to completely dismiss exceptional losses (it wasn’t supposed to turn out that way) even when these so-called “exceptional” costs threaten the very life of the company or society as we know it (I’m not being hysterical: look at how quickly the great crash of 2008 has been dismissed as a rogue event by the financial world).
To be honest, it’s unfair to blame financiers for doing what society rewards them for. The blame lies with the rest of us. Until we come up with a robust, viable, alternative to financial thinking and prove that, in Tom Johnson’s terms, “profit beyond measure” is possible by making products for people with people (and in a more people-friendly way) the situation is unlikely to change, no matter how much we bemoan it. So thank you for your question, which I’ll take as a call to action. The short and the long of it is that there isn’t more about lean engineering because we, the lean researchers, haven’t done enough.
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?