Jeff Bezos distinguishes between "One-Way-Door" and "Two-Way-Door" decisions. At Amazon, the rule is: Two-Way-Door decisions can be made by anyone, quickly and without bureaucracy. One-Way-Door decisions need more deliberation.
Most teams treat all decisions like One-Way-Doors – and become slow as a result.
Why Making Decisions Is So Hard
The Paradox of Choice
TOO FEW OPTIONS
→ Bad decisions because alternatives are missing
TOO MANY OPTIONS
→ No decision because analysis paralysis sets in
THE SWEET SPOT
→ 2-4 clearly defined options
The Most Common Decision Errors
| Error | Description | Example |
|---|---|---|
| Analysis Paralysis | Endless analyzing without deciding | "One more meeting, then we'll decide" |
| Confirmation Bias | Only seeking info that confirms your opinion | Framework X is great → Only read positive articles |
| Sunk Cost Fallacy | Holding onto bad decisions because of already invested resources | "We've already invested 6 months..." |
| Groupthink | Everyone agrees, nobody questions | Silence at "Does anyone have concerns?" |
| Recency Bias | Overweighting recent experiences | "Microservices didn't work at company X, so never again" |
| Authority Bias | Adopting the authority figure's opinion | "The CTO says X, so we do X" |
Framework 1: Reversible vs. Irreversible Decisions
The Two-Door Rule (Amazon)
One-Way-Door (Irreversible):
- Hard or impossible to undo
- High cost if wrong
- Need thorough analysis
Two-Way-Door (Reversible):
- Easy to undo
- Low cost if wrong
- Can be made quickly
EXAMPLES IN TECH
ONE-WAY-DOOR
- Completely change database architecture
- Switch programming language
- Migrate cloud provider
- Fire a team member
→ Analyze thoroughly, get input, take time
TWO-WAY-DOOR
- Try a new testing framework
- Change meeting format
- Introduce a feature flag
- Adjust code style
→ Decide quickly, try, adjust
The 70% Rule
Jeff Bezos' approach: Decide when you have 70% of the information you'd like to have.
AT 50% INFORMATION
→ Too early, too risky
AT 70% INFORMATION
→ Sweet spot: Enough knowledge, not too slow yet
AT 90% INFORMATION
→ Too late, opportunity missed
Why 70%? The effort for the last 30% of information increases exponentially, while insight gained decreases.
Framework 2: RAPID for Complex Team Decisions
RAPID defines clear roles for the decision process:
| Role | Meaning | Task |
|---|---|---|
| R - Recommend | Give recommendation | Analyzes options and proposes |
| A - Agree | Agreement required | Must agree (veto right) |
| P - Perform | Execute | Implements the decision |
| I - Input | Provide input | Is consulted, doesn't have to agree |
| D - Decide | Make decision | Final decision |
RAPID in Practice
EXAMPLE: Introduce new CI/CD tool
R (Recommend): Senior DevOps Engineer → Analyzes tools, creates recommendation
A (Agree): Security Team, Finance → Must agree for security/budget reasons
P (Perform): DevOps Team → Implements the tool
I (Input): Developer teams → Give feedback on requirements
D (Decide): Engineering Manager → Makes final decision
Why RAPID Works
- Clarity: Everyone knows their role
- Speed: No endless consensus-finding
- Accountability: One person decides
- Inclusion: Input is heard but doesn't block
Framework 3: 10/10/10 for Emotional Distance
When a decision is emotionally charged, the 10/10/10 method helps:
Ask yourself:
- How will I think about this decision in 10 minutes?
- How will I think about it in 10 months?
- How will I think about it in 10 years?
Example
DECISION: Should I tell the team the project will probably fail?
10 MINUTES
→ Uncomfortable, conflict, bad mood
10 MONTHS
→ The team had time to adapt. Trust is higher because I was honest.
10 YEARS
→ Nobody remembers the specific project. But: Reputation as honest leader remains.
DECISION: Yes, communicate openly.
Framework 4: OODA Loop for Fast Decisions
The OODA Loop comes from the military and works for fast, iterative decisions:
┌──────────────┐
│ OBSERVE │ ← Observe situation
└──────┬───────┘
↓
┌──────────────┐
│ ORIENT │ ← Understand context
└──────┬───────┘
↓
┌──────────────┐
│ DECIDE │ ← Make decision
└──────┬───────┘
↓
┌──────────────┐
│ ACT │ ← Act
└──────┬───────┘
│
└────────→ Back to OBSERVEOODA in Tech Daily Life
EXAMPLE: Production Incident
OBSERVE
- Error rate rising to 5%
- Latency tripled
- Since last deployment
ORIENT
- Last deployment was Feature X
- Feature X has database query
- Query has no index
DECIDE
- Rollback the deployment
ACT
- Execute rollback
- Check monitoring
- → Back to OBSERVE
SECOND LOOP (if problem remains)
- OBSERVE: Error rate still high
- ORIENT: Not the deployment
- DECIDE: Involve database team
- ACT: ...
Framework 5: Pre-Mortem
Instead of analyzing after failure (Post-Mortem), imagine BEFORE the decision that it failed.
Process
- Formulate decision:
We're migrating to Kubernetes
- Imagine time jump:
It's 1 year later. The migration failed.
- Questions:
- Why did it fail?
- What did we overlook?
- Which risks materialized?
- Analysis:
- Everyone writes reasons individually
- Go through together
- Prioritize risks
- Adjust decision:
- Build in mitigations for top risks
- Or: Reconsider decision
Why Pre-Mortems Work
- Bypasses groupthink (expressing concerns is legitimized)
- Activates different thinking (failure mode instead of success mode)
- Discovers blind spots before the decision
Framework 6: Eisenhower Matrix for Prioritization
Not every decision needs equal attention.
URGENT NOT URGENT
┌─────────────────┬─────────────────────┐
IMPORTANT │ DO │ PLAN │
│ │ │
│ - Prod incident │ - Architecture │
│ - Security bug │ - Team development │
│ - Deadline │ - Strategy │
├─────────────────┼─────────────────────┤
NOT │ DELEGATE │ ELIMINATE │
IMPORTANT │ │ │
│ - Status emails │ - Unnecessary mtgs │
│ - Routine tasks │ - Perfectionism │
└─────────────────┴─────────────────────┘Applied to Decisions
IMPORTANT + URGENT
→ Decide immediately, even with less info
IMPORTANT + NOT URGENT
→ Take time for thorough analysis
NOT IMPORTANT + URGENT
→ Delegate or quick 2-minute decision
NOT IMPORTANT + NOT URGENT
→ Don't decide, eliminate
Making Decisions in Teams
Consensus vs. Consent
Consensus: Everyone must agree
- Pro: High acceptance
- Con: Very slow, lowest common denominator
Consent: Nobody has a serious objection
- Pro: Faster, better decisions
- Con: Objections must be qualified
CONSENSUS
"Is everyone in favor?" → One person against = blocked
CONSENT
Does anyone have a serious objection?" → Only "This harms us" counts, not "I'd do it differently
Disagree and Commit
Amazon's principle: After the decision, the whole team commits – even those who were against it.
PROCESS
- Open discussion with all perspectives
- Decision is made
- Everyone commits to execution
- No "I told you so" if it goes wrong
IMPORTANT
- Only works with psychological safety
- Prerequisite: Everyone felt heard
RFC Process for Technical Decisions
Request for Comments (RFC) for larger technical decisions:
RFC STRUCTURE
- PROBLEM
What's the problem we want to solve?
- CONTEXT
What's the current situation?
- OPTIONS
What alternatives exist? Pro/con for each option
- RECOMMENDATION
What do we propose and why?
- RISKS
What can go wrong?
- TIMELINE
When do we need a decision?
PROCESS
- RFC is written and shared
- Team provides comments (async)
- Discussion meeting if needed
- Decision is documented
Avoiding Decision Fatigue
What Is Decision Fatigue?
The more decisions you make, the worse they get.
SYMPTOMS
- Postponing decisions
- Making impulsive decisions
- Choosing status quo
- Avoiding decisions
Strategies Against It
1. Important decisions early in the day
NOT: Architecture meeting at 5 PM BETTER: Architecture meeting at 10 AM
2. Eliminate routine decisions
- Same clothes (Steve Jobs approach)
- Same morning routine
- Standing meetings instead of "When works?"
- Templates for recurring decisions
3. Batching
- All emails at once
- All 1:1s on the same day
- Collect decisions and make them together
4. Set defaults
INSTEAD OF
Which framework do we use?
BETTER
Our default is React. Anyone who wants to deviate must justify it.
Documenting Decisions
Why Document?
- Preserve context: In 6 months you won't remember why
- Onboarding: New team members understand the history
- Learning: What worked, what didn't?
- Accountability: Who decided?
Architecture Decision Records (ADR)
# ADR-001: Use PostgreSQL as Database
## Status
Accepted
## Context
We need a database for the new application.
Requirements: ACID, JSON support, good performance.
## Decision
We use PostgreSQL.
## Rationale
- JSON support for flexible schemas
- Proven performance
- Team has experience
- Costs are low
## Alternatives Considered
- MongoDB: Rejected due to ACID requirements
- MySQL: Rejected due to weaker JSON support
## Consequences
- Ops team needs to build PostgreSQL knowledge
- Backup strategy must be defined
## Date
2026-01-21
## Deciders
@jonas
Common Decision Situations in Tech
Technology Selection
FRAMEWORK
- Clearly define requirements (before research!)
- Evaluate 2-3 candidates
- Proof of concept for top candidate
- Pre-mortem: What if it goes wrong?
- Decision + documentation
ANTI-PATTERN
- "This is trendy" as only criterion
- Evaluating 10 options in parallel
- Endless research without decision
Build vs. Buy
QUESTIONS
- Is it our core business?
→ Yes: More likely build → No: More likely buy
- Are there good solutions on the market?
→ Yes: More likely buy → No: More likely build
- Do we have the capacity?
→ Yes: Build possible → No: Buy or wait
- Total Cost of Ownership?
→ Factor in maintenance, updates, training
Refactoring vs. Feature
QUESTIONS
- How often is this code touched?
→ Often: Refactoring pays off → Rarely: Feature first
- How painful is the code?
→ Bugs, slow development: Refactoring → Works: Feature first
- Can you refactor incrementally?
→ Yes: Parallel to feature → No: Explicit decision needed
Conclusion: Decisions as a Skill
Good decisions aren't talent, they're a skill that can be trained.
Most Important Principles:
- Check reversibility: Two-Way-Door = decide fast
- 70% is enough: Don't wait for perfect information
- Clarify roles: Who decides? (RAPID)
- Manage emotions: 10/10/10 for distance
- Iterate quickly: OODA for dynamic situations
- Anticipate risks: Pre-mortem before the decision
- Document: For context and learning
The one question for today:
Which decision are you putting off – even though it's actually a Two-Way-Door?
Make it. Now. You can adjust later.
Want to understand how you communicate decisions and involve your team as a leader? Our guide to Servant Leadership shows a leadership style based on trust and transparency. See also: Decision Fatigue and Cognitive Biases in Project Management.