A few days ago, I came across a very interesting blog post over at engineering.com that details out a Day in the Life of an Automotive Design Engineer by Pawl Bearing. Besides being a somewhat funny and perhaps scary read, I think its fascinating because it seems like a realistic view into the day to day life of an engineer. Here’s some of the highlights:

  • Reviewing a new circuit board design
  • Identifying a ‘substitute’ for a part that has too long of a lead time for the schedule, but assessing the tradeoffs along the way and forcing the supplier to run stress tests
  • Providing from-the-hip estimates on time to first prototype on a new project the company just won
  • Taking over a project from an engineer that quit several weeks ago and dealing the angry customer
  • Submitting a PO request for testing on the new circuit board design
  • Attending the weekly engineering meeting
  • Interviewing a fresh-out-of-school engineering candidate
  • Head to the lab to take a look at a failed component
  • Responding to an angry customer who’s product is now failing
  • Work with accounting to make sure to use the right cost center number on POs

Obviously, this guy is pretty busy. But what really strikes me about this sequence of events is how this design engineer is interacting with just about every functional organization within the company including purchasing, testing, quality, accounting, human resources as well as customers and suppliers. That’s when a thought struck me: engineers truly do have enterprise wide responsibilities because they are working the entire lifecycle of the product.

With that in mind, I started to think about other functional roles. While at Aberdeen, I led a research group composed of research practices that each of focused on different departments. I got to read a lot of great studies and gain insight into what each is trying to accomplish. Here’s a rundown of what some other organizations responsibilities are and their goals in terms of metrics and measureables.

  • Purchasing: The responsibilities of this organization basically span the source-to-settle cycle. That includes running bid processes, executing PO delivery and then payment. Key metrics used to measure success are spend under management and savings.
  • Production: This department really gets started with the design release event and ends when the product leaves the production facility. Critical measures here include return on net assets (RONA), health and safety compliance and quality metrics.
  • Service: This organization is really focused on supporting products once they are in operation which starts once they are delivered. Key metrics include % of first time issue resolution, % of self-service resolved and similar measures.

In comparison to these other organizations, the scope and range of the responsibilities of engineering is unusual. By and large, engineering is just about the only department that must support and address the entire lifecycle of the product. that implies sometimes switching between wildly different lifecycle phases. But beyond that, they are in a position that no one else in the company is with respect to that product. No one must traverse the processes of all the other organizations like an engineer. No one else acts as the hinge point to help resolve issues in those processes like an engineer. No one else in the company engages and interacts with more stakeholders than an engineer. And there’s some interesting implications as a result

Are highly skilled engineers a key to running smoother and more efficient enterprise operations?

Because engineers know how the company gets work done more than anyone else, are they in a better position to take on executive leadership positions?

What are your thoughts? Do engineers truly have the broadest reach within the enterprise? Would engineers make better executives? Sound off. Let us know what you think.

Take care. Talk soon. And thanks for reading.