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

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
• •Multiple stakeholder input
• •Devil's advocate review
• •Documentation of reasoning
• •Senior decision maker

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
• •Empower individuals/small teams
• •Monitor results
• •Adjust as needed
• •Don't over-analyze

The Reversibility Analysis

Step 1: Assess True Reversibility

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

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

Decisions to Make in Minutes

• •Which test to write first
• •Variable naming
• •Comment wording
• •Which task to pick up next
• •Slack message tone

Decisions to Make in Hours

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

Decisions to Make in Days

• •Design patterns for new components
• •API contract changes
• •Team process changes
• •Tool adoption
• •Architectural changes to non-critical services

Decisions to Make in Weeks

• •Core architecture decisions
• •Platform/infrastructure choices
• •Significant hiring decisions
• •Large feature scope
• •Strategic priorities

Reversibility Template

# Reversibility Analysis: [Decision]

## The Decision
[What we're deciding]

## Reversibility Assessment

| Factor | Assessment | Score (1-5) |
|--------|------------|-------------|
| Technical effort to reverse | [Details] | |
| Time to reverse | [Duration] | |
| Financial cost to reverse | [Cost] | |
| Reputation impact of reversal | [Impact] | |
| Dependencies affected | [Count/scope] | |
| Learning lost if reversed | [Value] | |

Average: [X]
- 1-2: Clear Type 2
- 3: Type 1.5
- 4-5: Type 1

## Decision Type: [Type 1 / 1.5 / 2]

## Appropriate Process
- Analysis depth: [Minimal / Moderate / Extensive]
- Decision maker: [Individual / Team / Leadership]
- Time to decide: [Minutes / Hours / Days / Weeks]
- Documentation: [None / Brief / Full]

## Can We Increase Reversibility?
- Pilot: [Option]
- Abstraction: [Option]
- Time-box: [Option]
- Feature flag: [Option]

## Decision
[The choice made]

## Reversal Plan (if needed)
[How we would reverse if this proves wrong]

Verification Checklist

• • Assessed reversibility across multiple factors
• • Categorized as Type 1, 1.5, or 2
• • Matched decision process to decision type
• • Explored options to increase reversibility
• • Not over-analyzing Type 2 decisions
• • Not under-analyzing Type 1 decisions
• • Have a reversal plan for non-trivial decisions

Key Questions

• •"How hard would it be to undo this?"
• •"Are we treating this like a one-way door when it's actually two-way?"
• •"Can we pilot this to make it more reversible?"
• •"What's the cost of being wrong vs. the cost of delay?"
• •"Who else would be affected if we reverse?"
• •"Is this actually irreversible, or does it just feel that way?"

Bezos' Wisdom

"Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation."

"But most decisions aren't like that – they are changeable, reversible – they're two-way doors. If you've made a suboptimal Type 2 decision, you don't have to live with the consequences for that long. You can reopen the door and go back through."

"As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention."

Speed matters. Most decisions are reversible. Decide, learn, adjust.