Whenever one of his engineers cited “a requirement” as a reason for doing something, Musk would grill them: Who made that requirement? And answering “The military” or “The legal department” was not good enough. Musk would insist that they know the name of the actual person who made that requirement.
“If you set an aggressive schedule that people think they might be able to make, they will try to put out extra effort,” [Mueller] says. “But if you give them a schedule that’s physically impossible, engineers aren’t stupid. You’ve demoralized them. It’s Elon’s biggest weakness.”
“It’s not the product that leads to success. It’s the ability to make the product efficiently. It’s about building the machine that builds the machine. In other words, how do you design the factory?”
“At other places I’ve worked,” von Holzhausen says, “there was this throw-it-over-the-fence mentality, where a designer would have an idea and then send it to an engineer, who sat in a different building or in a different country.” Musk put engineers and designers in the same room. “The vision was that we could create designers who thought like engineers and engineers who thought like designers.”
“The important thing with Elon is that if you told him the risks and showed him the engineering data, he would make a quick assessment and let the responsibility shift from your shoulders to his.”
He called Steve Davis, a trusted engineer at SpaceX. It was 2 a.m. in California, but Davis agreed to study ways to build tunnels quickly and inexpensively. “Okay,” Musk said, “I will call you back in three hours.”
How can we move faster? What are the impediments? “He spent a lot of time giving us lessons about the importance of deleting steps and simplifying.”
“Step one should be to question the requirements,” [Musk] says. “Make them less wrong and dumb, because all requirements are somewhat wrong and dumb. And then delete, delete, delete.”
When Musk was asked why the caps existed, he was told they had been specified to make sure the pins did not get bent. “Who specified that requirement?” he asked. The factory team scrambled to find out, but they weren’t able to come up with a name. “So delete them,” Musk said. They did, and it turned out they never had a problem with bent pins.
Always wait till the end of designing a process—after you have questioned all the requirements and deleted unnecessary parts—before you introduce automation.
At a meeting at the Fremont factory on May 22, [Musk] recounted a story about World War II. When the government needed to rush the making of bombers, it set up production lines in the parking lots of the aerospace companies in California. He discussed the idea with Jerome Guillen, whom he would soon promote to being Tesla’s president of automotive, and they decided that they could do something similar.
The Algorithm
- 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 the 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.
- 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.
- Simplify and optimize. This should come after step two. A common mistake is to simplify and optimize a part or process that should not exist.
- 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.
- Automate. Tha 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.
Expectations for Managers and Other Maxims
- All technical managers must have hands-on experience. For example, managers of software teams must spend at least 20% of their time coding. Solar roof managers must spend time on the roofs doing installations. Otherwise, they are like a cavalry leader who can’t ride a horse or a general who can’t use a sword.
- Comradery is dangerous. It makes it hard for people to challenge each other’s work. There is a tendency to not want to throw a colleague under the bus. That needs to be avoided.
- It’s OK to be wrong. Just don’t be confident and wrong.
- Never ask your troops to do something that you’re not willing to do.
- Whenever there are problems to solve, don’t just meet with your managers. Do a skip level, where you meet with the level right below your managers.
- When hiring, look for people with the right attitude. Skills can be taught. Attitude changes require a brain transplant.
- A maniacal sense of urgency is our operating principle.
- The only rules are the ones dictated by the laws of physics. Everything else is a recommendation.
Bezos was methodical. His motto was “gradatim ferociter,” or “Step by step, ferociously.” Musk’s instinct was to push and surge and drive people toward insane deadlines, even if it meant taking risks.
“Does it have a chance of success above zero? If so, put it in!”
“But there’s something else I’ve found this year. It’s that fighting to survive keeps you going for quite a while. When you are no longer in survive-or-die mode, it’s not that easy to get motivated every day.”
When most clients are given three or four options, they will ask which one the banker recommends. Musk, instead, asked detailed questions about each option but did not solicit a recommendation. He liked to make his own decision.
The moderator asked what advice he would give to someone who wanted to be the next Elon Musk. “I’d be careful what you wish for,” he replied. “I’m not sure how many people would actually like to be me. The amount that I torture myself is next level, frankly.”
“I have a great idea,” he said. “We’re flipping it. Don’t make the choice opt-out. Instead, make it opt-in. We want to make it sound like the Shackleton expedition. We want people who declare they are hardcore.”
SpaceX and Tesla were successful because Musk relentlessly pushed his teams to be scrappier, more nimble, and to launch fire-drill surges that extruded all obstacles.
One of his maxims was that you should never use a cruise missile to kill a fly; just use a flyswatter. Was using a neural network to plan paths an unnecessarily complicated way to deal with a few very unlikely edge cases?
“This is how civilizations decline. They quit taking risks. And when they quit taking risks, their arteries harden. Every year there are more referees and fewer doers.” That’s why America could no longer build things like high-speed rail or rockets that go to the moon.
“When you’ve had success for too long, you lose the desire to take risks.”
As Shakespeare teaches us, all heroes have flaws, some tragic, some conquered, and those we cast as villains can be complex. Even the best people, he wrote, are “molded out of faults.”
But would a restrained Musk accomplish as much as a Musk unbound? Is being unfiltered and untethered integral to who he is? Could you get the rockets to orbit or the transition to electric vehicles without accepting all aspects of him, hinged and unhinged? Sometimes great innovators are risk-seeking man-children who resist potty training. They can be reckless, cringeworthy, sometimes even toxic. They can also be crazy. Crazy enough to think they can change the world.