Why should you have a Chief Engineer?
I’ve had conversations with numerous advisory clients this year about the role of the Chief Engineer. To be clear, I don’t generally advocate that an organization install this role. It is heralded in the lean product development community as a key aspect of such a transformation. Other than having clear roles, I have always believed that there is no “right” organizational design, and any problem that you can solve with reorganizing can also be solved with changes to process, culture, or capabilities. That being said, there are benefits of having a Chief Engineer (not the best description of the role), sometimes also referred to as an Entrepreneur System Designer (personally I think this title is much worse), which are harder to solve any other way. I went looking for a good article which described the benefits of the Chief Engineer, and not finding anything satisfactory, I wrote it up myself.
Drive Systems or Portfolio Improvements (or “Seeing the Forest for the Trees”)
Who owns the “how” of product development? An end-to-end process that integrates engineering, marketing, sales, manufacturing, sourcing, financing, etc. needs someone looking across the whole of that work. Who can see the end-to-end improvements that are needed? Who is more vested in the end-to-end success, more so than their functional preservation? This wide-aperture view is critical to driving the kinds of improvements that are needed to really improve product development, including most of the typical solutions promoted within lean product development.
This is also true at the portfolio level. How can you leverage the whole portfolio better? No one product owner, financial planner, or project manager wants to add risk to their project unless it is necessary to win, but shifting risk across programs might be the best thing to do for the portfolio, and Chief Engineers, who should be looking more broadly and long-term than others, are well suited for pushing for such changes.
Trade-off and Risk-based Decision Making
Is the proposed technical solution really feasible? Does the customer really care about that one feature or performance variable? Is the extra cost really worth it? These are hard enough questions. What happens when you have answered all three questions in a single decision. When properly developed, Chief Engineers can view across this breadth of decision making, understand enough what they need, as well as what they need to rely on others for, and ultimately make sound and well-balanced decisions.
When organizations lack that ability, the primary method of making such trade-off decisions involves traditional organizational power, and not sound trade-off management. For example, if the power is centered in finance, then the financial model is locked and engineering and marketing must push throughout without all the options they might desire. Perhaps worse is when the decision drags out much longer than it should be because the various parties can’t agree on how the decision should be made.
Because each function can understand their position with great depth and rigor, positions become entrenched and lack the perspective of the big picture. The Chief Engineer cuts through all of that. When ideally situated, the Chief Engineer not only doesn’t report to any of those functions, either literally or culturally, and speaks on the behavior of the customer and the project. They understand all perspectives and are able to make balanced decisions quickly that take into account all the variables, managing objectives versus the risk to the customer or business.
A lot of this work is done by looking at the systems, and being a master of the system-level of the product being designed. Coaching and teaching people at the system-level helps everyone better understand what they are designing, and how their sub-system, element, or feature integrates into the whole. Much of this work is done at integrating events, which are not reviews or controls but where real work is done. If the Chief Engineer owns any meetings, this should be central, as it is influencing the design through coaching as well as decision making.
Above the fray, managing abnormal conditions
The entire product development process is one big problem-solving challenge, trying to close the gap between what you currently offer, and what the market really wants. The daily, normal, work of product development is hard enough and requires focus. When problems occur that are abnormal to the normal flow of product development, the first challenge is that it’s difficult to determine whether it’s abnormal or just the normal friction of trying to bring a product to fruition. The natural instinct is just to push through because no matter what you do, there’s always more work to be done.
Some problems are abnormal. They require extra attention, or they require extra time, or they require a broader perspective, or a special skill. First, while we do our best to design our work to determine abnormal from normal, especially when it comes to technical challenges and evaluation of risk, sometimes experienced instinct is called for to determine abnormal from normal.
Second, it then requires some leadership to ensure the abnormal conditions receive their due attention. That might require the Chief Engineer to solve the problem, to lead others in problem-solving, or to coach others in problem-solving. But it is vital that the abnormal condition does not just get swept up into the normal body of work and forgotten about.
Developing Chief Engineers
If this role sounds like a difficult one, it very much is difficult. This is why most organizations shy away from it or implement half-measures in the general direction of Chief Engineers.
Here’s the change challenge…Do you begin developing Chief Engineers, so that 10 years later you can launch the role? Or do you launch the role, and that forces you to more deliberately develop people to the Chief Engineer role? There isn’t likely a right answer, as it might depend on things like your company culture and average turnover. But there is no doubt this is a formidable role and requires a special person to perform it. This is perhaps why people get stuck on the decision making power of the Chief Engineer, or lack thereof, thinking that the title is the power. In practice, I believe that because it is such a hard job, the respect for the person capable of the role is so clear, that the “respect” is what carries the power.
This comes largely as the intrinsic motivation of the Chief Engineer is master of their craft. A well-performing product, both in technical and market terms, is nothing more than a measure of that master. That pursuit of excellence helps develop a culture throughout the product development community and becomes the basis of the Chief Engineer being an effective coach and mentor to those throughout the organization.
To be clear, you can have Lean Product Development, and successful product development, without implementing Chief Engineers. However, they do serve a role, and when done well, a very useful role.