Elon Musk: Elon Musk's 5 steps to moving fast. The importance of simplification before automation.
If you are a space enthusiast and have two hours to spare, you can watch the entire walking interview of Elon Musk by Tim Dodd (aka the Everyday Astronaut) as he walks through the SpaceX Spaceport in Boca Chica Texas (see the links at the end of the article for the three-part video interview). What Elon is eager to share is not just the nuts and bolts of what his team has accomplished, but the principles they've learned along the way.
Embedded in the discussion of rockets, boosters, ceramic tiles, and a few side excursions into Tesla production war stories, Musk shares the five steps to rapid innovation - and some of the painful experiences when he departed from his rules. As important as the steps are, the order of the steps is even more critical:
1. make your requirements less dumb
2. delete requirements often.
3. simplify or optimize
4. accelerate cycle time (but not before doing the first 3 steps)
5. automate
Below is a summary of the rules and some of the insights about how Musk has applied them to his businesses and some of the hard lessons learned when he did not fully appreciate these principles.
1.Make Your Requirements Less Dumb
Rapid progress is possible when we accept that all requirements are wrong; some are less so. The humility to accept that we know very little is a critical mindset to adopt to make progress. An interesting observation Musk makes is that "It's particularly dangerous if a smart person gave you the requirements." Why? "Because you might not question them enough." Think about this in light of the frequent situation where the HiPPO (highest paid person in the organization) is calling the shots. An important part of evaluating a requirement is that "requirements must come with a name...not a department." By this, he means the name of a real person - a human being - who can agree with, defend and take accountability for a requirement. "You can't ask a department, you have to ask a person."
What Musk is describing is the opposite of the bureaucratic mindset that cripples innovation in many companies and spawns systems that are too complex to effectively innovate. Technical debt, monolithic systems, exponential increases in testing complexity and instability combined with rigidity of key systems are some of the creeping symptoms.
More about this below.
2. Delete Requirements Often.
Questioning requirements necessarily means deleting requirements - often. This means the aim of questioning requirements is not just about making them better, but eliminating them altogether as often as possible. How do you know you are doing this as rigorously as possible? Musk says for requirements or process steps that have been removed, "if you're not adding things back in at least 10% of the time, you're clearly not deleting enough."
How frequently are you removing requirements, process steps, or parts? Are you doing it so rigorously you occasionally have to add back something you removed? What percentage of the time do you realize you over-simplified and have to add something back? Is it 10%?
3. Simplify or Optimize. (But not before doing the first two steps)
Musk does not have a lot to say here, except that the natural inclination is to start optimizing or simplifying a broken or unnecessary process or part. "The most common error of a smart engineer, " Musk says, "is to optimize the thing that should not exist. Everyone is basically, without knowing it, got a mental straight jacket on. That is they'll work on optimizing the things that should simply not exist." How much progress is impeded by people working on things that do not matter? A lot.
An insight on simplifying: Musk mentions that a common mistake is leaving testing functionality and processes in a production system once it has achieved a steady state. During initial production, the process must be heavily measured and instrumented to catch and remediate defects and inconsistencies. Once the vast majority of bugs have been resolved, leaving in unnecessary testing slows down production speed, and interestingly, generates waste through false positives, which sometimes results in remediations that do more harm than good. While Musk's example (see below) is from the 'production hell' phase of the Model 3 rollout, his example has broader applicability. In the software world, a common mistake is leaving in code used for testing and measurement that slows production code, making it more complex to understand and modify. His suggestion is to remove testing that is no longer needed and only add it back when post-production testing identifies issues (and remove excess testing steps/processes once problems have been resolved).
4. Accelerate cycle time
You can always move faster, Musk says. "You're moving too slowly, go faster, but don't go faster until you've worked on the other three things first." If you are just digging a hole faster, you are digging your own grave.
5. Automate
"Automate" is certainly the most viscerally exciting step, and whether it be APIs, robots, intelligent automation, AI, the adoption of low/no-code technologies, the software, hardware options are ever-increasing. There is something we love about watching robots weld, or RPA systems take over a manual, repetitive process. The pitfall is when we do the steps in reverse order - automating a broken, or unnecessary process. This is a mistake Musk painfully admits, he has done many times. The worst approach of all is to do the steps in reverse. "I have personally made the mistake, of going backwards on all five steps multiple times." Musk says, "so I have to repeat this point."
Below is a short vignette Musk shares about a Model 3 production bottleneck that singlehandedly compromised the Model 3 production volumes, leading to a huge hit in the share price in 2018 following a quarterly earnings review meeting.
The tale of the 'flufferbot'
Elon illustrates the perils of doing the steps in reverse with an illustration from the Tesla Model 3 during the initial 'production hell' phase. Engineers had specified that a fiberglass mat insulate the battery pack from the hermetically sealed casing that enveloped it. The image to the right is from an eBay listing of a used fiberglass pulled from a salvaged Model 3. To keep pace, Musk invested in a 'flufferbot" (note: Musk's term, not mine) robot designed to lift the lightweight blanket and place it on top of the battery.
Getting the robot to accurately place the mat became an intractable problem: sometimes the robot could not grab the mat properly, other times it piled up the material off-center. Finally, in exasperation after weeks of work, Musk asked what the mat was for. "Fire prevention," one set of engineers said. Others said "sound dampening." Neither the fire prevention nor noise vibration analysis teams agreed, however. Each said the mat was a requirement of the other team. With fire prevention ruled out, Musk had a test version of the Model 3 developed without the mat: extensive measurement with microphones and measurement equipment found no difference in noise or vibration in the Model 3, with or without the mat.
"Literally it was like being in a Rube Goldberg cartoon...So we just deleted them and just bypassed this $2 million robot cell as a complete pile of nonsense." Musk said.
"Automating was a mistake, then accelerating was a mistake, then optimizing was a mistake." - Elon Musk
Of course, innovation isn't only about simplification. It is also about setting optimistic, and aggressive goals, questioning the status quo, and focusing on the right things at the right time. It's also about being humble, and receptive to the facts. Quite possibly a sense of humor comes in handy as well:
Link to Tim Dodd's two-hour walking video interview with Elon Musk:
Part 1: https://www.youtube.com/watch?v=t705r8ICkRw
Part 2: https://www.youtube.com/watch?v=SA8ZBJWo73E&t=229s
Part 3: https://www.youtube.com/watch?v=9Zlnbs-NBUI
VP, Program & Prod Mgmt @ Mutual of America Financial Group | Agile Transformation, Product Management
3 年If you can't do it using Excel, how do expect hardware or software to do it in an automated fashion.
Business Transformation @ EspriGas | Analytics | Process Improvement
3 年Great summary, John- I can sometimes overengineer requirements so this is good to keep in the back of my head- thanks