Featured Product
This Week in Quality Digest Live
Lean Features
Shiela Mie Legaspi
Set SMART goals
Gleb Tsipursky
Belief that innovation is geographically bound to office spaces is challenged by empirical evidence
Jamie Fernandes
From design to inspection to supply chain management, AI is transforming manufacturing
James Chan
Start the transition to preventive maintenance
Mark Rosenthal
The intersection between Toyota kata and VSM

More Features

Lean News
New video in the NIST ‘Heroes’ series
Embrace mistakes as valuable opportunities for improvement
Introducing solutions to improve production performance
Helping organizations improve quality and performance
Quality doesn’t have to sacrifice efficiency
Weighing supply and customer satisfaction
Specifically designed for defense and aerospace CNC machining and manufacturing
From excess inventory and nonvalue work to $2 million in cost savings
Tactics aim to improve job quality and retain a high-performing workforce

More News

Bruce Hamilton



In defense of engineers

Published: Tuesday, November 8, 2016 - 15:15

One of Shigeo Shingo’s popular status quo targets was engineers, whom he placed in three categories: table engineers, those who just sit around a table and talk about problems; catalog engineers, those who think the solution to every problem can be found in a catalog; and nyet engineers, those who say no to every request (nyet is Russian for “no”).

On one rare occasion, I heard Shingo retell his engineer category story in the presence of my company’s CEO, Bob R., who was himself an engineer. “I’m a can-do engineer!” Bob bristled in response. Although I’m not a big fan of stereotypes, I smiled at Bob’s retort. I think Shingo made jibes to shock people, in this case our CEO, into consciousness.

Similarly, another teacher, Ryuji Fukuda, once commented, “Engineers should polish their brains, not their shoes.” Fukuda offered the comment as light humor, but I recall a couple engineers in our group were not amused. “I feel like a doormat,” one engineer said to me. “When things go wrong, production just blames us.”

Full disclosure: I am not an engineer, and I might on occasion have been one of those production folks who walked all over engineering. While the same barbs slung by Shingo and Fukuda could just as easily be directed at other occupations, in Toyota Production System (TPS) lore, the role of engineers seems to be more critical. Engineers play such pivotal roles in a company’s success that the need for them to be involved in continuous improvement is that much greater than other occupations. If their work isn’t done “right the first time,” internal as well as external customers are adversely affected. Design for assembly (DFA) proponents, Boothroyd and Dewhurst, for example, point out that every assembly fixture is essentially a workaround for a design that didn’t adequately consider the folks who do the assembly. And Shingo noted that the best way to avoid production mistakes is to design them out before the product is released to production.

So why aren’t these things considered before product launch, and why do problems take so long to be fixed after launch? Perhaps the answer to these questions is that engineers are subject to the same cockamamie rules as production. Here’s a short list:
• Engineers typically have far too much work in process. Studies have demonstrated that two projects at once is an ideal number for a design engineer, yet most designers have many more.
• Engineers aren’t typically rewarded for other people’s designs (OPD), which creates pointless complexity, i.e., redesigning the wheel.
• Fixing problems with existing designs is seen to be far less important than creating new designs. Engineers are not encouraged to get into ‘old plumbing.’
• Design tools make seemingly simple changes arduous.
• Cost accounting provides no encouragement for engineers to design for assembly, maintenance, testability, or ease of changeover. Only functional cost is considered important.
• Most engineering departments are function-cloisters of cubicles that limit information flow between engineers in the same way that is often seen in production. Donald Reinertsen and Preston Smith, authors of The Principles of Product Development Flow (Celeritas Publishing, 2012), quip, “Communication between engineers is inversely proportional to the square of the distance between them.”

When W. Edwards Deming commented that 95-percent of an organization’s performance problems are caused by systems, he clearly wasn’t referring only to production. On the positive side, engineering departments that are able to break through status quo rules are creating huge competitive advantage for their organizations. Those who can’t break through, however, will regrettably continue to be doormats.

Can you think of any other “rules” that impede engineers? Please share them.


About The Author

Bruce Hamilton’s picture

Bruce Hamilton

Bruce Hamilton, president of the Greater Boston Manufacturing Partnership (GBMP), brings hands-on experience as a manager, teacher, and change agent. Prior to GBMP, Hamilton led efforts to transform United Electric Controls Co.’s production from a traditional batch factory to a single-piece-flow environment that has become an international showcase. Hamilton has spoken internationally on lean manufacturing, employee involvement, continuous improvement, and implementing change. Also, he has contributed to numerous texts ranging from visual control to variety reduction. Hamilton’s blog, Old Lean Dude, is an ongoing reflection on lean philosophy and practices, with an emphasis on keeping good jobs close to home.



Too often organizations stovepipe their staff into sales, production, quality and engineering departments that reinforce both stereotypes and insularity so that engineers reinforce their natural isolationist tendancies to become a closed caste that often treats input from other parts of the organization with suspicion if not outright hostility.  This happens in other parts of the organization as well; but, engineers, due to the personality traits that make them good engineers, are especially prone.  Organizations need to build cross-functional teams with limited lifespans that erase these barriers.  Engineers need to learn to open their ears to ideas of others.