Making Decisions: How Tech Leaders Make Better Decisions Faster
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 OBSERVE
OODA 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
1. Formulate decision:
"We're migrating to Kubernetes"
2. Imagine time jump:
"It's 1 year later. The migration failed."
3. Questions:
- Why did it fail?
- What did we overlook?
- Which risks materialized?
4. Analysis:
- Everyone writes reasons individually
- Go through together
- Prioritize risks
5. 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:
1. Open discussion with all perspectives
2. Decision is made
3. Everyone commits to execution
4. 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:
1. PROBLEM
What's the problem we want to solve?
2. CONTEXT
What's the current situation?
3. OPTIONS
What alternatives exist?
Pro/con for each option
4. RECOMMENDATION
What do we propose and why?
5. RISKS
What can go wrong?
6. 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:
1. Clearly define requirements (before research!)
2. Evaluate 2-3 candidates
3. Proof of concept for top candidate
4. Pre-mortem: What if it goes wrong?
5. Decision + documentation
ANTI-PATTERN:
- "This is trendy" as only criterion
- Evaluating 10 options in parallel
- Endless research without decision
Build vs. Buy
QUESTIONS:
1. Is it our core business?
→ Yes: More likely build
→ No: More likely buy
2. Are there good solutions on the market?
→ Yes: More likely buy
→ No: More likely build
3. Do we have the capacity?
→ Yes: Build possible
→ No: Buy or wait
4. Total Cost of Ownership?
→ Factor in maintenance, updates, training
Refactoring vs. Feature
QUESTIONS:
1. How often is this code touched?
→ Often: Refactoring pays off
→ Rarely: Feature first
2. How painful is the code?
→ Bugs, slow development: Refactoring
→ Works: Feature first
3. 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.
