single-optimization-metric — quality + safety report

---
name: single-optimization-metric
description: Force any goal-setting, OKR, team direction, or "what should we measure" debate through Musk's single-metric discipline — pick one number that captures the real mission and stack everything beneath it. Use this skill when the user is writing OKRs, debating KPIs, scoping a quarterly plan, defining team focus, picking a north star, asking "what should we optimize for?", "what's our key metric?", "how do I focus the team?", "we have too many priorities", "which goal matters most?", "should we track A or B?", "our dashboard has 40 numbers", or trying to align a team pulling in five directions. Also trigger when a roadmap measures activity instead of outcome, when a deck lists every metric without ranking them, when leadership keeps swapping the target, or when a team is gaming a proxy instead of the real thing. The principle — cost per ton to orbit, miles per intervention, dollars per kilowatt-hour — one number you cannot cheat. Trigger eagerly even when the user does not name Musk or the framework.
---

# Single Optimization Metric

> "The thing we optimize for at SpaceX is cost per ton to orbit. When the goal is low cost per ton of payload to orbit, you can't cheat."
> — Elon Musk, *The Book of Elon* (Chapter: Optimizing for Mass to Mars)

## What this skill captures

Most teams die from too many metrics, not too few. A dashboard with forty numbers is a dashboard with zero priorities — every direction looks equally valid, every tradeoff becomes political, and the team grinds. Musk's SpaceX runs on exactly one number: cost per ton of useful payload to orbit (or to the Moon, or to Mars). Not launches per year. Not engine count. Not headlines. "A lot of people talk a lot about the number of launches to orbit per year, but this is not really what matters. What really matters is the total useful payload to orbit per year." Everything — reusability, scale, propellant choice, tower catch — collapses into a single scoreboard you cannot game.

The value: this skill forces the user to name the one number, justify why it cannot be cheated, and either commit to it or admit they don't actually know what they're building. Video games without a score are boring; companies without one are dying.

## When to use this skill

- The user is writing OKRs, KPIs, or quarterly goals and has more than one "top" metric.
- A team is misaligned because different functions are optimizing for different numbers.
- The user is debating between two candidate metrics ("should we track A or B?").
- A roadmap or status report is dense with activity metrics (launches, PRs, demos) instead of outcome.
- Leadership keeps swapping the north star every quarter.
- The user is gaming a proxy (lines of code, posts shipped, meetings held) instead of measuring real output.

## The how-to

1. **Name the one number — and prove it cannot be cheated.**
   > "When the goal is low cost per ton of payload to orbit, you can't cheat."
   > — *The Book of Elon*

   The metric must be ungameable by construction. "Cost per ton to orbit" forces you to count fuel, vehicle amortization, refurb time, and reliability all at once. If your candidate metric can be juiced by lying to yourself (launches per year, engineers hired, story points), throw it out.

2. **Strip the metric down to the *useful* output, not the gross output.**
   > "You can't count the heat shield, parachute, or landing systems—only the useful stuff. In the case of the Mars rovers, it's really just the rover. That is the useful thing."
   > — *The Book of Elon*

   Total mass to orbit doesn't matter — useful payload does. Total revenue doesn't matter — gross margin on retained customers might. Define what counts as "the rover" in your domain and refuse to count anything else.

3. **Quantify the current value and the target — in orders of magnitude, not percentages.**
   > "To build a self-sustaining city on Mars, that cost will have to be less than one hundred thousand dollars a ton. That would be ten thousand times better than the current state of the art."
   > — *The Book of Elon*

   "10% improvement" is a status quo target. Set the metric, measure where you are today, and state the multiple you need. If the answer is 2x, ambition is probably too low. If it's 10,000x, now you have a real design constraint.

4. **Kill every competing metric or demote it to a constraint.**
   > "A lot of people talk a lot about the number of launches to orbit per year, but this is not really what matters. What really matters is the total useful payload to orbit per year."
   > — *The Book of Elon*

   Other numbers can survive as floors (reliability >= X, latency <= Y) — never as co-equal goals. Two top metrics means zero top metrics. Pick the one and tell the team the rest are constraints, not targets.

5. **Stack every architectural and design decision under the one metric.**
   > "There could be other solutions too, but this will work. The first order of business was to get one that works. Now we optimize."
   > — *The Book of Elon*

   Reusability, scale, tower catch, methane-vs-kerosene — every SpaceX decision ladders into cost-per-ton. Apply the same test to every feature, hire, and tool choice: does this move the one number? If not, defer or delete it.

6. **Re-derive the metric quarterly. Replace only when it's truly wrong, not when it's hard.**
   > "When we started the Starship design it seemed utterly insane. Now it's gone from utterly insane to merely late."
   > — *The Book of Elon*

   The metric is hard on purpose. Swapping it because you're behind is gaming yourself. Only replace it if the underlying mission changes — and announce the swap loudly so the team re-stacks under the new number.

## Common failure modes

- **The dashboard of forty.** A "balanced scorecard" with no ranking. Every metric is top priority, so none are. Forces decisions to escalate to politics.
- **Activity-as-outcome.** Counting launches, PRs, demos, posts, or meetings. These are inputs. Useful payload is the output. Musk explicitly calls this out: launches per year is not the metric.
- **The unmeasurable proxy.** "Customer love." "Engineering excellence." Inspiring, ungradable, infinitely cheatable. If you can't put a number on it this quarter, it's not the metric.
- **Two co-equal goals.** "Growth and profitability." "Speed and quality." This is how teams stall — every tradeoff becomes a fight. Pick one as the metric, the other as a constraint floor.
- **Swapping the metric every quarter.** If you change the scoreboard mid-game, the team learns the scoreboard doesn't matter. Commit for at least a year unless mission changes.

## When NOT to use this skill

- **Pre-product-market-fit exploration.** When you don't yet know what useful output looks like, optimizing one number too early locks in the wrong thing. First find the product, then pick the metric.
- **True multi-objective regulated work.** Safety-critical systems (aviation, medical devices) genuinely have multiple hard floors that can't all be expressed as one number without losing the plot.
- **Pure research with no shipping deadline.** Curiosity-driven work where the output is "what did we learn" doesn't compress cleanly into one metric.
- **Single-person solo projects.** The alignment problem this skill solves doesn't exist when there's no team to align.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Optimizing for Mass to Mars" (in "Building SpaceX").