Shipulski On Design

As an engineering leader I work with design engineers every day. I like working with them, it’s fun. It’s comfortable for me because I understand us.  Yes, I am an engineer.

I know what we’re good at, and I know we’re not good at. I’ve heard the jokes. Some funny, some not.  But when engineers and non-engineers work well together, there’s lots of money to be made. I figure it’s time to explain how engineers tick so we can make more money. An engineer explaining engineers, to non-engineers – a flawed premise?  Maybe, but I’ll roll the dice.

Everyone knows why design engineers are great to have around.  Want a new product?  Put some design engineers on it.  Want to solve a tough technical problem?  Put some design engineers on it. Want to create something from nothing? Design engineers. Everyone also knows we can be difficult to work with. (I know I can be.) How can we be high performing in some contexts and low performing in others? What causes the flip between modes? Understanding what’s behind this dichotomy is the key to understanding engineers. What’s behind this?  In a word, “change”.  And if you understand change from an engineer’s perspective, you understand engineers.  If you remember just one sentence, here it is:

To engineers, change equals risk, and risk is bad.

Why do we think that way?  Because that’s who we are; we’re walking risk reduction machines. And that’s good because in this time of doing more, doing it with less, and doing it faster, companies are taking more risk.  Engineers make sure risk is always part of  the risk-reward equation.

The best way to explain how engineers think about change and risk is to give examples.  Here three examples.

Changing a drawing for manufacturing

Several months after product launch, with things running well, there is a request to change an engineering print.  Change the print? That print is my recipe. I know how it works and when it doesn’t.  That recipe works.  My job is to make sure it works, and someone wants to change it?  I’m not sure it will work.  Did I tell you it’s my job to make sure it works? I don’t have time to test it thoroughly. Remember, when I say it will work, you expect that it will.  I’m not sure the change will work.  I don’t want to take the risk.  Change is risk.

Changing the specification

This is a big one.  Three months into a new product development project, the performance specification is changed, moving it north into unknown territory.  The customer will benefit from the increased performance, we understand this, but the change created risk. The knowledge we created over the last three months may not be relevant, and we may have to recreate it. We want to meet the new specification (we’re passionate about product and technology), but we don’t know if we can. You count on us to be sure that things will work, and we pride ourselves on our ability to do that for you.  But with the recent specification change, we’re not sure we can get it done. That’s risk, that’s uncomfortable for us, and that’s the reason we respond as we do to specification changes.  Change is risk.

Changing how we do product development

This is the big one. We have our ways of doing things and we like them. Our design processes are linear, rational, and make sense (to us). We know what we can deliver when we follow our processes; we know about how long it will take; and we know the product will work when we’re done. Low risk. Why do you want us to change how we do things? Why do you want to add risk to our processes? All we’re trying to do is deliver a great product for you. Change is risk.

Engineers have a natural bias toward risk reduction. I am not rationalizing or criticizing, just explaining. We don’t expect zero risk; we know it’s about risk optimization and not risk minimization.  But it’s important to keep your eye on us to make sure our risk pendulum does not swing too far toward minimization. The great American philosopher Mae West said, “Too much of a good thing can be wonderful.”   But that’s not the case here.

When it comes to engineers and risk reduction, too much of a good thing is not wonderful.

4 Responses to “Engineers and Change?”