Think Like Elonmusk

Think like Elon

The compressed version of the method is one line: what matters is solving the limiting factor. The work is finding it, because the assumed constraint is usually wrong. Money is not the constraint on healthcare, doctors per capita is. Chips are not the constraint on AI scaling, electrical power and permitting are. Scale is not the constraint on model quality, data quality is. Engineers are not the constraint on factory throughput, skilled trades are.

Everything else here follows from that: reduce the system until you can see which quantity actually binds, then attack that one.

On sources. The five-step algorithm most people associate with him comes from his talks and factory walkthroughs, not from his posting. Across roughly 1,480 posts sampled over three years, about one in eight carries technical reasoning at all, and that sample does not exercise the algorithm once. It appears at the end of this skill, clearly labeled, because it is genuinely his and genuinely useful. Everything before it is what the record actually shows.

The moves

Find the limiting factor, and solve only that

Start by asking what the stated constraint is, then check whether it is the real one. The pattern is that people name the constraint that is easiest to measure, usually money or headcount, while the binding one is a stock that takes years to build or a permission that takes years to obtain.

The reductio he uses to test a supply constraint: name the hypothetical machine that would relieve it, observe that it does not exist, then quote the real lead time. There is no magic doctor factory, and a doctor takes about thirty years to produce from birth.

Reduce the system to one scalar

Pick the single extensive quantity that dominates and reason in that unit, discarding the rest. Electricity output as the proxy for industrial capacity. Mass for a launch vehicle. Tonnage for batteries. Per-capita stocks for anything about human capacity.

Then express it as a ratio against a reference the listener already knows, rather than as a bare figure. A number with no reference point transmits nothing.

Bound it with an energy or area budget

The one physical-bounding move the record strongly supports. Whether a country can be powered by solar is answered with an area budget, not a policy argument. The scale of available solar input makes every other source small by comparison.

When a question is about whether something is possible at scale, compute the budget in energy or area before arguing about implementation.

Judge a design by what would make it pointless

Do not compare two architectures on current specifications. Ask which one turns the other into a special case, and check whether the mission the design serves will still exist when it ships.

The sharpest instance is killing a program on mission horizon rather than performance: if the destination it serves is scheduled to be retired within a few years, the vehicle has no logical purpose regardless of how well it works. The same reasoning retires capsule architectures in favor of propulsive landing, and treats a feature that is a strict subset of another as something to delete.

Establish what the part actually does before arguing about its replacement

Before defending a material or component choice, state the load path. A car door skin is thin mild steel that exists for aerodynamics and appearance and carries almost no load, which settles most arguments about what could replace it.

This is the corpus's version of questioning a requirement: not who asked for it, but what work it is actually doing.

Report rates, not totals

The rate of innovation is what determines whether a technology company succeeds, and speed functions as both offense and defense. In practice this shows up as headlining cadence: launches per month, launches per day, energy delivered growing rather than energy delivered total.

When reporting progress, give the derivative. Stocks flatter, rates inform.

Concede the axis you lose

In technical comparisons he names the axis where a competitor wins, then names the two where he does. A claim that wins on every dimension reads as marketing; a claim that surrenders one is checkable.

State the frontier as a set of tradeoffs and say which point on it you chose.

State scaling claims with their normalizer

The cleanest technical sentence pattern available: make the claim, then attach the condition that has to hold for it to mean anything, for example that parameter count proxies capability only so long as information compression efficiency is held roughly constant.

Any scaling argument without its normalizer is unfalsifiable.

Gate releases on a condition, not a date

The ship criterion is a predicate rather than a calendar entry: it goes to wide release when the bugs are gone, when the scaling issues are confirmed solved, when the system is demonstrably robust. A beta is a beta precisely because that predicate has not been satisfied yet.

Paired with graduated exposure: employee testing, then a wider beta, then general release, with the gate named at each step. Prefer evidence gathered from unaffiliated real users over curated demonstrations.

Use revealed preference as the oracle

When a claim about safety or reliability is contested, look for the party with money at stake. Whether you can buy insurance for something is a better test than any published analysis. For hiring, ask for evidence of exceptional work rather than credentials. For a competitor's claims, take the product apart.

Attack the form of a constraint, not its existence

The most usable version of questioning requirements. A numeric regulatory limit should be replaced by the physical effect it was meant to prevent: a transmitter should operate at whatever power does not disrupt other systems, rather than at an arbitrary ceiling.

This works inside organizations too. Most internal limits are proxies for an outcome nobody restated, and naming the outcome usually dissolves the argument.

Delete the step, then automate what remains

The ordering claim, in its one well-evidenced instance: a surgical procedure was simplified by removing a step entirely, and the automation was built around the simplified version. Removing the step is what made automating the rest worth doing.

Relocate the system when the constraint is regulatory

His most recent technical thesis, and worth flagging as recent rather than settled: if land-based compute is bound by power availability and permitting rather than by technology, the response is to move the system rather than improve it, with orbital compute as the scaling path around the end of the decade.

The transferable shape: when the binding constraint is the environment around an input rather than the input itself, changing location or jurisdiction can beat any amount of local optimization.

Delete the human interface where autonomy allows

The genuine best-part-is-no-part instance in the record is not a bracket, it is the steering wheel and pedals. Once a system no longer needs a human in the loop, the affordances built for that human are cost, mass, and complexity with no remaining function.

Execution over ideas

His highest-engagement statement about method is that ideas are trivial compared with execution. Treat a novel idea as the cheap part of the work.

Technical register

Worth copying deliberately, because it differs sharply from his non-technical writing:

• Lead with the reader's assumption stated as theirs, then negate it.
• Give a quantity, a category superlative, and a ratio to something familiar. Never a bare number.
• Hedge the date and the magnitude; never hedge the direction. Predictions carry "probably" and "roughly" on the number while the sign of the claim stays unqualified.
• Steelman the alternative to its best case, then beat even that.
• Concede an axis.
• Two causes, one technical and one bureaucratic, is a recurring and realistic shape for why something is blocked.
• Bad names conceal that two things are the same thing, so rename before arguing.

The five-step algorithm

From his talks rather than from the record above. It is the most useful thing he has articulated about engineering process, and its ordering is the whole point, since most effort is wasted optimizing, accelerating, and automating things that should not exist.

1. Make the requirements less dumb. Every requirement carries the name of a person, never a department, and you go ask that person why. Requirements from senior people are the most dangerous because nobody questions them.
2. Delete the part or process. If you are not adding back at least a tenth of what you remove, you are not removing enough.
3. Simplify or optimize what survived deletion, and only that.
4. Accelerate the cycle time, after the first three, never before.
5. Automate last, once the process is stable enough to be worth freezing.

Using this lens well

The limiting factor can be organizational. The method points at physical stocks and permissions, and sometimes the binding constraint is a decision nobody will make. Naming it as a technical constraint hides it.

Reducing to one scalar loses information on purpose. It is a tool for finding the dominant term, not a full model. Check what you discarded before committing.

Deletion needs a fast failure signal. Where failures are silent, delayed, or catastrophic, you learn the removed part was load-bearing too late. Before deleting, ask how you would find out you were wrong, and how fast.

Graduated exposure assumes recoverable failure. Staged rollout works when early users can absorb the bugs. It does not transfer to systems where failure injures someone or cannot be rolled back.

Some external requirements are the constraint. Safety standards, regulation, and accessibility rules can look like arbitrary conventions to someone questioning everything. Attacking the form of a limit is useful; verify which category it is in first.

Aggressive dates are hedged forecasts, not derivations. Treat the direction as the claim and the date as an estimate, which is how they are actually stated.

Use the procedure on its own. What transfers is the reasoning. Apply it without importing positions on unrelated subjects.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: zaidmukaddam
• Source: zaidmukaddam/skills
• License: MIT
• Homepage: https://zaidmukaddam.com/skill

Install and usage instructions live in the source repository linked above.