Musk Algorithm

The five steps, in order

The Musk algorithm is the build process Elon Musk drills into teams at SpaceX and Tesla, and the claim its proponents make is that the ordering carries the insight. The steps are: first, question every requirement, especially those from smart people, who are least likely to be challenged, and attach a named owner to each requirement rather than accepting that it "came from a department." Second, delete any part or process you can, aggressively enough that you have to add roughly ten percent of the deletions back, because otherwise you did not delete enough. Third, simplify and optimize, deliberately third and not first. Fourth, accelerate cycle time. Fifth, automate, and only last.¹

The reason for the order is the failure it guards against: the most common error is to optimize or automate something that should not exist. Speed and automation both lock a process in, so applying them before questioning and deletion just reaches the wrong place faster or makes a needless process permanent and invisible.¹ The proponents' sharpest version of the claim is that intelligence is a liability here, because a capable engineer can make almost anything work better, including a bad idea, which lets optimization skill substitute for the harder question of whether the work should be done at all. In that framing the algorithm's value "is not that it makes you successful. It makes you fail at the wrong things faster so you can find the right things."¹

How Glyman applies it at Ramp

Eric Glyman, cofounder of Ramp, presents this exact five-step algorithm, attributed to the SpaceX Raptor engine program, as an operating spine at his company, and extends it beyond the product into hiring.² His emphasis lands on the ordering. In his telling, "automation is last. You do not automate first. You need to delete, delete, delete, get down to simple requirements before you do any of this."²

Glyman's translation of the first two steps into recruiting is what he calls unreasonably short job descriptions. In his reasoning each additional requirement narrows and divides the candidate pool for no real edge, so questioning and deleting requirements, steps one and two, becomes the discipline of stripping a job description down to the few things that actually matter before any hiring process is built around it.² The move demonstrates the algorithm as general process discipline rather than a factory-only tool: the same delete-before-you-optimize sequence pointed at the system that produces hires. Glyman treats an inherited engineering discipline as a portable operating rule.

Relationship to adjacent patterns

Glyman's use of the algorithm sits alongside Simplicity as Distillation, which shares the instinct that reaching the essential structure is the work and everything else is subtraction. It also relates to Standards Over Rules, since a short, owned requirement list is a standard rather than an accreted rulebook. The algorithm's delete-until-something-breaks method is a complement to the Five Percent Rule: Tilman Fertitta inspects the small share of an operation that is wrong to judge an operator, while the Musk algorithm deletes until something breaks to find what is load-bearing, and both privilege the edges over the working core.

Limits

The "add back at least ten percent" step is a heuristic rather than a law, and it does not resolve how to know that a deleted element was load-bearing before its removal breaks something expensive. Proponents concede the cost of re-adding is low in software but may not be in domains that act on the physical world. The treatment here is an account of Musk's stated discipline and of Glyman presenting and applying it; it is the practitioners' own framing rather than an independent evaluation of whether the ordering produces the claimed advantage.