Drei Teams arbeiten parallel an CDK-Modulen. Keiner weiß vom anderen.
Erst als die Pipelines kollidieren, fällt es auf: Jedes Team hat sein eigenes Ding gebaut. Das ist kein Zufall, das ist Conway’s Law in Aktion.
Ich sehe das ständig. Teams entwickeln Features, betreiben Infrastruktur und machen nebenbei Support. Ein Engineer sitzt an einem neuen Service, und alle 20 Minuten poppt eine Slack-Nachricht zu einem Deployment-Problem auf. Der Context Switch kostet massiv Zeit, an Fokus ist nicht zu denken.
Wenn Standards fehlen, Arbeit doppelt gemacht wird und ständige Unterbrechungen den Alltag bestimmen, hast du ein strukturelles Problem. Keine Tool-Frage, sondern eine Organisationsfrage.
Wenn ich mir eine AWS-Architektur anschaue, sehe ich sofort die Teams dahinter. Monolithische Accounts mit hunderten Services durcheinander? Ein großes Team ohne klare Grenzen. Jeder Microservice mit eigenem Monitoring, Logging und Deployment-Setup? Isolierte Teams ohne Unterstützung durch ein Platform Team.
Ein Beispiel: Ein Unternehmen hatte am Ende fünf verschiedene Logging-Systeme, weil jede Abteilung ihre eigenen Standards entwickelt hat. Eine zentrale Architekturvorgabe gab es nicht.
Conway’s Law wirkt allerdings in beide Richtungen. Schlechte Teamstrukturen produzieren schlechte Architekturen. Du kannst genauso gezielt gute Architekturen fördern, indem du deine Teams richtig strukturierst.
Team Topologies definiert vier Teamtypen: Stream-Aligned, Platform, Enabling und Complicated-Subsystem Teams. Ich verstehe das nicht als Framework, das du einfach implementierst, sondern als Sprache, mit der sich erklären lässt, warum es irgendwo stockt.
Platform Teams bauen Standards, Stream-Aligned Teams konsumieren sie. So fällt die Arbeit nur einmal an. Bei großen Tech-Companies wie Amazon oder Spotify gibt es sogar mehrere Platform Teams für unterschiedliche Bereiche, das Prinzip bleibt aber gleich.
Der häufigste Fehler: Platform Teams werden zu Gatekeepern.
Die Lösung liegt in einer Self-Service-Mentalität. Ein Platform Team baut nicht für einzelne Anfragen, sondern stellt Produkte bereit, die Stream Teams eigenständig nutzen können. Muss ein Stream Team jedes Mal ein Ticket aufmachen, um eine neue Umgebung zu bekommen, hast du schon verloren.
Was es dafür braucht: Infrastructure as Code, dokumentierte APIs, klare Schnittstellen. Bei AWS sehe ich das oft mit Landing Zones oder Service Catalogs. Das Platform Team definiert den Rahmen, die Stream Teams deployen selbst.
Der Schlüssel dabei: Platform Teams müssen ihre internen Kunden verstehen. Fragen drei verschiedene Stream Teams nach dem gleichen Feature, ist das ein Signal.
Ich schaue auf drei Dinge.
Erstens: Wie lange dauert es von „Ich brauche X“ bis „Ich habe X“? Wenn Stream Teams Tage oder Wochen warten müssen, ist das Platform Team ein Bottleneck.
Zweitens: Wie oft kommen die gleichen Fragen? Ständige Slack-Nachrichten wie „Wie deploye ich das?“ bedeuten schlechte Dokumentation oder die falsche Abstraktion.
Drittens: Wiederverwendung. Nutzen mehrere Stream Teams dieselben Platform-Services, oder baut jeder wieder sein eigenes Ding?
Bei einem gut funktionierenden Platform Team werden neue Stream Teams schnell produktiv, weil die Grundlagen schon da sind. Ein gutes Signal ist außerdem, wie viele Deployment-Pipelines pro Woche ohne Platform-Team-Involvement laufen. Je höher die Autonomie, desto besser.
Die meisten Unternehmen machen es falsch herum: Sie ändern die Architektur, behalten aber die alte Teamstruktur. Das Ergebnis ist ein verteilter Monolith, das Schlimmste aus beiden Welten. Technisch sind es separate Services, aber jedes Deployment braucht Koordination über alle Services hinweg, weil ein Team alles anfasst. Du hast die Komplexität von Microservices, aber null Autonomie.
Team Topologies sagt dazu: Stream-Aligned Teams brauchen End-to-End-Verantwortung, von Frontend bis Datenbank für ihren Bereich. Tust du das nicht, kämpfst du permanent gegen Conway’s Law an. Und verlierst.
Ich fange mit den Teams an, aber nicht mit einem Big Bang. Mein Weg: kleine, autonome Einheiten schaffen und sie dann wachsen lassen.
Ich suche mir einen relativ abgegrenzten Bereich aus, ein Feature, eine Domain, und bilde dafür ein echtes Stream-Aligned Team mit End-to-End-Verantwortung. Das Team darf seine Services so bauen, wie es richtig ist, mit klaren Schnittstellen zum Rest. Es wird zum Vorbild.
Parallel identifiziere ich die gemeinsamen Probleme: Deployments, Monitoring, Secrets Management. Dafür starte ich ein kleines Platform Team, das genau dafür Lösungen baut. Nicht für alles auf einmal, sondern für die größten Schmerzpunkte.
Die Architektur folgt dann nach. Wenn Teams autonomer werden, entkoppeln sie ihre Services fast von allein, weil sie nicht mehr auf andere warten wollen.
Realistisch? Sechs bis zwölf Monate, bis du echte Veränderungen siehst. Die ersten Erfolge kommen aber schneller: Nach zwei, drei Monaten merkst du, ob es zieht. Darauf achte ich:
Teams hören auf, sich gegenseitig zu blockieren. Stream Teams warten nicht mehr darauf, dass jemand anderes „ihr Ding“ deployed.
Die Slack-Kanäle ändern sich. Weniger „Wer kann mir helfen?“, mehr „Wir haben das selbst gelöst“.
Teams fordern ihre eigenen Standards ein. Wenn ein Stream Team zum Platform Team kommt und sagt „Wir brauchen das als Service, nicht als Ticket“, haben sie es verstanden.
Team Topologies funktioniert nicht, wenn es nur im Orgchart steht. Es funktioniert, wenn Teams anders arbeiten, anders kommunizieren und anders liefern. Das siehst du an Deployment-Frequenz, an Lead Time und an der Stimmung.
Wenn Leute sagen „Wir kommen endlich voran“, bist du auf dem richtigen Weg.