I want to apply lean to engineering. Any thoughts?

Dear Gemba Coach

I am the regional manufacturing VP of a large industrial company. After the latest reorganization, engineering now comes under me. I’ve had good success with lean in manufacturing and want to apply it to engineering. I plan to get engineers to solve production problems faster. Any thoughts?

I completely agree with your goal. One of the uniquely “lean” aspects of lean engineering is greater teamwork between engineering and production – indeed, it is a distinctive sign of lean that the plant is ultimately the measure of all things. The peace of mind of both customers and producers is what we seek, and both are tightly linked. Indeed, if I had to sum up years of practicing lean with CEOs at the full company level, I’d say something like:

Using pull and stop-at-defect to surface good VA and VE problems to improve product design and develop people’s skills.

Value Analysis problems are those we find in products being currently produced, whereas Value Engineering problems are issues we can solve at the design stage, mainly from previous value analyses. Typically, by looking at customer complaints, final inspection and flow we will discover that some products in our range work better for customers and are easier to assemble than others. Main reasons tend to be:

• Fragile aspects: some dimensions of the product that don’t resist well to real customer usage, and customers do rather unexpected things with products in real life.
• Difficult assembly: if some aspect of the product is difficult to assemble, chances are some assembly won’t be done well enough, and chances equally are this will slip through inspection control, as the assembly will be standardized.
• Borderline manufacturing processes: when solving engineering problems engineers are often tempted to stretch known solutions to dicey conditions. This can work on paper, but in real production conditions the odds are that the manufacturing process won’t be robust enough and create both rejects and defects in the final product.
• Supply Chain surprises:  without close relationships with suppliers it’s often hard to know what exactly goes into the parts they provide at tier 2 or tier 3 level and sometimes quality causes are hidden deep in the supply chain and hard to get to.

 Engineers Are Just Different

At the gemba, what we do is look at red bins in the process and discuss with engineers as to whether the problem is one of:

1. Operator difficulty: is the gap in assembly itself, and why?
2. Process problem: is the machine part of the process not performing as we hoped?
3. Design issue: is the part as we’ve designed it difficult to assemble or difficult to make?

Experience shows that as we solve these problems with engineers, one by one, as they appear on the shop floor we discover issues no one had taken seriously before and sometimes it takes us deep into the very theory of how we make the parts. Working from the pull,  flow is essential because it prioritizes engineering problems in terms of what operators stumble upon and not what engineers would like to work on. In this sense, I think your goal is exactly a lean one.

However, and I realize I need to eat my hat by hearing me say so, it’s not so simple because we have a professional culture issue. Yes, yes, I know I’m the guy who’s been ranting that culture is a red herring and not a working concept and so on, but there it is. Engineers are simply very different from production guys.

I’ve learned the hard way at the gemba that involving engineers in solving operators’ problems is very, very difficult – and for some very valid reasons. First, engineers are typically already overloaded by their current workload, so it takes a strong managerial push to get them to take the time to interest themselves in what can be found in the red bins. Secondly engineers tend to think long thoughts, they think across weeks or months, whereas production guys are all about solving problems right now and then moving on to put out the next fire, it’s very hard to talk across different timescales. Thirdly, engineers tend to think in terms of the following mental cycle:

1. Understand the practical problem
2. Frame it as a theoretical problem
3. Solve it in theory
4. See how the theoretical solution can be applied in practice

Whereas production people tend to go from 1 to 4.  They don’t much care about the theory as long as the problem goes away.

What Is Product Development’s Job?

What it comes down to is that at the outset, it’s extremely hard to interest engineers in production problems – they have neither the patience nor the inclination, and many will actually feel threatened by the nuts-and-bolts, grease-and-grime aspect of daily life on the shop floor. The current generation of engineers, in particular, has been brought up to see themselves as on-the-screen designers and not failing 1,000 times before finding the right filament to make the light bulb work type of engineers.

The upshot is that I’ve found that in order to coach engineers to involve themselves with good VA or VE project you’ve got to start with a fully “engineering culture” lean program as well, to create a context for engineers to find their bearings in lean before, in the end, bringing them down to the customer gemba or the shop floor.

One of the best ways to do so in my experience is to start with Durward Sobek and Allen Ward’s groundbreaking Lean Product and Process Development, second edition, book and to set up an engineer’s program based on the key idea that Development’s job is to create operational value streams. In practice, what I’ve found works quite well is:

1. Reaffirming the job of chief engineer for each product
2. Creating a visual product launch plan to see ahead/late for each new product
3. Asking the chief engineers to write a two-page concept paper for his or her product, detailing customer segment, customer value, what functionality will be in the product and what won’t be in terms of performance, main techs, milestones and milestones management plan, and unresolved technical issues to explore before starting the project.
4. Conducting target cost exercises
5. And doing various teamwork workshops throughout the project life, such as tear downs, upfront problem solving, A3s, slow builds, 3P and so on until launch.

Re-Focus on Customers

Many of the engineers I come across are hampered by a very narrow definition of specs. They’re told it’s marketing management’s job to write up specifications, and they will design to spec. As a result they loose the “engineering” part of their job – they see themselves as delivering designs, not performance. This is a very hard nut to crack because the whole engineering management system often locks them in this position with brutal gate reviews, design reviews, and all sorts of tick-the-box activities that make sure the deeper questions are never asked.

On the other hand, I’ve found that once you’ve interested your engineers to what the product does for customers, once the discussion is back on to product performance and price, the engineers typically will follow through in production – after all, they are long thinkers, and when grabbed by a topic, won’t let it go. They’re engineers!

To answer your question directly, I completely agree with your aim, but I’d be a tad careful about how you go about it. I’d start with a lean development project that focuses on creating discussions about customer value and how we aim to deliver that (a formal way to do this is through QFD, but again, this requires some maturity) to involve engineers and create teamwork, and then progressively bring them to the shop floor to understand real-life issues. With engineering, it’s more important than ever not to try and force engineers to do anything (if you do, they’ll simply do it badly), but to involve them progressively in seeing that customer problems and operational problems are just as interesting as the problems they themselves prefer.