What are the key traits I should look for in a potential Chief Engineer?


Originally published in February 2017 at The Lean Post

What are the key traits I should look for in a potential Chief Engineer?

The answer to that question depends on what your expectations are for a chief engineer:

  • Do you want someone with deep technical expertise in a domain, as the term is commonly used in many organizations?
  • Do you want a system integrator, which is more in line with the role as practiced within lean product and process development?
  • Do you want someone that deeply understands what the product must be, which is also in alignment with the role as practiced within lean product and process development?

Even more important to ask: Why do you want a chief engineer? What problem(s) will a chief engineer solve for your organization?

The chief engineer as practiced within lean product and process development (LPPD) is a countermeasure to problems that are both inherent to developing products and to the organizational design in which it is used.

For example, the fundamental purpose of product development is to develop a product that customers will value, which is likely solving a problem the customer has. And in most organizations this needs to be done profitably. The chief engineer system is a key part of understanding what the product needs to be for the customer and the business.

The chief engineer system is also a countermeasure to problems that occur in companies that are organized functionally. Functional organizations can be great at developing deep technical expertise. But they also run the risk of contributing to sub-optimized products if each function optimizes within their function. You could have the best technical design, but if it can’t be manufactured or sold profitably those are major problems for the product and organization.

To overcome the problems inherent in a functional organization, another common organizational approach is to organize around the product. This organizational structure can be effective for cross-functional collaboration and optimization at the product level, but often results in a lack of focus on developing deep technical expertise. The problems this causes become more evident as years go by.

Organizations sometimes flip back and forth between being organized by function and by product as each organizational structure solves the problems of the other one. The chief engineer system is one approach to get both the benefits of deep technical expertise within functions and optimizing the product to meet the customer and business needs. The chief engineer system might be the right approach for your organization, but have you considered others?

In the chief engineer system, as typically used in LPPD, the organization is organized functionally. The chief engineer, with support from a small team, has full responsibility for the success or failure of the product. This doesn’t just include development, but ultimately the profit and loss for the product and everything else that encompasses as well.

In this system the chief engineer has full responsibility without authority over most people working on the product. Each function’s role is to support the chief engineer to be successful and to develop people’s technical expertise within the function. In this system the fit between the chief engineer and the rest of the organization is what is important for success. If you have a mature functional organization experienced in working this way with a new, inexperienced chief engineer, the functional leaders can help develop and support the chief engineer to be successful.

And then there is the organizational-change aspect to consider. Organizations are a collection of people and both individuals and the organization are or should be constantly changing – hopefully growing. When you make a change in one part of the organization, the rest of the organization reacts to it. If you introduce a chief engineer into your current organization, how will the rest of the organization respond? How do you want the rest of the organization to respond?

Mutual trust and respect between the chief engineer and the rest of the organization are a good starting point to set the conditions for success. What other traits are needed to get engagement and support to make the product successful with no authority? And given your current organization and what you expect a chief engineer to do within it, what are the key traits that individual needs to be successful?

,