Entscheidungsmodelle im Engineering
Software scheitert selten an fehlender Kompetenz.
Sie scheitert an:
- unklaren Entscheidungsrechten
- impliziten Veto-Strukturen
- politisierten Trade-offs
- Verantwortungsdiffusion
Architekturprobleme sind oft Entscheidungsprobleme.
Ein Entscheidungsmodell definiert:
- Wer darf entscheiden?
- Wer muss einbezogen werden?
- Wer trägt das Risiko?
- Wer darf widersprechen?
- Wer hat das letzte Wort?
Ohne explizites Modell entstehen implizite Machtstrukturen.
1. Warum Entscheidungsmodelle notwendig sind
Typische Symptome ohne klares Modell:
- Architektur wird im Daily entschieden
- Security wird „mitgemeint“
- QA blockiert am Ende
- PO entscheidet über technische Qualität
- Niemand fühlt sich verantwortlich
Wenn alle verantwortlich sind, ist niemand verantwortlich.
2. Entscheidungsebenen im Engineering
Nicht jede Entscheidung ist gleich.
Man kann sie grob unterscheiden:
1️⃣ Produktentscheidungen
Was bauen wir?
(Recht bei PM/PO)
2️⃣ Architekturentscheidungen
Wie strukturieren wir das System?
(Recht bei Architect / Tech Lead)
3️⃣ Qualitätsentscheidungen
Wie stabil, sicher, testbar muss es sein?
(Je nach Reife: TL, QA, Security)
4️⃣ Betriebsentscheidungen
Wie viel Risiko akzeptieren wir im Betrieb?
(SRE / DevOps / Management)
5️⃣ Organisationsentscheidungen
Wie strukturieren wir Teams und Verantwortung?
(Engineering Management)
Wenn diese Ebenen vermischt werden, entstehen Konflikte.
3. Typische Fehlmodelle
❌ Konsens-Illusion
„Wir entscheiden das gemeinsam.“
Ergebnis:
- Langsame Entscheidungen
- Kompromisslösungen
- Keine klare Verantwortung
❌ Implizite Hierarchie
„Der mit dem höchsten Titel entscheidet.“
Ergebnis:
- Fachlich schlechte Entscheidungen
- Demotivation
- Architektur-Zerfall
❌ Feature-Dominanz
„Time-to-Market gewinnt immer.“
Ergebnis:
- Technische Schulden
- Erodierende Qualität
- Spätere Eskalationen
4. Klare Entscheidungsdomänen
Ein funktionierendes Modell braucht:
Entscheidungsdomänen
Beispiel:
| Domäne | Entscheidungsrecht | Veto |
|---|---|---|
| Produkt | PO / PM | Management |
| Architektur | Architect / Tech Lead | Principal |
| Qualität | Tech Lead / QA | QA bei Stufe 4–5 |
| Security | Security Engineer | Security |
| Betrieb | SRE / DevOps | SRE |
Nicht jede Organisation braucht formale Tabellen.
Aber jede braucht Klarheit.
5. Veto-Rechte bewusst definieren
Ein stark unterschätztes Thema.
Veto-Rechte sind nötig bei:
- Security (kritische Risiken)
- Compliance (Stufe 4–5)
- Produktionsfreigaben
- Architektur-Breaking Changes
Ohne Veto wird Qualität politisch.
Mit zu vielen Vetos wird Delivery blockiert.
Balance ist entscheidend.
6. Escalation Path
Jedes Entscheidungsmodell braucht:
- klare Eskalationswege
- definierte Fristen
- definierte Instanz für Deadlocks
Deadlocks ohne Eskalationspfad führen zu:
- politischem Stillstand
- Schattenentscheidungen
- Frustration
7. Verbindung zu Qualitätsstufen
Stufe 1–2:
- informelle Entscheidungsmodelle
- Tech Lead dominiert
Stufe 3:
- klare Architektur- und Qualitätsdomänen
- erste formalisierte Veto-Strukturen
Stufe 4–5:
- dokumentierte Entscheidungsprozesse
- Change Control
- auditable Freigaben
Je höher das Risiko, desto formaler das Modell.
8. Entscheidungsmodelle und Kultur
Ein gutes Modell bedeutet nicht:
- Bürokratie
- Powerpoint
- RACI-Overhead
Es bedeutet:
- Klarheit
- Verantwortlichkeit
- Geschwindigkeit
Klare Entscheidung reduziert Reibung.
Unklare Entscheidung erzeugt Politik.
9. Leitfragen für Teams
- Wer entscheidet Architektur wirklich?
- Wer darf Qualität gegen Zeit priorisieren?
- Wer trägt das Risiko einer Security-Lücke?
- Wer darf ein Release stoppen?
- Wer entscheidet bei Konflikten zwischen PO und Tech Lead?
Wenn diese Fragen unklar sind, entstehen strukturelle Probleme.
Kerngedanke
Entscheidungsmodelle sind Organisationsarchitektur.
Ohne sie entstehen:
- implizite Machtstrukturen
- politische Kompromisse
- Qualitätszerfall
Mit ihnen entstehen:
- Geschwindigkeit
- Klarheit
- Stabilität
- Verantwortlichkeit
Technik skaliert nur, wenn Entscheidungen klar sind.