Team Topologies und Organisationsdesign

Lernziele

Nach dieser Lektion kannst du die vier Team-Typen aus Team Topologies (Skelton/Pais) mit konkreten Beispielen erklären, die drei Interaction Modes unterscheiden und Conway’s Law auf Plattform-Architektur anwenden. Du kannst im Interview begründen, warum ein Plattform-Team organisatorisch anders geschnitten sein muss als ein klassisches Infrastruktur-Team — und woran man Fehlstellungen erkennt.

Das Problem: Org-Charts bauen heimlich mit

Conway’s Law (1968) besagt: Organisationen bauen Systeme, deren Struktur ihre Kommunikationswege spiegelt. Das ist keine Theorie-Anekdote, sondern täglich beobachtbar. Ein Beispiel: Eine Firma hat ein Datenbank-Team, ein Netzwerk-Team und ein Middleware-Team. Was entsteht? Eine Architektur mit drei Schichten, drei Übergabepunkten und drei Wartesschlangen — jedes Deployment braucht drei Tickets, weil jede Schicht einem anderen Team gehört. Die Architektur ist nicht so geworden, weil sie technisch sinnvoll wäre, sondern weil die Organisation so geschnitten ist.

Für Platform Engineering folgt daraus etwas Unbequemes: Du kannst keine Self-Service-Plattform bauen, wenn die Organisation in Übergabe-Silos arbeitet. Die Plattform-Architektur und der Team-Schnitt müssen zusammen entworfen werden — Team Topologies liefert dafür das Vokabular, das sich in der Branche durchgesetzt hat.

Die vier Team-Typen — mit Gesichtern

Stream-Aligned Teams sind der Normalfall: Teams, die entlang eines Wertstroms liefern — das Checkout-Team, das Suche-Team, das Mobile-App-Team. Sie sollen end-to-end verantwortlich sein („you build it, you run it”) und Features schnell zu Kunden bringen. Alle anderen Team-Typen existieren nur, um diese Teams schneller zu machen. Das ist der wichtigste Satz des ganzen Modells.

Platform Teams nehmen Stream-Aligned Teams Komplexität ab, indem sie interne Services als Self-Service anbieten: das Team hinter der IDP aus Lektion 1. Wichtig ist die Abgrenzung: Ein Platform-Team betreibt die Plattform, nicht die Anwendungen der anderen Teams. Sobald es Incidents fremder Apps übernimmt, wird es zum Flaschenhals und untergräbt die Verantwortung der Stream-Teams.

Enabling Teams sind Spezialisten auf Zeit. Beispiel: Drei Teams sollen von VMs auf die neue Kubernetes-Plattform migrieren, haben aber niemanden mit Container-Erfahrung. Ein Enabling Team (zwei, drei erfahrene Leute) arbeitet einige Wochen mit jedem Team, vermittelt die Fähigkeiten — und zieht dann weiter. Das Erfolgskriterium eines Enabling Teams ist, sich überflüssig zu machen. Bleibt es dauerhaft, ist es in Wahrheit eine Abhängigkeit geworden.

Complicated-Subsystem Teams kapseln Domänen, die so viel Spezialwissen erfordern, dass man sie keinem Stream-Team zumuten will: eine Machine-Learning-Inferenz-Engine, ein Payment-Compliance-Modul, ein selbst betriebenes Service-Mesh-Core. Dieser Typ ist bewusst die Ausnahme — jede Auslagerung in ein Subsystem-Team erzeugt eine neue Abhängigkeit.

Drei Interaction Modes — und wann welcher gilt

Genauso wichtig wie der Team-Typ ist, wie Teams interagieren:

X-as-a-Service ist der Zielzustand für Plattform-Teams: Das Stream-Team konsumiert eine Capability über eine API, ein Portal oder Templates, ohne mit Menschen sprechen zu müssen. Skaliert auf beliebig viele Konsumenten.

Collaboration heißt: zwei Teams arbeiten zeitlich begrenzt eng zusammen, mit verschwimmenden Grenzen. Sinnvoll, wenn etwas Neues entsteht — etwa wenn das Plattform-Team mit zwei Pilot-Teams den ersten Golden Path entwickelt und noch niemand weiß, wie die richtige Abstraktion aussieht. Collaboration ist teuer (hoher Kommunikationsaufwand) und muss deshalb befristet sein.

Facilitating ist der Modus der Enabling Teams: helfen, coachen, Wissen übertragen — ohne selbst zu liefern.

Die typische Entscheidungssituation im Plattform-Alltag: Ein neues Feature der Plattform startet im Collaboration-Modus mit ein bis zwei Pilot-Teams, härtet dort aus und wechselt dann in den X-as-a-Service-Modus für alle. Wer diesen Übergang nie vollzieht, hat keine Plattform, sondern eine Dauerberatung. Wer ihn zu früh vollzieht, liefert eine API, die am Bedarf vorbeigeht — das „Inverse Conway Manoeuvre” (Org-Struktur bewusst so schneiden, dass die gewünschte Architektur entsteht) funktioniert nur mit diesem Lernschritt.

Cognitive Load als Schnittkriterium

Team Topologies gibt auch eine Antwort auf die Frage, wo Verantwortungsgrenzen verlaufen sollten: dort, wo der Cognitive Load eines Teams seine Kapazität übersteigt. Ein Stream-Team, das neben seiner Fachdomäne auch noch TLS-Zertifikate, Cluster-Upgrades und Netzwerk-Policies verantworten muss, ist überlastet — nicht an Arbeitszeit, sondern an Themenbreite. Die Plattform-Grenze richtig zu ziehen heißt: fachfremden, generischen Load in die Plattform verschieben, domänenspezifischen Load beim Stream-Team lassen.

Daraus folgt ein praktischer Test für jede Plattform-Capability: „Reduziert das den Load der Stream-Teams spürbar?” Wenn eine Abstraktion so leaky ist, dass Entwickler trotzdem die Details darunter verstehen müssen, hat sie Load hinzugefügt statt entfernt.

Praxis: deine Organisation kartieren

Nimm deine aktuelle (oder letzte) Organisation und führe eine Topologie-Analyse durch — Papier oder Whiteboard genügt:

1. Liste alle Teams auf, die an Software-Delivery beteiligt sind, und ordne jedes einem der vier Typen zu. Notiere Teams, die nicht eindeutig zuzuordnen sind — das sind meist die interessantesten Fälle.
2. Zeichne die Interaktionen zwischen den Teams als Pfeile und beschrifte jeden Pfeil mit dem faktischen Modus: Ticket? Meeting-Serie? API? Vergleiche mit dem Modus, der laut Modell dort stehen sollte.
3. Identifiziere die drei Stellen mit dem größten Abstand zwischen Ist und Soll — z. B. ein „Plattform-Team”, das faktisch im Ticket-Modus arbeitet, oder ein „temporäres” Hilfsteam, das seit zwei Jahren existiert.
4. Formuliere für eine dieser Stellen einen konkreten Veränderungsvorschlag in drei Sätzen: Was ändert sich, für wen, woran misst man den Erfolg?

Diese Übung liefert dir eine echte Geschichte für Interviews — deutlich stärker als jede auswendig gelernte Definition.

Typische Stolperfallen

Das Plattform-Team als Gatekeeper. Wenn jede Änderung der Stream-Teams ein Approval des Plattform-Teams braucht, ist aus dem Enabler eine Genehmigungsbehörde geworden. Richtig sind Leitplanken (Policies, Defaults), nicht Genehmigungen.

Umbenennen statt umbauen. Das alte Ops-Team heißt jetzt „Platform Team”, arbeitet aber weiter Tickets ab. Der Typ eines Teams bestimmt sich durch sein Liefermodell, nicht durch sein Namensschild.

Enabling Teams, die nie gehen. Ein Coaching-Team, das dauerhaft bleibt, hat einen Abhängigkeits-Kreislauf geschaffen — die Stream-Teams lernen es nie selbst.

Conway’s Law ignorieren. Eine Microservice-Architektur über eine Organisation mit zentralen Funktions-Silos zu legen, erzeugt verteilte Monolithen: viele Services, aber jede Änderung braucht weiterhin vier Teams.

Interview-Vorbereitung

Auf „Erkläre Team Topologies — und warum ist das für Plattformen relevant?” antwortest du am stärksten so: Conway’s Law als Problem (mit einem konkreten Beispiel wie dem Drei-Silos-Szenario) → vier Team-Typen in je einem Satz, mit Betonung darauf, dass alle anderen den Stream-Aligned Teams dienen → Interaction Modes mit dem typischen Übergang Collaboration → X-as-a-Service → Cognitive Load als Kriterium für die Plattform-Grenze.

Rechne mit diesen Follow-ups:

• „Was ist der Unterschied zwischen Platform Team und Enabling Team?” — Das eine liefert dauerhaft einen Service, das andere überträgt befristet Fähigkeiten und geht wieder.
• „Wann ist Collaboration der richtige Modus?” — Bei echter Neuentwicklung mit unklarer Abstraktion; immer befristet, mit geplantem Übergang zu X-as-a-Service.
• „Woran erkennst du ein Plattform-Team, das falsch arbeitet?” — Ticket-Warteschlangen für Standardvorgänge, Approvals statt Leitplanken, Übernahme fremder App-Incidents.
• „Was ist das Inverse Conway Manoeuvre?” — Die Organisationsstruktur bewusst so schneiden, dass die gewünschte Architektur die natürliche Folge ist — statt gegen die Org-Struktur anzubauen.

Zusammenfassung

Team Topologies liefert vier Team-Typen — Stream-Aligned, Platform, Enabling, Complicated-Subsystem — und drei Interaction Modes — X-as-a-Service, Collaboration, Facilitating. Plattform-Teams sind Enabler im X-as-a-Service-Modus; neue Capabilities entstehen in befristeter Collaboration mit Pilot-Teams. Conway’s Law erklärt, warum Team-Schnitt und Architektur nur gemeinsam funktionieren, und Cognitive Load ist das Kriterium, wo die Plattform-Grenze verläuft.

Die nächste Lektion klärt die verwandte Abgrenzungsfrage, die in fast jedem Interview kommt: Wie unterscheidet sich Platform Engineering von DevOps und SRE?