Understanding Elon Musk's Engineering Methods

In my life before EVANNEX, I was heavily involved in software engineering process design and implementation. One of my friends and colleagues during that time was Tom Gilb—a well-known author and consultant who specializes in evolutionary systems and software development processes. He is the creator of Planguage— a general-purpose, systems engineering planning language. Tom has a deep understanding of why some engineering processes succeed and others fail.  

Above: Elon Musk (Flickr: OnInnovation)

Over the past few years, Tom has become fascinated with Elon Musk’s engineering philosophy, summarized in the steps described at the Everyday Astronaut website (extracted below):

1. Make the requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you. He notes that it’s particularly dangerous if an intelligent person gives you the requirements, as you may not question the requirements enough. “Everyone’s wrong. No matter who you are, everyone is wrong some of the time.” He further notes that “all designs are wrong, it’s just a matter of how wrong.”
2. Try very hard to delete the part or process. If parts are not being added back into the design at least 10% of the time, not enough parts are being deleted. Musk noted that the bias tends to be very strongly toward “let’s add this part or process step in case we need it.” Additionally, each required part and process must come from a name, not a department, as a department cannot be asked why a requirement exists, but a person can.
3. Simplify and optimize the design. This is step three as the most common error of a smart engineer is to optimize something that should not exist.
4. Accelerate cycle time. Musk states “you’re moving too slowly, go faster! But don’t go faster until you’ve worked on the other three things first.”
5. Automate. An important part of this is to remove in-process testing after the problems have been diagnosed; if a product is reaching the end of a production line with a high acceptance rate, there is no need for in-process testing.

Additionally, Musk believes everyone should be a “chief engineer.” Engineers need to understand the system at a high level to understand when they are making an “optimization” that affects a system negatively or fails to consider other system elements that may be more important. As an example, Musk [discussing SpaceX design challenges] noted that an order of magnitude more time has been spent reducing engine mass than reducing residual propellant, despite both being equally as important.

Tom Gilb worries that this formulation of Elon’s approach might lead to oversimplification and/or misunderstanding, so he has reformulated and expanded on it. He writes: 

Let me attempt a reformulation, hoping to increase clarity of Musk’s intent.

1. DYNAMIC. CRITICAL REQUIREMENTS: State really-critical requirements only, and be prepared to learn quickly, about even-smarter requirements. Get rid of ‘dumb’ ones. 

2. DYNAMIC DESIGN PRIORITIZATION: Resist keeping designs, that are not clearly justified and prioritized by means of cost-effectiveness, in terms of their impacts on our requirements.

3. DYNAMIC DESIGN OPTIMIZATION: Keep continuous motivation to challenge existing designs, and to improve design cost-effectiveness, using new technology, using feedback from iterations, and using revised requirements.

4. ACCELERATE: Speed up repetitive processes, by re-design, by paralleling, automation, feedback, and relaxing unnecessary requirements.

5. AUTOMATE: Automate processes with high automation payoff, and avoid bad automation.

Tom expands on these comments and has more to say about Elon’s methods and system engineering in general.  For further information, visit: https://www.gilb.com/competitive-engineering.

===

Written by: EVANNEX Founder Roger Pressman