Von Holakratie zu Team Topologies: Tech-Teams für echte Autonomie gestalten

„Autonomie“ ohne Struktur führt nur schneller zu organisatorischer Schuld. Vor ein paar Jahren sind wir vom Matrix-/Projektmodus in den Produktmodus mit stream-aligned Teams gewechselt. Die Geschwindigkeit stieg, aber Defekte, Doppelarbeit und Konflikte zwischen Teams ebenso. Die Lösung war weder „mehr Freiheit“ noch „mehr Prozess“, sondern bessere Grenzen und klarere Entscheidungsrechte.

Dieser Beitrag fasst zusammen, was in der Praxis funktioniert hat, als wir selektiv aus Holacracy, dem Spotify‑Modell und Team Topologies übernommen haben – plus die Leitplanken, die Autonomie vor Chaos schützen.

Was Autonomie in der Technik wirklich bedeutet#

Entscheidungsrechte: Was entscheidet das Team allein, wo braucht es Rat oder Zustimmung?
Klare Domain‑Verantwortung: Ein Team besitzt den Problemraum end‑to‑end – Roadmap, Code, Infrastruktur, On‑Call, Kosten.
Dünne, verlässliche Schnittstellen: Interaktion über versionierte APIs/Events/Verträge – nicht über Meetings.
Outcomes statt Aufgaben: Verpflichtung auf Outcomes und SLOs, nicht Ticket‑Quoten.

Wie wir aus den Modellen übernommen haben#

Holacracy (selektiv)#

Übernommen: Rollencharter (Purpose, Verantwortlichkeiten, Domains) und kurze „Tactical Meetings“.
Nicht übernommen: Vollständige Governance‑Zeremonien/Verfassung – zu schwergewichtig.
Achtung: Rollen‑Wildwuchs und Unklarheit. Lebenden Rollenkatalog führen, Rollen monatlich bereinigen.

Spotify‑Modell (Sprache und Communities)#

Übernommen: Squads (cross‑functional) und Guilds (Communities of Interest). Chapters nur bei echten gemeinsamen Standards.
Nicht übernommen: Organigramm kopieren. Spotify selbst sagt: Modell = Momentaufnahme, kein Bauplan.
Achtung: Chapter Leads als Schattenmanager. Performance Management bei der Squad‑Führung belassen.

Team Topologies (Rückgrat)#

Übernommen: Vier Teamtypen, drei Interaktionsmodi:
- Stream‑aligned, Platform, Enabling, Complicated‑Subsystem
- Collaboration, X‑as‑a‑Service, Facilitating
Warum es wirkt: Richtet Organisation an Conways Gesetz aus, macht Abhängigkeiten explizit. Mit „Inverse Conway Maneuver“ Architektur an gewünschte Teamgrenzen anpassen.
Achtung: Platform‑Teams agieren als Produktteams mit SLAs und „Paved Road“, nicht als Ticketfabriken oder Gatekeeper.

Leitplanken für sichere Autonomie#

Ownership‑Karte: Jede Domain/jeder Service eindeutig einem Team zugeordnet. Keine Doppelverantwortung.
SLOs & Error Budgets: Teams verantworten Zuverlässigkeit; Führung schützt Budgets.
Change‑Taxonomie: Zwei‑Wege‑Türen = Rat einholen; Ein‑Wege‑Türen = Zustimmung betroffener Owner.
Decision Records (ADR): Leichtgewichtig, durchsuchbar, aus PRs verlinkt.
Paved Road: Meinungsstarke Defaults für CI/Deploy/Observability/Auth; Reifegrade und Deprecationsplan veröffentlichen.
Interaktionsverträge: Für jede Abhängigkeit Modus und Erwartungen festhalten.
Metriken: DORA (Lead Time, Deploy‑Frequenz, MTTR, Change‑Fehlrate), Team‑Gesundheit, internes NPS für Platform.

Migrations‑Playbook (12–24 Wochen)#

Value Streams kartieren, 3–5 Stream‑aligned Teams benennen; deren Outcomes klar machen.
Aktuellen Abhängigkeitsgraph zeichnen; Hotspots (Warten, Rework, unklare Ownership) markieren.
Interaktionsmodi festlegen; „Koordination per Meeting“ eliminieren.
Enabling‑Team aufsetzen (8–12 Wochen) für Testing, Observability, Trunk‑Based Development.
Platform als Produkt: Paved‑Road‑RFC mit Golden Paths für CI/CD, Logging, Auth, Experimente.
Service‑Grenzen: Repos und Laufzeit‑Ownership Teams zuordnen. Code, On‑Call, Budget kollokieren.
Kadenz: Wöchentliche Taktik (Squad), zweiwöchentliche Guild‑Syncs, monatliches Architekturforum, Quartalsreview.
Messen: DORA + Incidents + Merge‑Zeit baseline, nach 6/12/24 Wochen erneut messen.

Anti‑Patterns vermeiden#

Autonomy Theater: Backlogs „gehören“ Teams, aber kein Deploy/Staffing/Roadmap‑Einfluss.
Platform Police: Harte Gates statt Paved Road. Kreative Umgehungen folgen.
Schatten‑Management: Chapters bringen Hierarchie zurück.
Matrix‑Creep: Doppelbericht = unklare Entscheidungen. Pro Stream Single‑Threaded Leader.
Tooling statt Outcomes: Neue Zeremonien/Tools ohne Änderungen an Entscheidungsrechten/Grenzen.

Arbeitsvorlagen#

Team‑Charter (Copy/Paste)#

Purpose: Warum existiert das Team? Wer ist der Kunde?
Outcomes (12 Monate): 3–5 messbare Outcomes mit Leading Indicators.
Scope & Grenzen: Was ist in/out? Welche Services/Domains?
Entscheidungsrechte: Was alleine? Was mit Rat/Zustimmung?
Schnittstellen: Eigene APIs/Events; SLAs/SLOs.
Operating Model: Kadenz, On‑Call, Incident‑Response, Release‑Prozess.
Metriken: DORA, SLOs, Kundenzufriedenheit, Kostenleitplanken (z. B. $/1000 Requests).

Checkliste Interaktionsmodus#

Collaboration: Zeitlich begrenzt? Exit‑Kriterien klar? Benannter Owner?
X‑as‑a‑Service: SLOs veröffentlicht? Runbook? Backlog Intake sichtbar?
Facilitating: Coaching‑Ziele? Skill‑Transfer‑Plan? Sunset‑Datum?

Leichter Entscheidungsfluss#

Klein, reversibel: Team entscheidet; ADR schreiben.
Teamübergreifend, reversibel: Rat der betroffenen Owner; Fortfahren ohne begründeten Widerspruch.
Irreversibel/große Wirkung: Zustimmung der Owner‑Leads; Risiko und Rollback dokumentieren.

Tools, die helfen (ersetzen kein Design)#

ADR‑Repo mit Templates und Suche.
Scorecards für Paved‑Road‑Adoption pro Team.
Golden‑Path‑Starter für Services inkl. Observability/Auth.
Org‑Abhängigkeitskarte im Wiki; quartalsweise Review.

FAQ: Wann Autonomie nicht erzwingen#

Frühe Produkt/Market‑Fit‑Unklarheit? Engere Ausrichtung, weniger Teams.
Sicherheits-/Regulierungs‑kritische Domains? Mehr Zustimmung und Audit‑Trail.
Sehr kleine Orgs (<15 Engineers)? Keine Struktur erfinden – starke Defaults und klare Ownership reichen.

Fazit#

Beginne mit Value Streams und Grenzen, nicht mit Zeremonien.
Nutze Team Topologies als Rückgrat; aus Holacracy/Spotify nur gezielt übernehmen.
Investiere früh in Platform‑als‑Produkt und Enabling‑Teams.
Dinge aufschreiben: Charter, SLOs, ADRs, Interaktionsmodi.
Outcomes messen; Struktur danach anpassen.