Dear Gemba Coach,
My company wants to reduce its fixed costs. And as part of this my management has asked me to apply the lean techniques we’ve implemented in production to reduce headcount in engineering. I’m uneasy about doing this and wondered where I can find out more about lean in engineering departments.
Pull the andon chord! Stop the presses! Hold your horses! Think again! I realize it’s hard to ask one’s management to reconsider, but in this case it is worth expending some political capital to do so. Tell them that “reducing headcount in engineering” as an objective is going down a dangerous slope which might cost the company dearly if it’s not examined very, very carefully.
I’m not saying we should not be seeking productivity from engineering. As Orry Fiume once put it succinctly PRODUCTIVITY = WEALTH. The question, however, is to understand more fully what kind of productivity we’re seeking. In manufacturing, quite clearly, productivity is about increasing output and decreasing headcount. In lean, real productivity is even more specific since it’s about reducing headcount to produce the same number of products. As Ohno first noted (in the original Toyota Production System book), increasing output with the same number of workers doesn’t mean the sales are there, so it might be overproduction rather than productivity. And, improving efficiency by a fraction of a worker is not productivity because the person is still there. So productivity efforts in production comes down to reducing headcount while producing the same amount of products.
Engineering Value
Not so in engineering. The question to ask yourself is: what does individual productivity mean for an engineer? In product design or development, the issue is smarter solutions, not quantity of work. In other words, productivity is about shortening the lead-time to reaching the right solution. Increasing an engineer’s productivity is not about making him or her work longer or harder, but supporting her in reaching the right conclusions sooner. And back at the gemba, I’ve seen time and time again what applying cost cutting ratios to engineering departments can produce in terms of overworked engineers and terrible, terrible product decisions. As Jeff Liker points out, for a number of reasons, the moment your engineers are staffed at more than 80% capacity, your engineering department starts burning out, and your company will pay the high price of consequences on the market.
Let’s backtrack and think this through from a lean perspective. The overall aim of lean is complete customer satisfaction and complete elimination of waste. So what kind of waste are we talking about in the case of engineering? And how do we go about eliminating this kind of waste?
It’s often said that engineers cast the largest cost shadow because they have such an impact on the product, the manufacturing process and the entire supply chain. But engineers also cast the longest shadow on sales: great products sell themselves. The first and foremost aim of any company should be leading products. Indeed, Toyota didn’t transform itself from a near-bankrupt small town Japanese car company into today’s leading automotive manufacturer by simply reducing costs. It did so by designing and building cars people wanted to buy! In a saturated market, every car sold had to be taken away from one of the big 3 models—not an easy challenge. Toyota cars were not just cheaper. They were also better (no matter that the entire industry found them uglier as well, people bought them for their own reasons).
Right Product, Right Audience
The first waste we need to tackle is the waste to the customer: what are the cost of use and cost of ownership wastes that the engineering department creates through its technical choices? For instance, I was recently part of a post-mortem discussion about why a new product that was supposed to make a killing on the market turned out to be a spectacular failure. The product was a piece of a kit used by installers that work on heating systems. The new product is objectively better from both cost and performance point of views, but it’s harder to use and install, and necessitates new training for all the technicians. In this case, engineering made a cost/performance/usability trade-off that the market simply did not appreciate. Technicians preferred using their old widget, known products, rather than switch to the new one. Another way of looking at it is that the incremental gains of the new offering were not spectacular enough to compensate the switching cost. The company is doing fine and, in this instance, recovered well selling it’s old range, but in terms of engineering productivity this was a disaster as the engineering teams could have been working on something else instead.
The lean way of attacking this issue is the “chief engineer”: a heavy-weight project manager whose first role is to synthesize all known information of customer preferences, formulate a concept of the product, and translate this into engineering parameters. One classic Toyota story is that of chief engineer Yuji Yokoya being tasked with designing the new minivan model for the U.S. market. He chose to drive in every state of the U.S., northern Mexico, and Alaska to understand real customer usage conditions. Amongst the many things he learned, he realized that Americans will drive much longer distances with their kids than Japanese drivers ever would, and so the interior design of the car would be essential: “The other thing that really hit home is what I call the kid factor,” Yokoya said. ‘It’s the kids who occupy the rear two-thirds of the vehicle. And it’s the kids who are the most critical and the most appreciative of their environment.” Yokoya concluded the Sienna would be defined by its convenience, flexibility, and interior comfort.
In this case, Toyota engineers also did a lot of kaizen. “The goal was not to slash costs,” a manager clarified. “The goal was to achieve greatness at a great price and that meant rethinking, refining the entire development and manufacturing process.”
And so the first source of engineering productivity is hitting upon the right product for the right audience. If you don’t get this right, anything else is irrelevant.
Justifying Costs
The second shadow of waste created in the engineering department is the actual cost of the product, first in terms of purchased parts and materials (about 70% of most assembled products), second in terms of capital expenditure to by the production equipment (huge fixed costs!) and third in terms of labor content itself. Think about it. Every time an engineer uses a new screw in the product, he creates a full supply chain: a supplier has to be identified, the parts have to be procured, stocked, etc.
The lean approach to this aspect of the cost shadow are engineering standards. In the lean world, each engineer is supposed to keep his or her book of knowledge with what he or she knows about technologies, processes, suppliers and so forth (for more on this check out an earlier column: engineering checklists). The French counterpart of Toyota’s chief engineer in the PSA/Toyota joint venture vehicle confessed to me that he was astonished to find that the chief engineer remembered issues with models long before his time, which is how he learned about each engineer’s responsibility to keep their own paper or computer files of validated learning: “standards” learned from empirical experience in previous development.
The most obvious place to start with this is a standard parts list for non-critical items. The idea is not to impose on engineers a rigid control stifling their creativity, but to have them justify when they want to use a part outside the list: it’s not forbidden, but it has to be explained. Reducing the number of parts used has a dramatic effect on the whole supply chain. Similarly, reducing the number of technical processes used where we can enables us to re-use old equipment and can reduce capital costs by a sizable fraction. Again, there is no point in constraining engineers, as complete customer satisfaction comes first, but to develop thoughtfulness about the impact of engineering choices on the rest of the value chain.
Milestones Into Millstones
Thirdly, a further form of waste can be seen in project issues that contribute to blowing milestones and consuming more man-hours than expected. One key target of lean development is “zero engineering changes after tooling” – as engineering changes late in the process can be incredibly wasteful in both capital (re-doing tools) and costs (engineering man-hours). Most engineering projects I come across have horrors stories about poor upstream decision-making with large consequences downstream. I’ve come to the conclusion that the best way to get your project to burn down in flames and crash is to answer any engineer’s request for an early management decision. What I’ve seen time and time again is that when an engineer asks for a spec-based management decision, he or she is usually facing a problem they don’t fully understand or don’t know how to solve. Rather than say upfront: I don’t know how to do this, they substitute to the problems solutions they are familiar with, and ask management to commit. As you can imagine, this rarely ends well and all sorts of delayed bombs go off as the project nears completion.
The lean approach is to decide as late as possible, but try to spot critical issues before drawing. The idea is to lock onto the few technical challenging problems and develop several alternatives that can be evaluated with all the stakeholders of the value chain. One way of visualizing this is to draw circles corresponding to engineering, marketing, production, purchasing, logistics, etc. and try to find which solution best (or least worst) fits within all the circles. Such “set-based concurrent engineering” is a core lean practice that is nonetheless difficult to learn as it requires enough upstream resources to develop solutions that won’t be used (in practice, that’s not quite true as many aspects of the discarded solutions are still used in the final development).
There are many more techniques in lean engineering of course (target costs, slow builds, supplier integration and so on), but the point is always the same: lean engineering is about creating a learning structure and learning events to help engineers better understand the consequences of their technical choices beyond their immediate development problems. As a result, headcount may – or may not come down. This is an outcome issue, not terribly relevant to the problem at hand: developing great products for customers at an affordable cost. In any case, whether engineering headcount increases or decreases, the objective of reducing engineering headcount to reduce fixed costs is plain silly. This is like saying that you aim to reduce yeast in baking bread because you’re using less flour. Engineering’s total percentage cost in the company’s P&L is rarely huge and, using engineers to reduce non-quality costs would be a much sounder effort.
I realize this answer might not help you much, but I can’t of any other way to go – this is a critical-to-company debate and if your management is going down that road, it’s a battle well worth fighting, as all your jobs might be at stake. I’ve witnessed first had what a poorly designed product can do to a business, and it ain’t pretty. As always, the entry point into lean is about getting agreement on the problem you’re trying to solve, rather than implementing the known solution. Hope it helps some, and don’t hesitate to continue this debate as this is an incredibly rich and sensitive topic we still have so much to learn about!
