The five-step process:

First, make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you.

In fact, it's particularly dangerous if a smart person gave you the requirements, because you might not question them enough. Everyone is wrong some of the time, no matter who you are. So the first step is to make your requirements less dumb.

Second, try very hard to delete the part or process. This is extremely important. If you're not occasionally adding things back in, then you're not deleting enough. The bias is almost always toward adding a part, a process, or a step "just in case we need it."

You can make "just in case" arguments for almost anything.

For a rocket, especially one trying to become the first fully reusable rocket—a thing that has never existed before—you have to be ruthless about deleting parts and processes. You can't hedge every risk forever. For example, on Starship, the grid fins do not fold down. Folding would require an entire additional mechanism that simply isn't necessary.

Any requirement or constraint must come with a name, not a department. You can't question a department; you can only question a person. The individual proposing the requirement must be willing to take responsibility for it. Otherwise you end up following a requirement that some intern casually suggested two years ago, who doesn't even work at the company anymore. These things are often much sillier than people imagine.

So:

Step 1: Make the requirements less dumb.

Step 2: Delete the part or process.

If you're not adding things back roughly 10% of the time, you're clearly not deleting enough.

Only then comes Step 3: Simplify or optimize.

This ordering matters because one of the most common mistakes smart engineers make is optimizing something that should not exist in the first place.

People are trained throughout school to answer the question they are given. You can't tell your professor, "Your question is dumb." You'll get a bad grade. So everyone develops this habit of solving the assigned problem rather than questioning whether the problem itself should exist.

Without realizing it, people end up in a mental straitjacket, spending enormous effort optimizing things that should simply be removed.

Step 4 is accelerate cycle time.

You're probably moving too slowly. Go faster. But don't accelerate until you've done the first three steps. You can almost always make something go faster.

Finally, Step 5: Automate.

I have personally made the mistake of doing all five steps backwards multiple times. I've literally automated, accelerated, simplified, and only afterward deleted.

One example was during Model 3 production. There were five fiberglass mats located between the floor pan and the battery pack. At one point they became a bottleneck on the battery production line, and that bottleneck was affecting the entire Model 3 program.

I was basically living on the battery-pack production line trying to fix it. My first mistake was trying to improve the automation. I thought, "Let's make the robot better." That was a mistake. Then I tried accelerating the process. That was a mistake. Then I tried optimizing the process. That was also a mistake. Finally I asked, "What the hell are these mats actually for?"

I asked the battery safety team whether they were for fire protection. They said no—they were for noise and vibration. Then I asked the NVH (Noise, Vibration, Harshness) team what they were for. They said they were for fire safety. At that point it felt like I was living inside a Dilbert cartoon. Frankly, I feel that way fairly often. So we tested it. We built one car with the fiberglass mats and another without them. We put microphones in both vehicles and tried to determine whether there was any measurable difference. There wasn't. In fact, I couldn't even tell which was which.

So we deleted the mats entirely. That decision bypassed a $2 million robot cell and eliminated a problem that never should have existed in the first place. That's the lesson:

• Question the requirement.

• Delete before you optimize.

• Optimize before you accelerate.

• Accelerate before you automate.

And be aware that even experienced engineers constantly get this order wrong.

这个五步流程是这样的。

第一步，先让需求变得没那么蠢（Make your requirements less dumb）。

你的需求一定有问题。不管是谁提出来的，都一样。如果需求是一个聪明人提出来的，反而更危险，因为你可能不敢质疑它。事实上，每个人都会犯错，无论你是谁。所以第一步永远是先审视需求本身，看看它到底合不合理。

第二步，尽最大努力删除零件、流程或步骤（Delete the part or process）。

这一点极其重要。如果你从来不会出现“删掉之后又加回来”的情况，那说明你删得还不够狠。绝大多数组织天然倾向于不断增加东西——增加一个零件、增加一道流程、增加一个审批步骤。理由通常都是：

“万一以后需要呢？”

但这种“以防万一”的理由几乎可以为任何东西辩护。

以火箭为例。我们做的是历史上第一个完全可重复使用的火箭，这是航天领域长期追求的圣杯。在这种情况下，你必须拼命删除不必要的东西，而不是不断给自己留后路。例如 Starship 的格栅翼（grid fins）并不会折叠。因为折叠意味着额外增加一整套机械结构，而我们根本不需要它。

还有一个原则：任何需求或约束条件，都必须对应到一个具体的人，而不是一个部门。因为你无法质问一个部门，你只能质问一个人。提出这个需求的人，必须愿意对它负责。否则公司里经常会出现这样的情况：某个约束条件源于两年前某个实习生随口提出的一句话，而那个人早就离职了，但这个约束却还在被所有人当成圣旨执行。这种事情比你想象得常见得多。

所以：

第一步，质疑需求，让需求变得没那么蠢。

第二步，删除零件、流程和步骤。

如果删完以后从来不需要加回来，那么说明你还没有删到位。大约有 10% 的情况需要加回来，才算删得够狠。

第三步，才是简化和优化（Simplify or Optimize）。

顺序非常重要。聪明工程师最常见的错误，就是优化一个本来就不应该存在的东西。

从小学到大学，所有教育都在训练你回答问题，而不是质疑问题。老师出了一道题，你不能告诉老师：“你的题目本身就有问题。”

否则你会拿低分。久而久之，人们形成了一种思维惯性：默认问题一定是正确的，然后拼命去寻找最优解。结果就是大家被套上了一个无形的思维枷锁，把大量精力浪费在优化那些本来就应该被删除的东西上。

第四步，加快迭代速度（Accelerate cycle time）。

大多数时候，你只是推进得太慢了。加快速度，但一定要先完成前面三步。因为无论什么事情，几乎总能找到办法让它跑得更快。

第五步，自动化（Automate）。

而我自己犯过很多次错误——几乎是把这五步完全倒过来做。我曾经自动化、加速、优化了一大堆东西，最后才发现它们根本不该存在。举个例子。

Model 3 电池包顶部曾经有五块玻璃纤维垫，位于电池包和车身底板之间。有一段时间，这几块垫子成了整个电池生产线的瓶颈，而电池生产线又卡住了整个 Model 3 项目。当时我几乎天天待在生产线上，试图解决问题。

我做的第一件事，是改进自动化设备。错了；
然后我尝试提高生产速度。还是错了；
接着我开始优化整个流程。依然错了；
最后我终于问了一句：这几个垫子到底是干什么用的？
我去问电池安全团队：这是为了防火吗？他们回答：不是，这是为了降噪和减振。
于是我又去问 NVH（噪音、振动与舒适性）团队：这些垫子是干什么的？他们回答：为了防火。

整个场面就像《Dilbert》漫画一样荒谬。说实话，我经常有这种感觉。于是我们决定直接测试。造两辆车，一辆有这些垫子，一辆没有。在车里放上麦克风，看看能不能测出差异。结果完全测不出来。甚至我自己都分辨不出哪辆有、哪辆没有。于是我们直接把这五块垫子删掉了。一个价值两百万美元的机器人工作站也因此不再需要。而这一切问题，从一开始就不应该存在。

这就是整个五步法的核心：

• 先质疑需求
• 删除，然后才优化。
• 优化之后再加速。
• 最后才自动化。

而现实里，即便是经验丰富的工程师，也会一遍又一遍地把这个顺序搞反。

我发现我最喜欢犯“just in case we need it”这个错。然后就是无休止的 optimize a thing that should not exist

via