thinking-reversibility

What this skill does

# Reversibility Thinking

## Overview

Jeff Bezos distinguishes between Type 1 (irreversible, one-way door) and Type 2 (reversible, two-way door) decisions. The key insight: most decisions are Type 2 but get treated as Type 1, causing analysis paralysis. Match your decision process to the reversibility of the decision.

**Core Principle:** Reversible decisions should be made quickly by individuals. Irreversible decisions deserve deliberation. Most decisions are more reversible than they appear.

## When to Use

- Technology choices
- Architecture decisions
- Process changes
- Hiring decisions
- Feature implementations
- Organizational changes
- Any decision where you're uncertain how much analysis is warranted

Decision flow:

```
Decision to make?
  → Is it easily reversible? → yes → DECIDE QUICKLY (Type 2)
  → Is it hard/impossible to reverse? → yes → DELIBERATE CAREFULLY (Type 1)
  → Unsure of reversibility? → ANALYZE REVERSIBILITY FIRST
```

## When NOT to Use
- You've already classified the door — don't re-run the analysis; just decide at the matched depth.
- Trivial, clearly two-way calls (variable names, which test to write first) — deciding is faster than classifying.
- The decision is being forced by a hard external constraint (deadline, contract, regulation) with no real optionality — reversibility doesn't change the available move.
- An irreversible action is genuinely required and the upside justifies it — name it, accept it, and proceed deliberately rather than stalling.

## Trigger Card

Before deliberating over a decision:

1. **Classify the door** — is it one-way (costly to undo) or two-way (cheap to undo)? If you're not sure, it's probably one-way.
2. **Two-way door?** → Decide fast. The cost of delay exceeds the cost of a wrong choice you can reverse.
3. **One-way door?** → Ask: can I make it more reversible? (Feature flag, canary, small rollout, decouple the irreversible part.) Then deliberate — but only on what's actually irreversible.

If the decision is forced by an external constraint with no optionality, reversibility doesn't change the available move. If an irreversible action is genuinely required and the upside justifies it, name it and proceed.

## Type 1 vs Type 2 Decisions

### Type 1: One-Way Doors

**Characteristics:**
- Irreversible or very costly to reverse
- Consequences are significant and lasting
- Changing course means starting over

**Examples:**
- Fundamental architecture choices (monolith vs microservices for core systems)
- Major technology platform (cloud provider for critical infra)
- Hiring for leadership positions
- Shutting down a product line
- Major acquisitions or contracts
- Public commitments or promises

**Process:**
- Extensive analysis before acting
- Explicitly argue the opposing choice (steel-man the alternative)
- Document the reasoning and the assumptions it rests on
- Escalate / surface to the human owner before committing

### Type 2: Two-Way Doors

**Characteristics:**
- Easily reversed if wrong
- Limited blast radius
- Can iterate and adjust

**Examples:**
- Most feature implementations
- UI/UX changes
- Internal tool selection
- Process experiments
- Meeting cadences
- Individual hiring decisions
- Marketing campaigns

**Process:**
- Decide quickly
- Pick the most reasonable option now
- Monitor results
- Adjust as needed
- Don't over-analyze

## The Reversibility Analysis

### Step 1: Assess True Reversibility

| Factor | Question | Impact on Reversibility |
|--------|----------|------------------------|
| Technical cost | How hard to undo technically? | High cost = less reversible |
| Time cost | How long to reverse? | Months = less reversible |
| Financial cost | How expensive to change? | High cost = less reversible |
| Reputation cost | Will reversal damage trust? | Yes = less reversible |
| Learning cost | Will we lose the learning? | Critical learning = more complex |
| Dependency cost | Have others built on this? | Many dependents = less reversible |

### Step 2: Categorize the Decision

```
Reversibility Score:
- Can undo in days with minimal cost: TYPE 2 (two-way door)
- Can undo in weeks with moderate cost: TYPE 2 with monitoring
- Can undo in months with significant cost: TYPE 1.5 (evaluate carefully)
- Cannot realistically undo: TYPE 1 (one-way door)
```

### Step 3: Match Process to Type

| Decision Type | Process | Effort | Who decides |
|---------------|---------|--------|-------------|
| Type 1 | Full analysis, argue the alternative, document | High | Surface to human owner before committing |
| Type 1.5 | Structured analysis, document rationale | Moderate | Flag to owner if stakes are high |
| Type 2+ | Quick analysis, note rationale | Low | Decide and proceed |
| Type 2 | Just decide | Minimal | Decide and proceed |

## Common Reversibility Misclassifications

### Treating Type 2 as Type 1

```
Decision: Which logging library to use
Common mistake: Extensive evaluation, committee decision, weeks of analysis
Reality: Can swap libraries in a day; dependencies are isolated
Correct approach: Engineer picks one, team evaluates after 2 weeks

Cost of over-deliberation: Weeks of productivity lost
```

### Treating Type 1 as Type 2

```
Decision: Database technology for core product
Common mistake: Quick decision because "we can always change later"
Reality: Changing databases means rewriting queries, data migration, retraining
Correct approach: Thorough evaluation, prototype, stakeholder alignment

Cost of under-deliberation: Months of migration pain later
```

### Hidden Reversibility

Some seemingly irreversible decisions are actually reversible:

```
"We can't change our API because clients depend on it"
Reality: Versioning makes this reversible
       v1 continues, v2 adds improvements

"We can't change the architecture"
Reality: Strangler pattern enables gradual change
        Migrate piece by piece
```

### Hidden Irreversibility

Some seemingly reversible decisions lock you in:

```
"It's just a prototype, we can rewrite later"
Reality: Prototypes often become production
        "Temporary" code lives for years

"We can always switch cloud providers"
Reality: Deep integration creates massive switching cost
        Proprietary services create lock-in
```

## Reversibility Patterns

### The Pilot Pattern

Turn Type 1 into Type 2 through limited rollout:

```
Type 1: "Adopt new framework for entire codebase"
Piloted: "Use new framework for one service"
         → Now it's Type 2: Can abandon pilot with limited impact
         → If successful, expand incrementally
```

### The Abstraction Pattern

Create reversibility through interfaces:

```
Type 1: "Choose between Postgres and MySQL"
With abstraction: "Define data layer interface, start with Postgres"
                  → Can swap implementation later
                  → Cost of reversal dramatically reduced
```

### The Time-Box Pattern

Make long commitments into short experiments:

```
Type 1: "Commit to vendor for 3 years"
Time-boxed: "Start with 6-month pilot"
            → Can exit at known cost
            → Full commitment only after validation
```

### The Feature Flag Pattern

Deploy with reversibility built in:

```
Type 1: "Launch new pricing model"
With flags: "Launch to 5% of users, flag-controlled"
            → Can disable instantly
            → Expand only when confident
```

## Decision Speed Guidance

### Decide Immediately (Type 2)

- Which test to write first
- Variable naming
- Which task to pick up next
- Local refactors within a single module

### Quick Analysis (Type 2+)

- Library choices (within approved options)
- Implementation approach for a feature
- Code organization within a module
- Bug fix approach

### Structured Analysis (Type 1.5)

- Design patterns for new components
- API contract changes (if unversioned)
- Tool adoption
- Architectural changes to non-critical services

### Full Deliberation, Surface to Owner (Type 1)

- Core architecture decisions
- Platform/infrastructure choi