When Engineers Should Embrace Change



Every CFO would answer the question with, “When it costs less.”  Period.  End of story.  Unfortunately, when dealing with high-tech design, this is blatantly untrue.  There is a plethora of bad technical decisions awaiting every company, from untested software to unproven IP, going cheap (and thus forcing change upon your engineers) isn’t always the best way to go.

As with any real design, balance is the key.  Change is necessary.  If semiconductor designers stayed with the same software they used in the 80′s, our laptops would still be as powerful as handheld calculators.  The goal of the company should be to balance the benefits of change (improved profit margins, more advanced technology), with the associated risks (my recent post: Why Engineers Resist Change & How To Change Their Minds).  Engineers need to embrace change under the following circumstances.

1) “Be a little selfish.”

Engineers should embrace change if it provides an immediate opportunity to increase their own personal skill sets.   This applies to learning new software, new programming languages, new management techniques, and of course new design methods.

It’s true that some companies will force this upon the engineer during times of high stress, causing the engineer to burn up a lot of personal time in the process.  I would argue that it’s probably still worth it.  Bottom line, if it’s something that can be put on your resume and the company is paying for the training, you should do it.

2) The gains are too good to pass up.

Some changes are necessary simply because there is new technology available that will greatly improve design performance and engineer productivity.  This often comes in the form of new software with vastly better runtimes, memory usage, and functionality.

In the industrial world, new products and materials can provide unforeseen improvements to high-tech designs.  The long-term gains available should be embraced by the engineer, given appropriate runway and deadlines.  This is where upper-management normally misses the boat.

A significant change to toolsets, products, and/or materials, at any point in the design process, will most likely cause a schedule delay.  The key is balancing this delay, assuring that finished products will still hit the ideal marketing windows.  Given appropriate time, the engineer should embrace the technology improvements and use them to their fullest extent.

3) “It’s all about the money.”

When all is said and done, the goal is to make money.  The CFO’s mantra to lower costs is not entirely evil, it should be everyone’s goal to help the bottom line.  Again, the key is balance.  If there is a significantly cheaper option available, whether it be software, tools, or parts, it should be evaluated in detail by the company’s best engineers.  It is up to them to determine the technical capabilities of the new toy.

If end-design schedule, performance, or functionality will suffer as a result of a change, it is up to the evaluating engineers to clearly communicate this to upper management.  (Unfortunately, they are not always given the chance to do so, but that is a blog for another day.)  Engineers need to be reasonable with this analysis, and if the change won’t have a significant effect on productivity or margin of error, then the change should be embraced for the betterment of the company’s profit margin.

Industrial Interface

There is of course the rare case when a new tool saves the engineer time and the company money, while at the same time maximizes the quality of his or her design, all with virtually zero learning curve or schedule delay hit.  These opportunities should be jumped upon in earnest!

Category: Efficiency, Engineering & Design

Tagged: , , , , , ,

3 Responses

  1. Gerald says:

    “causing the engineer to burn up a lot of personal time in the process”
    This is where I want to jump in. Engineers are often very company loyal and will invest personal time in these kind of things. But I think it is absolutely wrong for a company to demand or expect that.
    Where I currently work it is expected of engineers to put in at least a couple of hours of work in the evenings (while the other departments are not) and not get paid for those. When I refused I got repremanded.

    “it should be evaluated in detail by the company’s best engineers”
    Actually it shouldn’t let us take the example of a new programming language. A good programmer can use many languages to do the same (syntax is not as important), he may have a favorite. A lesser programming god has problems with this, suddenly the things don’t work as he expects because now Integer has to be defined as int16 etc… I would let an mixed group of engineers evaluate the new programming language

  2. Ron Amundson says:

    I expected my guys to put in at least 100 hrs a year on professional development, some of it on the companies dime, some on their own. If an engineer is not personally investing in their continuing ed, they will get left behind one way or another.

    As far as making the call, an engineering manager should build in some level of pioneer time during planning stages. Such calls come up on nearly every project… it is errant planning not to set aside at least a portion of the project timelime for such.

    Cash cowing the engineering staff via dumping all pioneer time to their personal hours makes for high turnover and low morale, even more so if the pioneer change/skill set is not fungible across a sector.

  3. [...] past blog posts (here and here), I discussed change in the high-tech design workplace.  Today’s blog is about [...]

Leave a Reply