Automate (But Automate Last)

Besides black art, there is only automation and mechanization. — Federico García Lorca

In 2018, Musk was trying to ramp up production in his Tesla Fremont factory from 2,000 to 5,000. He revisited every process and system, cutting corners wherever he could (and sometimes removing one too many bolts). Quality (of product and of life) might have decreased in the factory, but they eventually hit their goal. One of the more surprising tactics to increase production was removing automation. For a company that distinguished itself on its automation, it was able to dial back some of it to move faster. Here’s the last Musk principle from his manufacturing and management “algorithm”:

5. Automate. That comes last. The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and the bugs were shaken out.

Optimization is fragile. How many times a task will be done (not a question on the factory floor) is not the only input to whether or not to automate. Before a process is fully defined, the automation calculus might not work out. Tasks you don’t understand can’t be automated (obvious, but not in practice). Tasks that shouldn’t exist shouldn’t be automated (again, obvious, but not in practice). Tasks that are low-leverage should be automated last (focus on the highest-leverage tasks first). In a world of bits, we don’t have to worry about space or cost constraints — code doesn’t take up any space, and cost is usually not a concern. In the world of atoms, space and time are real.

The full Musk manufacturing and management “algorithm.”

1. Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from “the legal department” or “the safety department.” You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.

2. Delete any part or process you can. You may have to add them back later. In fact, if you do not end up adding back at least 10% of them, then you didn’t delete enough.

3. Simplify and optimize. This should come after step two. A common mistake is to simplify and optimize a part or a process that should not exist.

4. Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps. In the Tesla factory, I mistakenly spent a lot of time accelerating processes that I later realized should have been deleted

5. Automate. That comes last. The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and the bugs were shaken out.