How to scale software like Elon Musk: delete first, automate last

It assumes the system is basically right, the process is basically useful, and the next move is to add more people, more tooling, more coordination, more automation, or more dashboards. That is how teams end up with a faster version of the wrong machine.

The interesting part of Elon Musk's operating style is not the mythology around sleeping on factory floors or sending aggressive emails. The useful part is much smaller and more portable. It is the discipline of treating every requirement, part, process, and line of code as guilty until proven useful.

That discipline is often called "the algorithm". In business operations it sounds like manufacturing advice. In software, it is a surprisingly sharp way to fight cognitive overhead.

The algorithm goes like this: question every requirement, delete every unnecessary part, simplify what remains, speed up the cycle, and only then automate. That order matters. Swap the order and you get expensive nonsense.

Question the requirement

Software teams are very good at accepting inherited requirements. A customer once asked for it. Legal wanted it. Sales promised it. Security said it was mandatory. A principal engineer designed the abstraction three years ago. A Jira ticket said "must".

Musk's version of the rule is blunt: every requirement should have a name attached to it. Not a department. Not a process. A person. That sounds like management theater until you apply it to code.

When a requirement has no owner, nobody can explain the tradeoff. When nobody can explain the tradeoff, the team cannot safely remove it, reshape it, or decide that it is no longer true. The requirement becomes architecture by folklore.

In Rails terms, this is how small apps become mysterious. A callback exists because "billing needs it". A background job retries forever because "integrations are flaky". A JSON field stores six optional states because "the mobile app depends on it". Two years later, nobody knows which mobile app, which version, or which customer.

Before scaling anything, force requirements back into daylight. Who needs this behavior? What breaks if it disappears? Is the constraint still real? Is it a product constraint, a legal constraint, an infrastructure constraint, or just a memory of a constraint? That is not bureaucracy. It is the opposite. It prevents bureaucracy from hiding inside the code.

Delete before you optimize

The most famous part of the algorithm is also the most uncomfortable: delete parts of the process.

Musk has said that if you do not have to add back at least 10 percent of what you removed, you did not remove enough. The exact number is less important than the posture. Removal should feel a little dangerous. If deletion is always obvious, the team is probably trimming leaves while the roots keep growing.

Software has its own version of this problem. We optimize modules that should not exist. We add caching around queries that should not run. We add observability to workflows that should be removed. We parallelize jobs that are doing pointless work. We tune a service boundary that only exists because a previous architecture diagram looked serious.

The cheapest code to maintain is the code you did not write. The second cheapest is the code you deleted.

Here is a small example. Imagine a checkout system that performs several validation steps. Some are still useful. Some were added during a long-gone migration. Some only protect against states the database now prevents.

class CheckoutReadiness
  def initialize(order)
    @order = order
  end

  def ready?
    paid? && shippable? && address_confirmed?
  end

  private

  attr_reader :order

  def paid?
    order.payments.settled.exists?
  end

  def shippable?
    order.line_items.all?(&:shippable?)
  end

  def address_confirmed?
    order.shipping_address.present?
  end
end

The interesting move is not to add a caching layer to ready?. The interesting move is to ask whether each check still earns its place. Maybe address_confirmed? exists because the app once allowed orders without addresses, but the current database schema requires one. Maybe shippable? exists because the product once mixed physical and digital goods, but the company removed digital goods last year. Maybe paid? is the only condition that still represents real uncertainty. Deleting a stale check is not micro-optimization. It removes a branch from every future reader's head.

That is the software version of simplifying a turbopump by removing parts instead of negotiating harder with suppliers. You are not making the same thing cheaper. You are making a smaller thing.

Simplify what survives

Only after deletion does optimization become honest. This is where a lot of engineering teams get the order wrong. They see a messy workflow and immediately start improving it. They rename classes, add interfaces, split responsibilities, introduce an event bus, add a new queue, move the code into a service, and feel productive because the design looks cleaner. But if the workflow itself is unnecessary, all of that polish is waste.

Once the dead parts are gone, the remaining system deserves care. This is when names matter. This is when database constraints matter. This is when the boring Rails shape often wins: a clear model, a small controller, a plain object only when it buys clarity, and tests that explain the business rule. Simplification is not making code look clever. It is making the next change smaller.

In practice, this usually means collapsing accidental layers. If data passes through five objects before it reaches the thing that actually changes state, ask what each layer protects. If nobody can answer, the layers are probably not architecture. They are sediment.

This is also where "first principles" is most useful. Do not ask, "How do companies usually build this?" Ask, "What has to be true for this feature to work?" A surprising amount of software gets simpler when you stop copying the shape of other people's constraints.

Speed comes after shape

That might mean faster deploys, shorter feedback loops, smaller batch sizes, quicker tests, or fewer handoffs. It might mean putting the engineer who understands the user flow next to the engineer who understands the database. In manufacturing, a slow line exposes bottlenecks. In software, a slow change process hides them.

Speed is powerful only when the system is pointed in the right direction.

If you speed up before questioning, deleting, and simplifying, you just create defects faster. You ship confused requirements faster. You scale meetings faster. You increase throughput through a pipe that should have been removed.

This is why "people as vectors" is a useful metaphor, even if it sounds cold. A team can have brilliant people with high magnitude, but if their direction differs, the result is drag. One group optimizes for safety, another for speed, another for sales commitments, another for architectural purity. Everybody works hard. The net vector is weak.

Alignment is not a motivational poster. It is a throughput primitive.

The practical version is simple. Make the constraint visible. Decide what matters this week. Put names on requirements. Remove low-value work. Then increase speed around the smaller, clearer system.

Automate last

Automation is the final step for a reason. Automating a bad process is not leverage. It is preservation. It takes something that should be questioned and makes it run forever, usually with fewer humans watching closely enough to notice the absurdity.

Software teams are especially vulnerable to this because automation feels virtuous. We automate deployments, compliance checks, dependency updates, customer workflows, test data generation, billing retries, support triage, and incident response. Some of that is excellent. Some of it is a shrine to an old mistake.

Before automating, ask whether the process should exist. Then ask whether it can be smaller. Then ask whether the cycle time is worth improving. Only then should the team reach for automation.

The same rule applies to AI features. If a support workflow is unclear, adding an LLM can make it look magical while hiding the fact that the company does not know what a good answer is. If a code review process is mostly ritual, automating comments can create more ritual. If a reporting workflow produces numbers nobody acts on, generating the report faster does not create judgment.

Automation should multiply clarity, not compensate for the absence of it.

The software lesson

The useful lesson is not "copy Elon Musk". Most teams should not copy the intensity, the theatrics, or the chaos that often comes with founder-led companies.

The useful lesson is the order of operations. Question the requirement before you honor it. Delete before you optimize. Simplify before you speed up. Speed up before you automate. Treat code as a liability until it proves otherwise.

That mindset scales because it attacks the hidden tax inside software: cognitive load. Every stale feature, vague requirement, unused abstraction, and inherited process forces the team to remember one more thing. At some point, the system is not slow because the servers are slow. It is slow because understanding it is slow.

The best scaling work often looks unimpressive from the outside. A module disappears. A queue is removed. A workflow loses three states. A database constraint replaces defensive application code. A meeting vanishes because the requirement now has a clear owner. A deploy becomes safer because there is less to deploy. That is not less engineering. That is engineering with the waste removed.

Happy deleting!