Jeff Bezos unterscheidet zwischen „One-Way-Door" und „Two-Way-Door" Entscheidungen. Bei Amazon gilt: Two-Way-Door Entscheidungen können von jedem getroffen werden, schnell und ohne Bürokratie. One-Way-Door Entscheidungen brauchen mehr Überlegung.
Die meisten Teams behandeln alle Entscheidungen wie One-Way-Doors – und werden dadurch langsam.
Warum Entscheidungen treffen so schwer ist
Das Paradox der Wahl
ZU WENIGE OPTIONEN:
→ Schlechte Entscheidungen, weil Alternativen fehlen
ZU VIELE OPTIONEN:
→ Keine Entscheidung, weil Analyse-Paralyse einsetzt
→ [Decision Fatigue](/de/blog/decision-fatigue) setzt ein
DER SWEET SPOT:
→ 2-4 klar definierte Optionen
Die häufigsten Entscheidungsfehler
| Fehler | Beschreibung | Beispiel |
|---|---|---|
| Analyse-Paralyse | Endloses Analysieren ohne Entscheidung | „Noch ein Meeting, dann entscheiden wir" |
| Confirmation Bias | Nur Informationen suchen, die eigene Meinung bestätigen | Framework X ist toll → Nur positive Artikel lesen (siehe auch Kognitive Biases im Projektmanagement) |
| Sunk Cost Fallacy | An schlechten Entscheidungen festhalten wegen bereits investierter Ressourcen | „Wir haben schon 6 Monate investiert..." |
| Groupthink | Alle stimmen zu, niemand hinterfragt | Stille bei „Hat jemand Bedenken?" |
| Recency Bias | Letzte Erfahrungen übergewichten | „Microservices haben bei Firma X nicht funktioniert, also nie wieder" |
| Authority Bias | Meinung der Autoritätsperson übernehmen | „Der CTO sagt X, also machen wir X" |
Framework 1: Reversible vs. Irreversible Entscheidungen
Die Two-Door-Rule (Amazon)
One-Way-Door (Irreversibel):
- Schwer oder unmöglich rückgängig zu machen
- Hohe Kosten bei Fehlern
- Brauchen gründliche Analyse
Two-Way-Door (Reversibel):
- Leicht rückgängig zu machen
- Niedrige Kosten bei Fehlern
- Können schnell getroffen werden
BEISPIELE IN TECH:
ONE-WAY-DOOR:
- Datenbank-Architektur komplett ändern
- Programmiersprache wechseln
- Cloud-Provider migrieren
- Team-Mitglied entlassen
→ Gründlich analysieren, Input einholen, Zeit nehmen
TWO-WAY-DOOR:
- Neues Testing-Framework ausprobieren
- Meeting-Format ändern
- Feature-Flag einführen
- Code-Style anpassen
→ Schnell entscheiden, ausprobieren, anpassen
Die 70%-Regel
Jeff Bezos' Ansatz: Entscheide, wenn du 70% der Informationen hast, die du gerne hättest.
BEI 50% INFORMATION:
→ Zu früh, zu riskant
BEI 70% INFORMATION:
→ Sweet Spot: Genug Wissen, noch nicht zu langsam
BEI 90% INFORMATION:
→ Zu spät, Chance verpasst
Warum 70%? Bei den letzten 30% der Informationen steigt der Aufwand exponentiell, während der Erkenntnisgewinn sinkt.
Framework 2: RAPID für komplexe Team-Entscheidungen
RAPID definiert klare Rollen für den Entscheidungsprozess:
| Rolle | Bedeutung | Aufgabe |
|---|---|---|
| R - Recommend | Empfehlung geben | Analysiert Optionen und schlägt vor |
| A - Agree | Zustimmung erforderlich | Muss zustimmen (Veto-Recht) |
| P - Perform | Ausführung | Setzt die Entscheidung um |
| I - Input | Input geben | Wird konsultiert, muss nicht zustimmen |
| D - Decide | Entscheidung treffen | Finale Entscheidung |
RAPID in der Praxis
BEISPIEL: Neues CI/CD-Tool einführen
R (Recommend): Senior DevOps Engineer
→ Analysiert Tools, erstellt Empfehlung
A (Agree): Security Team, Finance
→ Müssen aus Sicherheits-/Budget-Gründen zustimmen
P (Perform): DevOps Team
→ Implementiert das Tool
I (Input): Entwickler-Teams
→ Geben Feedback zu Anforderungen
D (Decide): Engineering Manager
→ Trifft finale Entscheidung
Warum RAPID funktioniert
- Klarheit: Jeder weiß, was seine Rolle ist
- Geschwindigkeit: Kein endloses Konsensfinden
- Accountability: Eine Person entscheidet
- Inklusion: Input wird gehört, aber blockiert nicht
Framework 3: 10/10/10 für emotionale Distanz
Wenn eine Entscheidung emotional aufgeladen ist, hilft die 10/10/10-Methode:
Frage dich:
- Wie werde ich über diese Entscheidung in 10 Minuten denken?
- Wie werde ich in 10 Monaten darüber denken?
- Wie werde ich in 10 Jahren darüber denken?
Beispiel
ENTSCHEIDUNG: Soll ich dem Team sagen, dass das Projekt
wahrscheinlich scheitern wird?
10 MINUTEN:
→ Unangenehm, Konflikt, schlechte Stimmung
10 MONATE:
→ Das Team hatte Zeit, sich anzupassen. Vertrauen ist höher,
weil ich ehrlich war.
10 JAHRE:
→ Niemand erinnert sich an das spezifische Projekt.
Aber: Reputation als ehrliche Führungskraft bleibt.
ENTSCHEIDUNG: Ja, offen kommunizieren.
Framework 4: OODA-Loop für schnelle Entscheidungen
Der OODA-Loop kommt aus dem Militär und funktioniert für schnelle, iterative Entscheidungen:
┌──────────────┐
│ OBSERVE │ ← Situation beobachten
│ (Beobachten)│
└──────┬───────┘
↓
┌──────────────┐
│ ORIENT │ ← Kontext verstehen
│ (Orientieren)│
└──────┬───────┘
↓
┌──────────────┐
│ DECIDE │ ← Entscheidung treffen
│ (Entscheiden)│
└──────┬───────┘
↓
┌──────────────┐
│ ACT │ ← Handeln
│ (Handeln) │
└──────┬───────┘
│
└────────→ Zurück zu OBSERVE
OODA im Tech-Alltag
BEISPIEL: Production Incident
OBSERVE:
- Error-Rate steigt auf 5%
- Latenz verdreifacht
- Seit letztem Deployment
ORIENT:
- Letztes Deployment war Feature X
- Feature X hat Datenbank-Query
- Query hat keinen Index
DECIDE:
- Rollback des Deployments
ACT:
- Rollback durchführen
- Monitoring checken
- → Zurück zu OBSERVE
ZWEITER LOOP (falls Problem bleibt):
- OBSERVE: Error-Rate noch hoch
- ORIENT: Nicht das Deployment
- DECIDE: Datenbank-Team einschalten
- ACT: ...
Framework 5: Pre-Mortem
Anstatt nach dem Scheitern zu analysieren (Post-Mortem), stelle dir VOR der Entscheidung vor, dass sie gescheitert ist.
Prozess
1. Entscheidung formulieren:
"Wir migrieren auf Kubernetes"
2. Zeitsprung vorstellen:
"Es ist 1 Jahr später. Die Migration ist gescheitert."
3. Fragen:
- Warum ist sie gescheitert?
- Was haben wir übersehen?
- Welche Risiken haben sich materialisiert?
4. Analyse:
- Jeder schreibt individuell Gründe auf
- Gemeinsam durchgehen
- Risiken priorisieren
5. Entscheidung anpassen:
- Mitigations für Top-Risiken einbauen
- Oder: Entscheidung überdenken
Warum Pre-Mortems funktionieren
- Umgeht Groupthink (Bedenken zu äußern wird legitimiert)
- Aktiviert andere Denkweise (Failure Mode statt Success Mode)
- Entdeckt blinde Flecken vor der Entscheidung
Framework 6: Eisenhower-Matrix für Priorisierung
Nicht jede Entscheidung braucht gleich viel Aufmerksamkeit.
DRINGEND NICHT DRINGEND
┌─────────────────┬─────────────────────┐
WICHTIG │ MACHEN │ PLANEN │
│ │ │
│ - Prod Incident │ - Architektur │
│ - Security Bug │ - Team-Entwicklung │
│ - Deadline │ - Strategie │
├─────────────────┼─────────────────────┤
NICHT │ DELEGIEREN │ ELIMINIEREN │
WICHTIG │ │ │
│ - Status-Mails │ - Unnötige Meetings │
│ - Routine-Tasks │ - Perfektionismus │
└─────────────────┴─────────────────────┘
Für Entscheidungen angewendet
WICHTIG + DRINGEND:
→ Sofort entscheiden, auch mit weniger Info
WICHTIG + NICHT DRINGEND:
→ Zeit für gründliche Analyse nehmen
NICHT WICHTIG + DRINGEND:
→ Delegieren oder schnelle 2-Minuten-Entscheidung
NICHT WICHTIG + NICHT DRINGEND:
→ Nicht entscheiden, eliminieren
Entscheidungen im Team treffen
Konsens vs. Consent
Konsens: Alle müssen zustimmen
- Pro: Hohe Akzeptanz
- Contra: Sehr langsam, kleinster gemeinsamer Nenner
Consent: Niemand hat einen schwerwiegenden Einwand
- Pro: Schneller, bessere Entscheidungen
- Contra: Einwände müssen qualifiziert sein
KONSENS:
"Sind alle dafür?" → Eine Person dagegen = blockiert
CONSENT:
"Hat jemand einen schwerwiegenden Einwand?"
→ Nur "Das schadet uns" zählt, nicht "Ich würde es anders machen"
Disagree and Commit
Amazons Prinzip: Nach der Entscheidung committed das ganze Team – auch die, die dagegen waren.
PROZESS:
1. Offene Diskussion mit allen Perspektiven
2. Entscheidung wird getroffen
3. Alle commiten sich zur Umsetzung
4. Kein "Ich hab's ja gesagt" wenn es schiefgeht
WICHTIG:
- Funktioniert nur mit psychologischer Sicherheit
- Voraussetzung: Alle fühlten sich gehört
RFC-Prozess für technische Entscheidungen
Request for Comments (RFC) für größere technische Entscheidungen:
STRUKTUR EINES RFC:
1. PROBLEM
Was ist das Problem, das wir lösen wollen?
2. KONTEXT
Was ist die aktuelle Situation?
3. OPTIONEN
Welche Alternativen gibt es?
Pro/Contra für jede Option
4. EMPFEHLUNG
Was schlagen wir vor und warum?
5. RISIKEN
Was kann schiefgehen?
6. TIMELINE
Wann brauchen wir eine Entscheidung?
PROZESS:
- RFC wird geschrieben und geteilt
- Team gibt Kommentare (async)
- Diskussion-Meeting wenn nötig
- Entscheidung wird dokumentiert
Decision Fatigue vermeiden
Was ist Decision Fatigue?
Je mehr Entscheidungen du triffst, desto schlechter werden sie.
SYMPTOME:
- Entscheidungen aufschieben
- Impulsive Entscheidungen treffen
- Status Quo wählen
- Entscheidungen vermeiden
Strategien dagegen
1. Wichtige Entscheidungen früh am Tag
NICHT: Architektur-Meeting um 17 Uhr
BESSER: Architektur-Meeting um 10 Uhr
2. Routine-Entscheidungen eliminieren
- Gleiche Kleidung (Steve Jobs Approach)
- Gleiche Morgenroutine
- Standing Meetings statt "Wann passt es?"
- Templates für wiederkehrende Entscheidungen
3. Batching
- Alle E-Mails auf einmal
- Alle 1:1s am gleichen Tag
- Entscheidungen sammeln und gemeinsam treffen
4. Defaults setzen
STATT:
"Welches Framework nehmen wir?"
BESSER:
"Unser Default ist React. Wer davon abweichen
will, muss es begründen."
Entscheidungen dokumentieren
Warum dokumentieren?
- Kontext bewahren: In 6 Monaten weißt du nicht mehr, warum
- Onboarding: Neue Teammitglieder verstehen die Historie
- Lernen: Was hat funktioniert, was nicht?
- Accountability: Wer hat entschieden?
Architecture Decision Records (ADR)
# ADR-001: Verwendung von PostgreSQL als Datenbank
## Status
Akzeptiert
## Kontext
Wir brauchen eine Datenbank für die neue Applikation.
Anforderungen: ACID, JSON-Support, gute Performance.
## Entscheidung
Wir verwenden PostgreSQL.
## Begründung
- JSON-Support für flexible Schemas
- Bewährte Performance
- Team hat Erfahrung
- Kosten sind niedrig
## Alternativen betrachtet
- MongoDB: Abgelehnt wegen ACID-Anforderungen
- MySQL: Abgelehnt wegen schwächerem JSON-Support
## Konsequenzen
- Ops-Team muss PostgreSQL-Kenntnisse aufbauen
- Backup-Strategie muss definiert werden
## Datum
2026-01-21
## Entscheider
@jonas
Häufige Entscheidungssituationen in Tech
Technologie-Auswahl
FRAMEWORK:
1. Anforderungen klar definieren (vor der Recherche!)
2. 2-3 Kandidaten evaluieren
3. Proof of Concept für Top-Kandidat
4. Pre-Mortem: Was wenn es schiefgeht?
5. Entscheidung + Dokumentation
ANTI-PATTERN:
- „Das ist gerade hip" als einziges Kriterium
- 10 Optionen parallel evaluieren
- Endlos recherchieren ohne Entscheidung
Build vs. Buy
FRAGEN:
1. Ist es unser Kerngeschäft?
→ Ja: Eher Build
→ Nein: Eher Buy
2. Gibt es gute Lösungen am Markt?
→ Ja: Eher Buy
→ Nein: Eher Build
3. Haben wir die Kapazität?
→ Ja: Build möglich
→ Nein: Buy oder warten
4. Total Cost of Ownership?
→ Maintenance, Updates, Training einrechnen
Refactoring vs. Feature
FRAGEN:
1. Wie oft wird dieser Code angefasst?
→ Oft: Refactoring zahlt sich aus
→ Selten: Feature zuerst
2. Wie schmerzhaft ist der Code?
→ Bugs, langsame Entwicklung: Refactoring
→ Funktioniert: Feature zuerst
3. Kann man inkrementell refactoren?
→ Ja: Parallel zum Feature
→ Nein: Explizite Entscheidung nötig
Fazit: Entscheidungen als Skill
Gute Entscheidungen sind kein Talent, sondern ein Skill, der trainiert werden kann.
Die wichtigsten Prinzipien:
- Reversibilität prüfen: Two-Way-Door = schnell entscheiden
- 70% reicht: Nicht auf perfekte Information warten
- Rollen klären: Wer entscheidet? (RAPID)
- Emotionen managen: 10/10/10 für Distanz
- Schnell iterieren: OODA für dynamische Situationen
- Risiken antizipieren: Pre-Mortem vor der Entscheidung
- Dokumentieren: Für Kontext und Lernen
Die eine Frage für heute:
Welche Entscheidung schiebst du gerade vor dir her – obwohl sie eigentlich eine Two-Way-Door ist?
Triff sie. Jetzt. Du kannst sie später anpassen.
Du willst verstehen, wie du als Führungskraft Entscheidungen kommunizierst und dein Team einbindest? Unser Guide zu Servant Leadership zeigt einen Führungsstil, der auf Vertrauen und Transparenz setzt.
