Bevor Sie KI einführen: Richten Sie die Teams am Wertstrom aus

Bevor Sie KI ins Unternehmen bringen, gibt es einen Schritt, der sich höher verzinst als jede Tool- oder Modellauswahl: Richten Sie Ihre Technologie-Teams entlang des Wertstroms neu aus. Ich habe zu viele Unternehmen erlebt, die Werkzeuge gekauft, Modelle deployt und Leute geschult haben – und am Ende war das Delivery immer noch langsam, die Leute sogar erschöpfter als vorher. Die Ursache liegt fast nie in einer zu schwachen KI. Sie liegt darin, dass die Teams entlang technologischer Schichten geschnitten sind – Frontend, Backend, Algorithmen, Betrieb, Security. Ein einziges End-to-End-Feature berührt vier, fünf Teams, und an jeder Übergabe blutet etwas aus: ein Stück Anforderung, ein Stück Kontext, ein Stück Verantwortung. Stimmen die Teamgrenzen, hat die KI einen Boden, auf dem sie wirken kann. Stimmen sie nicht, beschleunigt die KI lediglich die Schuldenproduktion auf einer kaputten Struktur.

Dieser Artikel stellt eine Organisationsdesign-Methode vor, die sich tatsächlich anwenden lässt – Team Topologies (Skelton & Pais, 2019). Drei Gedanken stehen im Kern: Teams entlang des Wertstroms schneiden, die kognitive Last jedes Teams beobachten, die interne Plattform als Produkt führen. Ich entfalte das an einem realen Szenario aus der Fertigung.

Ein CIO aus der Fertigungsindustrie – der Fall ist aus einem realen Projekt anonymisiert – erzählte mir Folgendes: Die Einführung eines KI-Features zur intelligenten Qualitätssprüfung war technisch nicht schwer. Kameras erkennen Fehler, das Modell ist marktreif. Schwer war das Delivery. Die Frontend-Gruppe baute die Oberfläche, die MES-Gruppe änderte den Arbeitsauftrags-Flow, die Algorithmik-Gruppe deployte das Modell, die Operations-Gruppe verwaltete die Server, und die Security-Gruppe musste obendrauf noch einmal drüberschauen. Ein Feature, 5 Teams, 4 formelle Übergaben, 3 Monate Verzug. Keine Gruppe hat gefaulenzt. An jeder Übergabe fiel nur etwas herunter.

Der Teamschnitt bestimmt

1. Conway’s Law erklärt nur die Hälfte

Conway’s Law besagt: Die Architektur eines Systems spiegelt die Kommunikationsstruktur des Teams, das es baut. Wer seine Teams in Frontend und Backend aufteilt, bekommt ein System mit Frontend-Backend-Trennung. Wie die Teams kommunizieren, so wächst das System – empirisch immer wieder bestätigt.

Conway hat aber nur beschrieben, dass es so kommt. Er hat nicht gesagt, wie man Teams gestalten muss, damit eine gute Architektur von selbst entsteht. Diese Lücke haben Skelton und Pais 2019 mit Team Topologies geschlossen: vier grundlegende Teamtypen, drei Interaktionsmodi und ein durchgehender Grundsatz – die kognitive Last im Blick behalten.

2. Vier Teamtypen: Optionen für die Reorg, nicht Vokabeln zum Auswendiglernen

Ich behandele diese vier Typen als Optionen, auf die Sie bei einer Reorg zurückgreifen können. Sie müssen keine Definitionen auswendig lernen.

Stream-aligned Teams – das Arbeitstier Ihrer Organisation, und die deutliche Mehrheit. (Das Buch sagt „most”, ohne eine feste Quote zu nennen.) Ein „Stream” ist ein kontinuierlicher Wertstrom. Ein Stream-aligned Team verantwortet ein Segment dieses Stroms end-to-end – von der Anforderung über die Entwicklung bis zum Go-Live und Betrieb. Ein einziges Kriterium genügt, um zu prüfen, ob ein Team stream-aligned ist: Kann es den Wert ohne Abhängigkeit von anderen Teams bis zum Nutzer bringen? Zurück zu dem CIO: Hätte sein Prüf-Feature einem einzigen „Prüf-Stream-Team” gehört – mit Leuten, die Frontend, MES-Anbindung, Modell-Deployment und Operations beherrschen – wäre das Feature ohne jede Übergabe ausgeliefert worden. So sollte es aussehen.

Das häufigste Problem in Großunternehmen: Das System läuft end-to-end, aber die Teams sind in horizontale Technologieschichten geschnitten. Jede End-to-End-Lieferung muss sich durch die Meldegrenzen mehrerer Teams durcharbeiten. Der Rhythmus ist branchenübergreifend derselbe, auch wenn sich die Namen ändern. Im Finanzwesen berührt ein Kreditrisiko-Feature gleich vier Gruppen – App, Kernsystem, Risikomodell, Daten. E-Commerce und Telekommunikation verdichten denselben Schmerz in andere Worte: Eine Promotion berührt Katalog, Transaktion, Marketing, Lager; eine Tarifänderung berührt Kanal, Billing, CRM, Netz. Sobald horizontal geschnittene Teams einen vertikalen Wertstrom bedienen müssen, vermehren sich die Übergaben von selbst. Daran leiden alle.

Plattform-Teams – ebnen den Weg für die Stream-aligned Teams. Ein Plattform-Team stellt Infrastruktur, CI/CD und gemeinsame Dienste bereit, sodass Stream-aligned Teams sich Fähigkeiten selbst bedienen können, statt ein Ticket zu stellen und zu warten. Ein Kriterium: Wird Ihre interne Plattform als Produkt geführt – mit Nutzern, Roadmap, SLA – oder ist sie zu einer internen Outsourcing-Werkstatt verkommen, die von Tickets lebt? Die meisten IT-Abteilungen großer Unternehmen stecken im zweiten Teufelskreis. Sie bauen eine Plattform, die niemand nutzt. Die Fachteams gehen drumherum und bauen ihr Eigenes. Das Plattform-Team verkommt zum Dienstleister, der Aufträge abarbeitet. Netflix’ Spinnaker (Continuous Delivery) und Spotifys Backstage (Entwicklerportal) sind die Lehrbuchbeispiele für eine Plattform, die als Produkt geführt wird. Die beiden werden ständig verwechselt: Spinnaker gehört Netflix, Backstage gehört Spotify. Bringen Sie das vor dem Vorstand nicht durcheinander.

Enabling Teams – helfen Stream-aligned Teams auf ein höheres Niveau, mit dem ausdrücklichen Ziel, sich selbst überflüssig zu machen. Ein Enabling Team liefert nicht direkt Geschäftswert. Es hebt die Fähigkeiten der Stream-aligned Teams an: ein Coach, der eine neue Technologie einführt; ein Begleiter einer DevOps-Transition; ein Berater für Security und Compliance. Das Verhältnis zum Stream-aligned Team ist das von Mentor und Schüler, nicht das von Auftraggeber und Auftragnehmer. Für Großunternehmen heißt das: Genau diese Rolle sollte ein externer Transformationsberater spielen – Fähigkeiten transferieren, statt eine langfristige Abhängigkeit aufzubauen.

Complicated-Subsystem-Teams – für die harten Nüsse, die tiefe Spezialisierung verlangen. Wenn ein Subsystem echte Tiefe braucht – eine Risiko-Engine, einen Empfehlungsalgorithmus, Kryptografie, Video-Codecs – wird es herausgelöst und einem Expertenteam übergeben, statt die kognitive Last eines Stream-aligned Teams sprengen. Solche Teams sollten selten sein. Eine Organisation, in der viele Complicated-Subsystem-Teams sprießen, hat in der Regel das, was eigentlich Plattform-Fähigkeit sein sollte, in eine Sammlung von Silos zerschnitten.

Nur die Teamtypen zu benennen reicht nicht. Man muss auch definieren, wie sie miteinander umgehen. Team Topologies unterscheidet drei Interaktionsmodi. Collaboration – zwei Teams arbeiten eng zusammen, passend für unsicheres Neuland, aber energieintensiv und nur für kurze Phasen. X-as-a-Service – ein Team bietet eine Fähigkeit als Produkt an, das ein anderes Team selbst bedient; das ist der effizienteste Modus und sollte der Normalfall sein. Facilitating – ausschließlich Enabling Teams vorbehalten. Die zentrale Frage des Organisationsdesigns lautet: Wie bringe ich so viele Interaktionen wie möglich in Richtung X-as-a-Service? Wer langfristig auf „Collaboration” angewiesen ist, hat seine Plattformisierung nicht hingekriegt. Beim CIO sieht das so aus: Das Prüf-Stream-Team und das Plattform-Team sollten als X-as-a-Service interagieren. Die Plattform stellt einen Self-Service-CI/CD-Eingang bereit, das Prüf-Team nutzt ihn, ohne sich abzustimmen. Wenn für jedes Deployment noch ein „Collaboration”-Meeting mit dem Plattform-Team nötig wird, fehlt die Plattformisierung – und das Problem liegt nicht in der Einstellung, sondern darin, dass die Plattform nie als Produkt geführt wurde.

Gesunde Organisation: Ar

3. Warum weder „mehr Leute” noch „mehr Prozess” retten: die kognitive Last

Das ist der am meisten unterschätzte Beitrag von Team Topologies. Es rückt die kognitive Last ins Zentrum des Organisationsdesigns.

Ein Team von 5 bis 8 Personen hat nur eine begrenzte kognitive Kapazität. Verlangt man von einem Team, gleichzeitig ein Dutzend zusammenhangsloser Systeme zu pflegen, mit sechs oder sieben Upstreams zu sprechen und sich obendrein durch drei neue Frameworks zu arbeiten, ist es überlastet. Qualität sinkt. Delivery wird langsamer. Menschen brennen aus.

Das erklärt ein zweites Rätsel, das mir der CIO schilderte: „Ich habe drei Leute dazugegeben – warum sind wir immer noch langsam?” Die Wurzel liegt darin, dass diese Gruppe bereits zu viele unzusammenhängende Dinge gleichzeitig trug. An Leuten fehlte es eigentlich nicht. Mehr Leute setzen nur mehr Körper demselben Chaos aus. Mehr Prozess ist noch schlimmer: Prozess frisst eine weitere Schicht kognitive Last, und die Leute, die eigentlich etwas liefern könnten, verbringen noch mehr Zeit mit Formularen, Meetings und Freigaben.

Das leichteste Fett, das ein Großunternehmen abschneiden kann, ist die Last, die es sich selbst aufbürdet – teamübergreifendes Hin und Her, ständiger Kontextwechsel, Freigabeketten. Man braucht dafür keine neue Technologie. Man muss nur aufhören, sich selbst zu quälen.

Ein konkretes Beispiel. Der Leiter eines Kernsystem-Teams bei einer Bank, 7 Leute, gleichzeitig an vier Upstreams angebunden – Risiko, Kundenservice, Regulierungs-Reporting, Marketing – und zuständig für drei voneinander unabhängige Module. Allein die tägliche Last aus teamübergreifenden Freigaben, Alignments und Kontextwechseln fraß fast die Hälfte der Kapazität. Einem solchen Team nützt das beste KI-Werkzeug auf dem Markt nichts. Es hat keine freie kognitive Bandbreite mehr, um Neues zu lernen oder Prozesse zu ändern. Rettung heißt hier erst einmal Entlastung: die unzusammenhängenden Module herauslösen und das Team auf einen einzigen Wertstrom verpflichten.

Amazons Two-Pizza-Team-Regel handelt von Kommunikationskosten: Sobald eine Gruppe wächst, explodiert die Zahl der Kommunikationskanäle zwischen den Mitgliedern (n(n-1)/2), und die Entscheidungen werden langsam. Team Topologies geht eine Ebene tiefer: Ab etwa 8 Personen lässt sich auch die kognitive Last nicht mehr bändigen. Was Organisationsdesign wirklich tut, ist Teams nach kognitiver Last zu schneiden, sodass die Last jedes Teams im erträglichen Bereich bleibt – statt Meldelinien nach Funktion zu ziehen.

Ein Ein-Satz-Check-up für Großunternehmen: Tragen Ihre „beschäftigsten Leute” gleichzeitig fünf oder mehr unzusammenhängende Dinge? Wenn ja, rettet weder mehr Personal noch mehr Prozess. Dann müssen Sie neu schneiden.

4. So gehen Sie ran: das Inverse Conway Maneuver

Das ist der am direktesten anwendbare Hebel. Zeichnen Sie nicht erst eine Zielarchitektur und passen dann die Teams an, sondern ändern Sie die Teamstruktur zuerst, und lassen Sie die Architektur in die Form wachsen, die Sie wollen.

Der klassische Weg: Ein Architekt zeichnet eine Zielarchitektur („Wir gehen auf Microservices!“) und fordert die Teams auf, sich entsprechend anpassen. Das scheitert fast immer. Die bestehende Teamstruktur zieht die Architektur immer wieder in ihre eigene Form zurück. Conway’s Law, am Werk.

Das Inverse Conway Maneuver dreht die Reihenfolge um. Sortieren Sie die Teams zuerst entlang des Wertstroms neu – weisen Sie Stream-aligned Teams aus, bauen Sie ein Plattform-Team auf –, sodass die Teamgrenze zur künftigen Servicegrenze wird. Dann driftet die Architektur von selbst zu einer sinnvollen Serviceaufteilung, weil Teams natürlicherweise über APIs kommunizieren, statt in einer gemeinsamen Datenbank herumzustochern.

Zurück zu dem CIO. Ich habe ihn nicht zuerst ein Microservice-Framework wählen lassen. Ich habe ihn etwas viel Schlichteres tun lassen: den „Prüf”-Strom als eigenes Team aufzustellen. Jeweils eine Person aus den ursprünglichen Frontend-, MES-, Algorithmik- und Operations-Gruppen herauslösen, zu einem 6-köpfigen Prüf-Stream-Team zusammenfassen, das end-to-end für die Prüffunktion verantwortlich ist. In drei Wochen passierten drei Dinge. Woche eins: Sie stellten fest, dass ein Schritt, der im MES-Auftragsflow feststeckte, das Algorithmik-Team gar nicht brauchte – sie änderten es intern. Woche zwei: Sie entschieden selbst, das Modell-Deployment vom „Bei Operations anstehen” auf teaminternen Self-Service umzustellen, weil das Plattform-Team ihnen einen CI/CD-Selbstbedienungs-Eingang eröffnet hatte. Woche drei: Sie nahmen ein erstes kleines End-to-End-Feature live, ohne irgendeine Teamgrenze zu berühren. Keine neuen Leute, kein neues Werkzeug – die horizontalen Schichten waren zu vertikalen Strömen aufgerichtet worden. Die Delivery-Zeit sank von 3 Monaten auf 3 Wochen. Es folgte ein unerwarteter Gewinn: Dieses Team begann, von sich aus Verbesserungen vorzuschlagen, weil es zum ersten Mal den ganzen Prüf-Strom überblickte und für das Ergebnis end-to-end verantwortlich war. Als es noch über 5 Teams lief, hatte sich niemand für den gesamten Prüf-Strom verantwortlich gefühlt.

Beispiel Fertigung: Prüf

Für Entscheidungsträger ist das eine kontraintuitive, aber hebelstarke Schlussfolgerung: Hören Sie auf, am Architekturdiagramm endlos zu feilen, und fangen Sie an, im Organigramm zu schneiden. Architektur ändern ist das Ergebnis. Organisation ändern ist der Hebel.

Wer es einsetzt

  • Banken (offizieller TT-Schwerpunkt + Referenzfall bei starker Regulierung). teamtopologies.com führt eine Experten-Kolumne mit dem Titel „When DORA metrics meet governance in banking”. Die dort zitierte DORA-Forschung ist hart: External approvals korrelieren negativ mit Lead Time, Deployment Frequency und Restore Time – je mehr teamübergreifende Nachtrags-Freigaben, desto langsamer das Delivery und desto langsamer die Störungsbehebung. Das stützt exakt die These dieses Artikels: Compliance-Anforderungen in das Stream-Team einbauen, Freigaben nach vorn verlagern, statt teamübergreifend im Nachhinein gegenzuzeichnen. Digitalkreditinstitute wie ClearBank tauchen im offiziellen Ökosystem wiederholt auf. Die Bankenbranche ist der instruktivste Fall für eine Wertstrom-Reorganisation unter harter Regulierung.
  • Zalando (E-Commerce, Vorbild für „Plattform als Produkt”). Die interne Entwicklerplattform dient als Self-Service-Fähigkeit für Stream-aligned Teams – ein Plattformisierungs-Maßstab, den die TT-Community oft zitiert.
  • AutoTrader UK (Auto-Classifieds). Ein realer Adoptionsfall, den TT offiziell wiederholt zitiert – Reorganisation nach Wertstrom plus interne Plattform als Produkt.
  • KPMG UK (2024 TT Official Solutions Partner geworden). Bringt TT zu Großkunden und Finanzinstituten – ein Signal, dass TT im Mainstream-Beratungsmarkt angekommen ist.
  • Netflix / Spotify (Vorbilder für „Plattform als Produkt”, keine TT-Adoptionsfälle). Beide haben ihre Plattform schon vor Erscheinen des Buchs 2019 als Produkt geführt und belegen damit das Prinzip – sie sind aber keine Adoptionsfälle des TT-Vierteamsmodells.

Quellen: teamtopologies.com/examples (offizielle Fallbibliothek) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (DORA-Expertenkolumne zur Bankenbranche)

5. Wann es nicht wirkt

Team Topologies ist kein Silberkugel. Vier typische Fallstricke, und jeder steht für ein reales Großunternehmen-Leiden.

Nur umbenennen, die Struktur nicht ändern. Die „Frontend-Gruppe” heißt jetzt „Stream-aligned Team”, die Meldestruktur bleibt aber nach Technologieschicht – Conway’s Law lässt sich nicht mit einer Namensgebung bezahlen. Das ist das häufigste Ende einer kosmetischen Reform in einem Großunternehmen: neue Etiketten, alte Struktur.

Das Plattform-Team wird nicht als Produkt geführt. Keine Roadmap, keine Nutzererfahrung. Stream-aligned Teams umgehen es weiter, und die Plattform verkommt zu einer ticketgetriebenen Outsourcing-Werkstatt.

Alle Teams „collaborieren”. Collaboration ist ein energieintensiver Interaktionsmodus, nur geeignet für kurze Phasen in unsicherem Neuland. Wer langfristig auf Collaboration angewiesen ist, hat seine Plattformisierung nicht hingekriegt. Die Oberfläche sieht aus wie „tolle Kooperationskultur”. Die Krankheit darunter ist fehlende Plattformisierung.

Die KPIs ziehen nicht nach. Das Organigramm hat sich geändert, gemessen wird weiter nach Funktion – Frontend-Codezeilen, Bug-Zahlen – und das Verhalten kippt sofort in die alte Form zurück.

Diese vier Punkte verdichten sich zu einem Urteil: Organisationsstruktur, Anreizstruktur und technische Architektur – wer von den dreien eine ändert, ohne die beiden anderen mitzuziehen, scheitert.

Eine Variante für stark regulierte Branchen. Banken und Telekommunikation werden fragen: Funktionen wie Security, Compliance und Technologie-Risik müssen aus Gründen der Segregation of Duties unabhängig bleiben – das ist eine harte gesetzliche Anforderung, keine organisationale Trägheit. Nicht einfach in das Stream-Team hineinzerren. Aber man muss auch nicht zur horizontalen Nachtrags-Freigabe zurückkehren. Zwei Wege. Erstens: Compliance- und Security-Vertreter in das Stream-Team einbetten. Sie sitzen im Team, melden zusätzlich fachlich an die Compliance-Linie – nah am Wertstrom und trotzdem unabhängig. Zweitens: Compliance als Enabling Team ausgestalten, das dem Stream hilft, regulatorische Anforderungen in den Flow einzubauen – etwa Compliance-Checks in der CI –, sodass die Freigabe nach vorn in das Team rutscht, statt teamübergreifend nachträglich zu erfolgen. Regulatorische Anforderungen werden zur eingebauten Qualität des Stream-Teams, nicht zum externen Prüftor. Das ist der Schlüssel, damit auch stark regulierte Branchen „fließen” können.

6. Was Sie vielleicht fragen wollen

„Wir sind seit zehn Jahren nach Technologieschichten geschnitten – zieht eine Reorg nicht alles aus den Angeln?” Ja, aber weit weniger, als Sie fürchten. Sie müssen nicht das ganze Unternehmen umstoßen und neu anfangen. Wählen Sie den Wertstrom, der am meisten klemmt – meistens der, über den am lautesten geklagt wird –, und stellen Sie ihn als einzelnes Stream-aligned Team auf. Wie jener CIO: 4 bis 8 Wochen, ein kleines Team, und Sie werden eine spürbare Veränderung der Delivery-Geschwindigkeit sehen. Ergebnisse überzeugen die nächste Runde besser als eine Präsentation.

„Wie hängt das mit der KI-Transformation zusammen, die wir schon laufen haben?” Direkt. KI repariert keine fehlgesteuerte Organisation. Sie verstärkt, was ohnehin da ist: Hochleistungs-Teams werden mit KI schneller; fehlgesteuerte Teams bauen mit KI nur schneller Schulden auf. Deshalb muss die Organisationsdiagnose vor der Tool-Beschaffung stehen. Deshalb habe ich in meiner Methode, dem 7-Step AI Transformation Coaching Framework, die „Capability-Bewertung” sehr weit vorn gesetzt: erst auf Organisation und Leute schauen, dann über Werkzeuge reden.

„Was, wenn wir nicht alle vier Teamtypen zusammenbekommen?” Die meisten Organisationen bekommen sie nicht zusammen – und müssen auch nicht. Die ersten beiden, die Sie haben sollten, sind Stream-aligned Teams (für End-to-End-Delivery) und ein Plattform-Team (damit das Rad nicht immer neu erfunden wird). Enabling und Complicated-Subsystem-Teams richten Sie nach Bedarf ein; dass sie anfangs fehlen, ist normal. Erfinden Sie keine Teams nur, um auf vier Typen zu kommen. Das kehrt Mittel und Zweck um.

7. Was Entscheidungsträger mitnehmen

These eins: Bevor Sie KI einführen, zeichnen Sie eine Team-Topologie-Karte. Haben Sie vor der letzten KI-Tool-Einführung je eine Team-Topologie gezeichnet? Sind Teams nach Technologieschichten falsch geschnitten, beschleunigt selbst die stärkste KI nur die Schuldenproduktion auf einer kaputten Struktur. Diese eine Prüfung fängt mindestens die Hälfte der wirkungslosen IT-Investitionen eines Großunternehmens ab. Konkreter Schritt: Listen Sie alle Teams auf und markieren Sie, für welchen Wertstrom jedes end-to-end verantwortlich ist. Wer sich nicht zuordnen lässt, ist nach Technologieschicht geschnitten und wird vorrangig reorganisiert.

These zwei: Machen Sie einen kognitive-Last-Check-up. Hören Sie auf, „Haben wir genug Leute?” zu fragen. Fragen Sie, welche Teams gleichzeitig mehr als 5 unzusammenhängende Systeme pflegen, und welche Personen an mehr als 3 Upstreams hängen. Das offenzulegen, bringt mehr als zusätzliche Leute oder Prozesse. KI kann einen Teil der Last abfangen – Code schreiben, nachschlagen, vorsortieren –, vorausgesetzt, Sie verteilen die Last bewusst neu, statt einem ohnehin überlasteten Team noch eine „KI-Rollout”-Aufgabe aufzubürden.

These drei: Führen Sie die interne Plattform als Produkt, sonst verkommt sie zum Outsourcing. Eine Plattform braucht Nutzer, eine Roadmap, ein SLA und jemanden, der für die Adoptionsrate verantwortlich ist. Im KI-Zeitalter muss diese Plattform zusätzlich das Modell-Gateway, die Prompt-Bibliothek und eine Agent-Laufzeitumgebung umfassen – das Fundament, das der spätere Beitrag zum „Adoption Framework” ausbauen wird.

These vier: Lassen Sie nicht zu, dass KI falsche Grenzen zementiert. Dieser Punkt richtet sich an Organisationen, die KI-Agenten einführen. Wenn Sie Agenten in Teams einbauen, wird ein falscher Teamschnitt verstärkt: Der Agent automatisiert entlang der bestehenden, falschen Grenzen und verfestigt die kaputte Struktur. Bevor Sie KI-Agenten einführen, stellen Sie sicher, dass die Teamgrenzen stimmen. Das ist das Thema des 11. Teils dieser Reihe.

Umkehr-Selbstcheck (ohne Beschönigung beantworten): Ist Ihr Team nach Wertstrom geschnitten oder nach Frontend/Backend/Operations/Security? Trägt Ihre beschäftigste Person gleichzeitig mehr als 3 unzusammenhängende Dinge? Eine interne Plattform, die niemand nutzt, ist die rote Ampel einer gescheiterten Plattformisierung. Wenn eine der Antworten Ihnen Unbehagen bereitet: Reorganisieren Sie zuerst die Teams, bevor Sie KI einführen – das ist die Investition mit der höchsten Vorrendite.

Nächster Schritt

Das ist Teil 2 der Reihe „Software-Engineering im KI-Zeitalter” (Folge 172 der Kolumne „Learn AI Slowly”). Von Conway (die Organisation bestimmt die Architektur) zu Team Topologies (wie man die Organisation gestaltet). Teil 3 wirft einen Blick auf eine grundlegendere Frage: Wenn KI Code-Produktion fast kostenlos macht – wohin wandert der Flaschenhals des Software-Engineering?

Reihe: Diese Reihe begleitet kontinuierlich die Entwicklung von KI-Programmierwerkzeugen, Organisationsarchitektur und Software-Engineering-Paradigmen – etwa zu neuen Konsequenzen von Conway’s Law im Zeitalter der KI-Agenten (2026) oder zur Reife des aktuellen Werkzeug-Ökosystems. Abonnieren Sie die Reihe für fortlaufend aktualisierte Einsichten.

Über diese Reihe

„Software-Engineering im KI-Zeitalter” ist eine Tiefenreihe für CIO, CDO, CTO und digitale Verantwortliche in Telekommunikation, Finanzen, Fertigung und E-Commerce – insgesamt 15 Teile. Basierend auf über 200 wissenschaftlichen Arbeiten und Branchenberichten, mit Evidenzstufen versehen.

Ich bin ehemaliger IBM-Ingenieur und ICF-zertifizierter Coach, habe KI- und Digitalisierungs-Projekte für Carrier und Großunternehmen umgesetzt. Was hier steht, sind Erfahrungs-Urteile aus dem Feld.

Wenn Sie beim Lesen denken „Sieht unsere Firma auch so aus” – ich habe einen „Team-Topologie-Selbstcheck mit 20 Fragen” erstellt und biete einen 30-minütigen 1:1-Diagnose-Call an, der Ihnen hilft, den Wertstrom zu finden, den Sie zuerst reorganisieren sollten. Bei Interesse: Schreiben Sie dem Kanal „AI Decision-Maker Insight” oder an coach@iaiuse.com.

Quellen

  • Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (Ursprungsquelle der vier Teamtypen / drei Interaktionen / kognitiven Last – Primärquelle.)
  • Conway, M. (1968). How Do Committees Invent? Datamation.
  • Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
  • IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (Mehrere Adoptions-Rückblicke – Sekundärquelle.) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
  • Netflix Spinnaker / Spotify Backstage – Vorbilder für Plattform-als-Produkt.
  • AutoTrader UK – ein von TT offiziell zitierter Adoptionsfall (Detail-Link unter teamtopologies.com folgt).
  • Offizielle Fallbibliothek: https://teamtopologies.com/examples