Entscheidungen treffen: Wie Tech-Leader bessere Entscheidungen schneller treffen

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

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:

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

1. Klarheit: Jeder weiß, was seine Rolle ist
2. Geschwindigkeit: Kein endloses Konsensfinden
3. Accountability: Eine Person entscheidet
4. 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:

1. Wie werde ich über diese Entscheidung in 10 Minuten denken?
2. Wie werde ich in 10 Monaten darüber denken?
3. 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?

1. Kontext bewahren: In 6 Monaten weißt du nicht mehr, warum
2. Onboarding: Neue Teammitglieder verstehen die Historie
3. Lernen: Was hat funktioniert, was nicht?
4. 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:

1. Reversibilität prüfen: Two-Way-Door = schnell entscheiden
2. 70% reicht: Nicht auf perfekte Information warten
3. Rollen klären: Wer entscheidet? (RAPID)
4. Emotionen managen: 10/10/10 für Distanz
5. Schnell iterieren: OODA für dynamische Situationen
6. Risiken antizipieren: Pre-Mortem vor der Entscheidung
7. 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.