you-have-to-blow-things-up — quality + safety report

---
name: you-have-to-blow-things-up
description: Calibrate iteration speed to consequences. When there are no humans aboard, blow things up fast and learn — don't design to eliminate every risk or you will never ship. Use this skill whenever the user is debating test strategy, deploy strategy, hardware iteration cadence, release risk, blast radius, staging vs prod, canary rollouts, "how safe should this be", "what's our test coverage bar", "should we ship this if it might break", "we need more QA before launch", "let's add another review gate", "we can't afford a failure", "100% uptime", "zero-downtime deploys", "the risk-reward feels off", "should we slow down", or any moment a team is treating low-stakes iteration like life-critical engineering. Also fires when reviewing a roadmap that has zero planned failures, when someone equates a broken canary with a P0 incident, or when conservatism is being copy-pasted from a context with humans-aboard stakes into a context without them. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - risk-reward-asymmetry-design
  - failure-is-irrelevant-unless-catastrophic
---

# You Have To Blow Things Up

> "We don't want to design to eliminate every risk. Otherwise, we will never get anywhere."
> — Elon Musk, *The Book of Elon* (Chapter: You Have to Blow Things Up)

## What this skill captures

Iteration speed must be calibrated to consequences, not to corporate reflex. When nothing irreversible is on the line — no humans aboard, no customer data lost, no contractual SLA tripped — the cost of caution is higher than the cost of failure, because you stop learning. Musk runs two regimes in parallel inside the same company: Dragon (crewed) is "extreme conservatism mode — there can never be a failure, ever, for any reason whatsoever," while early Starship was "the polar opposite of Dragon. We were iterating rapidly to learn." Same physics, same engineers, opposite operating mode, because the stakes are different.

The value you get from this skill: a forcing function to name the stakes honestly, choose the matching iteration regime, and stop importing humans-aboard conservatism into no-humans-aboard work. Most over-engineering is a category error.

## When to use this skill

- The user is debating test coverage, staging gates, or QA bars before a deploy that has no irreversible blast radius.
- A team is treating a broken feature flag, canary, or internal tool like it were a fatal accident.
- Someone is proposing yet another approval layer, review gate, or hardening cycle on a system that is not crewed.
- A roadmap or hardware iteration plan has zero planned failures — every prototype "must work."
- The user has copy-pasted SOC2/medical/aviation conservatism into a context where nobody dies if it breaks.
- The user is hesitating to ship because "what if it goes wrong" — without naming what "wrong" actually costs.
- Reviewing why a project is slow: the answer is often that low-stakes work is being treated as high-stakes.

## The how-to

1. **Name the stakes first. Decide which regime applies.** Before any test/deploy/iteration debate, force a one-line answer: is this Dragon (humans aboard, irreversible) or early Starship (no humans, reversible, learning-mode)?
   > "Since Dragon now carries crew, there can be no failures, ever. Everything's going to be tested. There can never be a failure, ever, for any reason whatsoever. With human crew in a developed vehicle, we're in extreme conservatism mode... Early Starship models were the polar opposite of Dragon. We were iterating rapidly to learn."
   > — *The Book of Elon*
   If you can't name the irreversible cost of failure, you're not in conservatism mode. Stop pretending you are.

2. **If it's no-humans-aboard: blow it up on purpose. Plan for failures, don't plan around them.** Schedule the explosion. Pre-commit to learning from each blow-up.
   > "Starship does not have anyone on board during early trials so we can blow things up, learn, and iterate. That's really helpful."
   > — *The Book of Elon*
   A roadmap with zero planned failures is not a brave roadmap — it's a slow one.

3. **Push to the edge of margins. Don't engineer to a comfort zone you invented.** If you're not occasionally failing, you're over-designing and shipping nothing.
   > "We want to push the envelope. If you don't push the envelope, you cannot achieve the goal of a fully and rapidly reusable rocket with high payload. It's not possible. You have to go close to the edge on margins."
   > — *The Book of Elon*
   Margin you never test is margin you never validated. It's theater.

4. **Refuse the risk-reward asymmetry that kills iteration.** Audit your own org: does "change it and it breaks" punish 10x harder than "change it and it improves" rewards? That's the shuttle disease.
   > "There was risk-reward asymmetry. If you make a change and something goes wrong, big punishment. If you make a change and it goes right, small reward... It's hard to iterate when people are on board every mission."
   > — *The Book of Elon*
   Kill the asymmetry or accept that your system will calcify around its last working version.

5. **Build a risk list — and expect it to be wrong.** Write down the failures you predict. Then accept that the actual failure won't be on the list, and the list is still worth writing.
   > "Before every Starship launch, we go through the list of risks we predict, which we call the 'risk list.' If you look at various reasons why we blew up, none of the reasons they blew up were on our 'risk list.' ... We need time and trials to iron out the unknown unknowns."
   > — *The Book of Elon*
   The point of the risk list is not to be right. It's to force flight cadence high enough to discover the unknown unknowns.

6. **First make the damn thing work. Optimize later. Delete what isn't load-bearing.** Doors are unnecessary complexity on a ship you won't get back.
   > "The first goal is to make the damn thing work — we'll optimize it later... Early versions of Starship didn't even have doors. We didn't need doors... Eliminate what isn't necessary to solve the key problem."
   > — *The Book of Elon*
   Polishing a prototype that hasn't proven the core function is a stalling tactic dressed up as rigor.

## Common failure modes

- **Conservatism contagion.** Importing crewed-vehicle discipline into an internal tool, a feature flag, a research prototype, or a canary. Musk's own warning: "It's hard to iterate when people are on board every mission." If nobody's "on board," stop acting like they are.
- **The shuttle trap.** "We figured it was good enough because it worked before. But that's like Russian roulette: 'Look, I've pulled the trigger and I'm fine.'" Defending a frozen design because last time it didn't blow up is the same logic that killed Challenger and Columbia.
- **Zero-failure roadmaps.** If your plan has no planned blow-ups, you're either lying about the plan or you're going to ship one over-engineered thing per fiscal year.
- **Optimizing before working.** Tuning, refactoring, and pre-scaling a thing that hasn't done its core job once. "Make the damn thing work" comes first; everything else is procrastination with extra steps.
- **Pretending you have a risk list when you have a worry list.** A risk list is written, ranked, and reviewed against actual post-mortems. A worry list is a vibe.

## When NOT to use this skill

- Humans aboard. Crewed systems, medical devices, anything where a failure mode is someone dying, irreversibly losing customer funds/data, or breaching a contractual safety SLA. Dragon mode applies. Test everything. Iterate slowly. Musk himself: "there can never be a failure, ever, for any reason whatsoever."
- Regulated launch blast radius. The failure isn't recoverable inside your sandbox (regulators, public safety, security exposure of real user data). Move it to a sandbox first, then apply this skill there.
- Mature systems running at high reliability where the marginal change is small and the cost of regression is large (e.g. Falcon 9 in production: "Every one has come home safely, which is the most important thing"). At that point you've earned conservatism.
- The user has already correctly identified the stakes as high — don't argue them down out of contrarian reflex. This skill calibrates iteration; it doesn't worship recklessness.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "You Have to Blow Things Up" (in "Building SpaceX").