Doormats

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
• 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. Bob bristled in response, “I’m a can-do engineer!”  While 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.” Dr. Fukuda offered the comment as light humor, but I recall a couple engineers in our group did not see the humor. “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 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 is not done ‘right the first time,’ internal as well as external customers are adversely impacted.   DFA proponents, Boothroyd and Dewhurst for example, point out that every assembly fixture is essentially a workaround for a design that did not 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 is 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 are not typically rewarded for OPD (other people’s designs), which creates pointless complexity: 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 or maintenance or test-ability 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. Preston Smith, author of The Principles of Product Development Flow, quips, “Communication between engineers is inversely proportional to the square of the distance between them.”

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

When Edward’s Deming commented that 95% of an organization’s performance problems are caused by systems, he clearly was not 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 cannot break through however will regrettably continue to be doormats. 

O.L.D.