Team Topologies: vier Teamtypen und drei Interaktionsmodi
Team Topologies ist ein Ansatz zur Gestaltung von Produkt- und Technologieteams, den Matthew Skelton und Manuel Pais in einem Buch von 2019 beschrieben haben. Der Artikel erläutert die vier Teamtypen, die drei Interaktionsmodi, die Rolle der kognitiven Last sowie ein durchgerechnetes Beispiel für die Entscheidung über ein Plattformteam.
Beträge und Werte in den Beispielen sind illustrativ und zeigen den Rechenweg. In Projekten arbeiten wir mit den Daten des Kunden.
Dominik Dębski · Lemur Media · · Lesezeit: 4 Min.
Geprüft von Dominik Dębski, 1.11.2026
Was ist Team Topologies?
Team Topologies ist ein Modell der Teamorganisation, das den Typ jedes Teams und seine Zusammenarbeit mit anderen so festlegt, dass die Arbeit mit möglichst wenigen Übergaben zum Kunden fließt.Die Autoren sind Matthew Skelton und Manuel Pais. Das Buch „Team Topologies: Organizing Business and Technology Teams for Fast Flow“ erschien 2019 bei IT Revolution; die zweite, erweiterte Auflage ist auf den 23. September 2025 datiert. Das Modell beruht auf Conways Gesetz (Conway's Law), der Beobachtung von Mel Conway aus dem Jahr 1968, dass Systeme die Kommunikationsstruktur der Organisation abbilden, die sie entwickelt. Deshalb wird die Teamstruktur bewusst gestaltet, bevor die Systemarchitektur entsteht.
Welche Teamtypen und Interaktionsmodi gibt es?
| Teamtyp | Rolle |
|---|---|
| Stream-aligned Team | Liefert Wert in einem einzelnen Arbeitsstrom, z. B. für ein Kundensegment oder eine Phase der Customer Journey |
| Enabling Team | Hilft Stream-aligned Teams, neue Fähigkeiten und Praktiken zu erlernen, und zieht sich danach zurück |
| Complicated-Subsystem Team | Betreut einen Bereich, der enge Spezialisierung erfordert, z. B. eine Pricing-Engine oder ein Prognosemodell |
| Plattformteam (Platform) | Stellt interne Services bereit, die Stream-aligned Teams eigenständig nutzen |
Teams arbeiten in einem von drei Modi zusammen. Kollaboration (Collaboration) bedeutet gemeinsames Arbeiten für einen begrenzten Zeitraum, z. B. an einem neuen Produkt. Service (X-as-a-Service) bedeutet die Nutzung eines fertigen Services eines anderen Teams bei minimaler Kommunikation. Moderation (Facilitation) bedeutet Unterstützung beim Beseitigen von Hindernissen oder beim Erlernen einer neuen Praxis.
Warum ist die kognitive Last wichtig?
Die Autoren betrachten die kognitive Last des Teams (Team Cognitive Load) als eines der wichtigsten Gestaltungskriterien: Ein Team verantwortet so viele Domänen, wie es verstehen und betreuen kann. Ein überlastetes Team trifft schlechtere Entscheidungen und wird zum Engpass in der Lieferung. In der Praxis bedeutet das, die Zahl der Systeme, Technologien und Geschäftsbereiche je Team zu begrenzen und wiederkehrende Infrastrukturarbeit auf eine Plattform zu verlagern.
Aus Conways Gesetz leiten die Autoren das sogenannte umgekehrte Conway-Manöver (Reverse Conway Maneuver) ab: Teamstruktur und Kommunikationswege werden vor dem Bau eines Systems verändert, damit die entstehende Architektur der Zielarchitektur entspricht. In der Praxis heißt das: Die Entscheidung über die Aufteilung eines Systems in Module und die Entscheidung über die Aufteilung der Teams fallen gemeinsam. Will ein Unternehmen ein Zahlungsmodul und ein Katalogmodul unabhängig voneinander weiterentwickeln, braucht jedes davon ein eigenes Team mit klarer Verantwortung.
Wie gestaltet man Teams in der Praxis?
Die Gestaltung beginnt bei den Wertströmen für den Kunden; erst danach werden Teamtypen und Interaktionsmodi festgelegt. In unserer Praxis gehen wir in fünf Schritten vor.
- Wertströme: eine Liste der Kundensegmente, Produkte oder Phasen der Customer Journey, in denen das Unternehmen Wert liefert.
- Stream-aligned Teams: ein Team pro Strom, mit allen Kompetenzen, die nötig sind, um Änderungen ohne Übergaben zu liefern.
- Kognitive Last: Überprüfung der Systeme und Domänen, die jedem Team zugeordnet sind, und Verlagerung des Überhangs auf eine Plattform oder ein Complicated-Subsystem Team.
- Interaktionsmodi: Festhalten, welche Teams in welchem Modus und bis wann zusammenarbeiten.
- Flusskennzahlen: Zeit von der Idee bis zur Umsetzung, Zahl der Abhängigkeiten zwischen Teams, Anteil der durch andere Teams blockierten Arbeit.
Das Modell gilt auch für Teams außerhalb der IT. Ein Wertstrom für ein Kundensegment kann Produkt, Marketing, Vertrieb und Service umfassen, und das Datenteam übernimmt häufig die Funktion einer Plattform für die übrigen Teams.
Wann lohnt sich ein Plattformteam?
Ein Plattformteam lohnt sich, wenn die Zeit, die es den Stream-aligned Teams spart, größer ist als seine eigene Besetzung.
| Komponente | Berechnung | Ergebnis |
|---|---|---|
| Zeit für Infrastruktur vor der Änderung | 6 Teams × 7 Personen × 20 % | 8,4 VZÄ |
| Zeit für Infrastruktur nach der Änderung | 6 Teams × 7 Personen × 5 % | 2,1 VZÄ |
| Eingesparte Zeit | 8,4 − 2,1 | 6,3 VZÄ |
| Besetzung des Plattformteams | 5 VZÄ | |
| Nettogewinn | 6,3 − 5 | 1,3 VZÄ |
Bei vier Stream-aligned Teams läge die Einsparung bei 4 × 7 × 15 % = 4,2 VZÄ, also unter der Besetzung der Plattform. Dann ist ein Enabling Team für einige Monate oder ein externer Dienstleister die bessere Lösung.
Welche Grenzen und typischen Fehler gibt es?
- Bestehende Abteilungen werden in Teamtypen umbenannt, ohne Verantwortung und Arbeitsfluss zu ändern.
- Dauerhafte Kollaboration zwischen Teams: Der Kollaborationsmodus sollte ein Enddatum haben.
- Ein Plattformteam, das Aufträge annimmt, statt Services zur eigenständigen Nutzung bereitzustellen.
- Fachbereiche werden außen vor gelassen: Das Modell gilt auch für Vertrieb, Marketing und Daten, wenn sie am selben Wertstrom beteiligt sind.
- Keine Flusskennzahlen, z. B. Zeit von der Idee bis zur Umsetzung, vor und nach der Reorganisation.