risk-reward-asymmetry-design — quality + safety report

---
name: risk-reward-asymmetry-design
description: Diagnose conservative-org paralysis as a structural risk-reward asymmetry problem, not a courage problem. Use this skill aggressively whenever the user is doing change management, deploy-policy review, incident-response design, or asking "why won't the team update X that's clearly fragile", "the team won't touch the legacy system", "leadership says move faster but punishes every regression", "we keep seeing the same near-misses", "the postmortem blames the engineer", "our deploy cadence has slowed to a crawl", "people are too scared to refactor", or any moment a known fragility persists because the cost of touching it outweighs the reward for fixing it. Also fires on NASA-shuttle-pattern diagnoses, "good enough because it worked before" reasoning, and orgs treating prior survival as proof of safety. This skill is the diagnostic lens — name the asymmetry, then hand off to remediation. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - fail-tolerant-incentives
  - failure-is-irrelevant-unless-catastrophic
  - you-have-to-blow-things-up
---

# Risk Reward Asymmetry Design

> "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."
> — Elon Musk, *The Book of Elon* (Chapter: You Have to Blow Things Up (NASA shuttle subsection))

## What this skill captures

When an organization stops changing a system everyone knows is fragile, the cause is almost never cowardice or incompetence — it is a payoff structure. Musk's NASA shuttle diagnosis is precise: engineers saw the O-ring and the foam-strike on the wing, knew they were real, and still did not push fixes because "if you make a change and something goes wrong, big punishment. If you make a change and it goes right, small reward." Under that asymmetry, the rational move is to do nothing and hope. That is exactly what they did, until the rocket disassembled.

This skill is the diagnostic lens. It forces the user to stop asking "why won't they change it?" and start measuring the punishment-for-touching-it versus the reward-for-fixing-it. The value: you stop blaming individuals and start naming the structural reason their org has frozen, which is the only thing you can actually fix.

## When to use this skill

- A team has flagged a known fragility (legacy service, fragile deploy step, sketchy auth layer) for months and nobody has touched it.
- Leadership demands "move faster" while every regression triggers a blame-heavy postmortem.
- Deploy cadence has silently decayed and nobody can name a single policy change that caused it.
- A change-management or release-policy review where new gates keep getting added and none get removed.
- Postmortem culture where the engineer who shipped the change is named and the engineer who sat on a known bug is not.
- Any "it has worked so far" argument used as evidence the current design is safe.

## The how-to

1. **Name the specific known fragility.** Do not let the conversation stay abstract — pin it to the one component, deploy step, or design choice everyone privately knows is sketchy.
   > "They had seen the issues with the O-ring and the insulation coming off and hitting the wing before, but there had not been a catastrophe."
   > — *The Book of Elon*
   If you cannot name the O-ring, you are not diagnosing — you are venting.

2. **Measure the punishment for changing it.** What happens to the engineer who touches it and breaks something? Be concrete: PIP, public blame in the postmortem, weekend on-call, reputation hit, loss of promo case, getting "the talk" from a VP.
   > "If you make a change and something goes wrong, big punishment."
   > — *The Book of Elon*
   List the punishments by name. Vague "it would look bad" answers mean you have not actually surfaced the cost.

3. **Measure the reward for fixing it.** What happens to the engineer who quietly hardens it and nothing breaks? Usually: nothing. Maybe a line in a self-review nobody reads.
   > "If you make a change and it goes right, small reward."
   > — *The Book of Elon*
   If the reward is "I get to not be punished next quarter," the asymmetry is total.

4. **Call out the Russian-roulette reasoning.** Hunt for the phrase "it's worked before," "we haven't had an incident," or "it's been stable for years" being used as evidence of safety. That is the trigger-pull-and-I'm-fine fallacy in disguise.
   > "But that's like Russian roulette: 'Look, I've pulled the trigger and I'm fine.'"
   > — *The Book of Elon*
   Prior survival is not evidence of safety when the failure mode is catastrophic and uncorrelated with prior trials.

5. **State the diagnosis out loud.** Write the sentence: "Our team won't fix X because the punishment for breaking it is Y and the reward for hardening it is Z, and Y >> Z." Make it impossible to look away from.
   > "That lack of iteration was a problem."
   > — *The Book of Elon*

6. **Hand off to the remedy, do not improvise it here.** This skill diagnoses. Fixing the asymmetry (rewarding successful changes, protecting engineers from blameful postmortems, treating known-fragility-left-alone as itself a punishable choice) is a separate problem. Name the asymmetry and stop.

## Common failure modes

- **Blaming individuals.** "The team is just risk-averse." No — the team is responding rationally to the payoff structure you built. Fix the structure or shut up.
- **Adding a new gate as the "fix."** Every new review gate increases the punishment for changing things and adds zero reward for fixing them. You just made the asymmetry worse.
- **Treating "stable for N years" as a safety argument.** Musk's whole point: the shuttle was stable for years too. Stability without iteration is the failure mode, not the success state.
- **Confusing this diagnostic with the remedy.** This skill names the disease. Designing the incentive flip — fail-tolerant postmortems, change-reward signals, promotion credit for hardening — is downstream work.
- **Applying this to humans-aboard contexts.** Crew Dragon is "extreme conservatism mode" by design. Asymmetry against change is correct when the failure mode is irreversible loss of life. Do not confuse contexts.

## When NOT to use this skill

- The system genuinely has humans aboard or irreversible blast radius (payments at scale, medical devices, crewed vehicles). Asymmetry against change is the feature, not the bug.
- The team is not changing X because X is actually fine and the user is the one with the wishful thinking. Validate the fragility is real first.
- The blocker is technical capability (nobody understands the code) rather than incentive structure. That is a knowledge problem, not an asymmetry problem.
- The change has been tried, failed, and the org correctly learned from it. Asymmetry only diagnoses paralysis around known-fixable fragility.

## Source

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