The responsible engineer (RE) model is a method of engineering large systems. It has been implemented in most of the aerospace startups I have been a part of. While the specific implementation may vary from company to company or even team to team, the RE model generally follows principles similar to those in “extreme ownership”. The idea is that each part/component of a large system should have one owner and point of contact called the responsible engineer. They are end-to-end responsible for the successful engineering, test, and operations of whatever they are the RE of, and thus should have total authority of all decisions on said component in the system.

The RE model really excels with motivating folks to care about their components. Folks take a sense of pride in making sure their systems work as they should, and are designed and manufactured on time. The model makes sure there is someone looking out for each subsystem as appropriate. People naturally view designs through the perspective of the systems they are the RE of, helping surface concerns that otherwise might not be thought about. The model also gives a concrete point of contact to go to when system changes may impact a subsystem. With the signoff of the appropriate REs, it is very easy to make system level changes without the back and forth that might otherwise exist. Different engineers may have different opinions if a change or risk is acceptable, and ultimately having a single point of contact makes sure that a risk is understood by the most knowledgeable engineer.

The drawbacks of the RE model are the natural consequences of what it excels at. While REs take pride in their specific systems, they often care less about other systems. If there are 5 propulsion engineers, there is less incentive for the 4 REs to help the 1 struggling RE who may be on tighter deadlines, given they aren’t responsible for said component. Likewise, since folks tend to be judged on the work they are the RE over, the model fails when you have highly variable workloads through the design cycle. One component may need more engineers and time in early design, while a different component may need more eyes during testing. The platonic RE model would have a single RE for each component, slowing down potential dev time. On a similar vein, if a RE is on vacation there is naturally less knowledge about said system given cross training conflicts with the idea of “one engineer for one component”. Different REs are also different engineers, and ultimately think differently on acceptable risk within their subsystems. In engineering and especially aerospace a system is only as functional as its weakest link. If one engineer accepts more risk to their component than everyone else, they are ultimately shifting the risk posture of the entire system.

The other issue of the RE model lies with “puppet REs”. REs are expected to have full decision making authority over their system, but in practice this hardly happens. An RE without the decision making authority to execute their engineering design is hardly an RE. Rather than the RE model being a tool to enable agile design, it becomes a system of who to shift blame to. In a toxic environment, REs might try to negotiate requirements not to maximize the benefit of the system, but to minimize the probability that their particular subsystem is at fault. Ultimately systems only succeed or fail together, and so REs need both the authority to have real ownership of their component, as well as the higher level picture to optimize for the entire system. Aerospace systems should not be designed by one system engineer overseeing the project, but equally dangerous is a tribal system rather than a unified design.