Wird die Lieferung immer wieder blockiert oder gebremst, ohne dass der Grund klar ist? In dieser Lightning Lesson stellten Giuseppe De Simone und Simon Sablowski ein einfaches, kollaboratives Werkzeug vor, mit dem Abhängigkeiten zwischen Teams sichtbar werden und ein gemeinsames Verständnis der damit verbundenen Koordinationskosten entsteht. Als Beispiel wurde ein Feature-Wunsch über fünf Teams hinweg abgebildet, um zu zeigen, woher Koordinationskosten kommen und was sich ändert, wenn Teamgrenzen am Ergebnis statt an technischen Schichten oder Domänen ausgerichtet werden.

Die Aufzeichnung zeigt, wie sich Folgendes umsetzen lässt:

  • Grenzen erkennen, die Koordinationskosten verursachen. Es wird sichtbar, wo Teamgrenzen in der aktuellen Struktur unnötige Übergaben, Verzögerungen und Overhead erzeugen.
  • Teamübergreifende Abhängigkeiten sichtbar machen. Versteckte Abhängigkeiten werden aufgedeckt, bevor sie als Blocker im Lieferfluss auftauchen.
  • Das passende Koordinationsmuster wählen. Es wird bewertet, welche Muster zum tatsächlichen Kontext passen und welche still und leise alles verlangsamen.

Zur Aufzeichnung (englisch)

Die wichtigsten Erkenntnisse

1. Vier Fragen, bevor das Organigramm angefasst wird

Vor jeder organisatorischen Neugestaltung skizzierte Giuseppe vier strategische Entscheidungen, die alles Weitere prägen. Es sind keine Frameworks, sondern Fragen, bei denen sich ein längeres Nachdenken lohnt:

  • Was ist „unser Produkt“? Eine Bank kann Internetbanking als ein Produkt betrachten oder bis hinunter zu getrennten Kreditkarten-Apps für iOS und Android aufteilen. Breitere Definitionen bedeuten weniger, aber komplexere Teams mit einem ganzheitlicheren Blick auf Prioritäten; engere Definitionen sind einfacher zu führen, bergen aber das Risiko der Suboptimierung.
  • Komponententeams oder Feature-Teams? Wer nach technischer Schicht aufteilt (Frontend, Backend, Hardware), setzt die kompetentesten Menschen auf jeden Teil. Kund:innen formulieren ihre Anforderungen jedoch nicht höflich innerhalb einer Schicht, sodass Abhängigkeiten systembedingt entstehen. Feature-Teams vermeiden das, erfordern aber Investitionen in breitere Kompetenz im Team.
  • Effizienz oder Effektivität? Eine Aufteilung nach Fähigkeiten optimiert die Effizienz; interdisziplinäre Teams mit Ende-zu-Ende-Verantwortung optimieren die Effektivität.
  • Ein Product Owner pro Team oder pro Produkt? Pro Team ist im Alltag einfacher, doch je mehr Product Owner es gibt, desto mehr Zeit geht für die Abstimmung der Backlogs untereinander drauf.

Keine dieser Entscheidungen ist kostenlos: Jede bringt Trade-offs mit sich, die in Kauf genommen und nicht vermieden werden.

2. Koordinationskosten sichtbar machen: Häufigkeit × Risiko = Kosten

Simon stellte eine einfache Übung zur Abbildung von Abhängigkeiten vor, die aus „Koordination fühlt sich teuer an“ eine konkrete Zahl macht. Ein realistisches Feature wird über alle betroffenen Teams hinweg nachverfolgt, und jede Abhängigkeit wird auf zwei Achsen von 1 bis 3 bewertet: Häufigkeit (wie oft die Teams interagieren müssen) und Risiko (wie viel schiefgehen kann). Das Produkt ergibt die Kosten pro Abhängigkeit. Abhängigkeiten gibt es in drei Varianten: technisch, Freigaben und wissensbasiert (etwa wenn eine einzelne Entwickler:in als Einzige ein Legacy-System versteht).

3. Wie eine Neugestaltung entlang von Ergebnissen aussieht

Das Beispiel war ein Feature, mit dem Kund:innen einen wiederkehrenden Nutzungsbericht planen können (CSV oder PDF, per E-Mail, nur für zahlende Tarife), aus Kundensicht simpel. In einer typischen Komponentenstruktur (Web-Frontend, Authentifizierung und Berechtigungen, Abrechnung, Daten und Reporting, Benachrichtigungen) berührte es fünf Teams mit sieben Abhängigkeiten, bei Gesamtkosten der Koordination von 38. Und das in einer gut geführten Organisation, in der niemand faul oder langsam ist.

Wurden Frontend, Daten und Reporting sowie Benachrichtigungen zu einem einzigen Team „Reporting und Insights“ zusammengelegt, sank die Zahl der Abhängigkeiten von sieben auf zwei. Diese zwei verbleibenden Abhängigkeiten wurden als veröffentlichte Self-Service-APIs formalisiert statt als spontane Slack-Threads und Pull-Request-Reviews, und die Gesamtkosten fielen von 38 auf 2. Gleicher Umfang, gleiche Arbeit, nur deutlich weniger Reibung auf dem Weg durch das System.

4. Das Kleingedruckte: was die Zahlen nicht erfassen

In der Q&A-Runde wurde das Modell produktiv hinterfragt, und die Einschränkungen sind ebenso wichtig wie das Werkzeug:

  • Es ist eine bewusste Vereinfachung: Der Wert liegt im Gespräch, das die Bewertung auslöst, nicht in der Genauigkeit der Zahlen.
  • Eine Neugestaltung allein an einem Feature auszurichten ist ein Fehler. Das Mapping sollte über vier oder fünf Features laufen, um die Struktur zu finden, die in den meisten Fällen funktioniert (eine „80-%-Lösung“, keine perfekte).
  • Das Verschieben von Menschen und das Zusammenlegen von Teams hat soziale und verhaltensbezogene Folgen, die das Modell überhaupt nicht abbildet.
  • Es ist ein Werkzeug, um fundierte Wetten zu platzieren, nicht um Experimente zu vermeiden: Was tatsächlich passiert, zeigt sich erst nach der Änderung.
  • Unachtsam eingesetzt, kann es zur Ausrede für ständige Reorganisation werden, die ihrerseits echte Kosten verursacht.

Warum das wichtig ist

Koordinationskosten sind fast immer verborgen: Sie leben als Frust in den Köpfen, nicht als Zahl an der Wand. Da KI das Tempo einzelner Menschen und Teams weiter erhöht, führt ein Operating Model mit veralteten Grenzen nur dazu, dass dieselben versteckten Abhängigkeiten früher getroffen werden. Sie sichtbar zu machen, selbst mit einer groben, unvollkommenen Bewertung, verwandelt ein diffuses Gefühl von Reibung in etwas, das ein Team besprechen, priorisieren und angehen kann.

Mehr erfahren? Giuseppe und Simon pilotieren im November einen vollständigen Kurs, Leading Coordination and Collaboration in AI-Accelerated Organisations, denn schnellere Teams brauchen Grenzen, die für das Tempo ausgelegt sind, zu dem sie inzwischen fähig sind. Wer Teil der ersten Kohorte sein oder mit Feedback mitgestalten möchte, kann sich gern melden.

Über die Vortragenden

Giuseppe De Simone ist Certified Trainer und Organisationscoach mit über 25 Jahren Erfahrung in Produktentwicklung und Transformationen im Enterprise-Maßstab. Er hat Führungskräfte in Organisationen gecoacht und trainiert, in denen die Lücke zwischen individueller Leistung und Lieferdurchsatz keine Theorie, sondern täglicher Alltag ist. Immer wieder sieht er dasselbe Muster: KI-Werkzeuge beschleunigen die individuelle Leistung, doch das Operating Model war nie für dieses Tempo ausgelegt, mit mehr statt weniger Reibung als Folge. Seine Arbeit konzentriert sich auf die Ebene, die die meisten überspringen: wie Entscheidungen fließen, wie Abstimmung zerbricht und wie Teams unter Druck koordinieren. Er ist Gründer und CEO seines Beratungs- und Trainingsunternehmens und Fellow Coach bei Better Change.

Simon Sablowski ist Berater für Koordination und Organisationsdesign und unterstützt Unternehmen dabei, die Ebene zwischen Menschen und Lieferung neu zu gestalten: die Strukturen, Grenzen und Muster, die bestimmen, wie schnell Entscheidungen fallen, wie Abhängigkeiten gesteuert werden und wie Teams in der Praxis tatsächlich koordinieren. Er arbeitet mit engineering-getriebenen Organisationen, die die Lücke zwischen individueller Leistung und Lieferdurchsatz überbrücken wollen, und konzentriert sich auf die strukturellen Ursachen, die die meisten Interventionen auslassen: wo Teamgrenzen verlaufen, wie Abhängigkeiten sichtbar werden und welche Koordinationsmuster zur tatsächlichen Arbeit passen, nicht nur zum Organigramm.