Elon Musk is possibly the best engineer and entrepreneur of all time, and he has some insights into the most common errors smart engineers make.
In a dated interview, Musk, the visionary behind Tesla, SpaceX, and now X (formerly Twitter), once offered a compelling perspective on a pervasive issue among bright engineers. His remarks highlighted a fundamental flaw in engineering thinking, one often rooted in the very education system that trains these professionals. He presented a clear, albeit unconventional, five-step process for effective engineering. What’s particularly interesting is how Musk’s recent restructuring and rebranding of Twitter seems to reflect this very philosophy, emphasizing a rapid, iterative approach to product development.

“The most common error of a smart engineer is to optimize a thing that should not exist,” Musk says. This, he argues, stems from a deeply ingrained habit of convergent thinking, instilled by the traditional academic structure.
“Why would people (work to optimize something that shouldn’t exist)?” Musk asked rhetorically. “Well, everyone’s been trained in high school and college that you’ve got to answer the question. So you can tell a professor your question is done. You have to *answer* some questions. So everyone’s basically, without knowing it, they’ve got a mental straitjacket on. They’ll work on optimizing the thing that should simply not exist.”
His solution? To question the question itself. “Just make your requirements less dumb. Your requirements *are* definitely dumb. It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements. You might not question them enough. No matter who you are, everyone’s wrong some of the time,” Musk says.
He continues by outlining the key steps engineers should follow: “Then, try very hard to delete the part or process. This is actually very important. If you’re not patiently adding things back in, you’re not deleting enough. The bias tends to be very strongly towards, ‘Let’s add this part or process step in case we need it.’ But you can basically make ‘in case’ arguments for so many things.”
Only once the requirements have been questioned and appropriate parts removed does optimization come into play. “Only the third step is simplify or optimize,” Musk says.
The final two steps in Musk’s framework emphasize speed and automation. “The fourth step is to accelerate cycle time. You’re moving too slowly. Go faster. But don’t go faster until you’ve worked on the other three things first. And then the final step is automate.”
Musk says he learnt his framework through trial and error. “Multiple times I automated, accelerated, simplified, and then deleted.” Musk hinted that this doesn’t work, and said his new framework — which emphasizes questioning and deleting unnecessary things first — was more effective.
Musk’s insights offer a stark contrast to the traditional engineering process. He argues that the focus shouldn’t be on perfecting existing solutions, but rather on questioning the very existence of the problem being solved. His emphasis on deletion before optimization challenges conventional wisdom and encourages a more radical approach to innovation.
This constant questioning and iterative process of refinement, evident in his own ventures, suggests a model for achieving truly disruptive progress. The rapid changes and sometimes controversial decisions at Twitter/X, while criticized by some, can be viewed as a real-world application of his “delete, simplify, automate, accelerate” philosophy, emphasizing speed and efficiency over incremental improvements to pre-existing structures. Musk laid off 80 percent of Twitter’s staff, before hiring back people who he later realized were critical to its functioning. Ever since Musk has taken over Twitter, the company has not only not suffered any outages, but also released several new features with a fraction of its original workforce. And this can be down to his framework which urges engineers to shed their “mental straightjackets” and embrace a more dynamic and questioning approach to problem-solving.