Best Practice & Anwendungsszenarien

Organisationskonzept nach General Stanley McChrystal

1. Einleitung: Was ist Team of Teams?

Das Konzept „Team of Teams“, maßgeblich von General Stanley McChrystal geprägt, ist der Goldstandard für Organisationen, die von einer starren Hierarchie zu einem agilen Netzwerk wechseln wollen. Es verbindet die Effizienz einer Pyramide mit der Anpassungsfähigkeit eines kleinen Teams.

Wichtiger Hinweis: „Team of Teams“ ist kein reines Strukturmodell, sondern ein Kulturmodell. Es scheitert oft dort, wo Führungskräfte nicht bereit sind, die Kontrolle abzugeben.

Die 4 Kernpfeiler des Erfolgs

Pfeiler	Beschreibung
Vertrauen	Teams müssen sich blind darauf verlassen, dass die anderen Einheiten im Sinne des Ganzen handeln.
Gemeinsame Absicht	Jeder Mitarbeiter, vom Praktikanten bis zum CEO, muss das übergeordnete Ziel verstehen.
Shared Consciousness	Radikaler Informationsfluss, der Silos durch tägliche, kurze Check-ins (O&I) ersetzt.
Empowered Execution	Entscheidungen werden dort getroffen, wo die Informationen am aktuellsten sind.

2. Internationale Success Stories

2.1 Joint Special Operations Task Force – Irak

Dies ist die Geburtsstunde des Konzepts. McChrystal stellte fest, dass die US-Streitkräfte trotz technischer Überlegenheit gegen die Al-Qaida im Irak (AQI) verloren, weil der Gegner schneller lernte und kommunizierte.

Transformation: Er brach Silos zwischen CIA, FBI und dem Militär auf.

Erfolg: Die Anzahl monatlicher Einsätze stieg von ca. 10 auf über 300 – bei gleichzeitig massiv gesteigerter Präzision.

2.2 General Electric (GE)

Unter der Führung von Chris Fussell implementierte GE Teile des Konzepts, um interne Bürokratie zu bekämpfen.

Transformation: GE Aviation synchronisierte Kommunikation zwischen Ingenieuren, Lieferketten-Managern und Vertrieb.

Erfolg: Entscheidungen, die früher Wochen dauerten, wurden auf Stunden verkürzt.

2.3 Intuit

Der Software-Riese (QuickBooks, TurboTax) stand vor der Herausforderung, dass Produktteams sich gegenseitig im Weg standen.

Transformation: Intuit schuf ein Netzwerk, in dem Daten und Erkenntnisse über Kundenbedürfnisse in Echtzeit geteilt wurden.

Erfolg: Wandel vom Desktop-Software-Unternehmen zur Cloud-Plattform. Die Innovationsrate stieg drastisch an.

2.4 Cleveland Clinic

Im Gesundheitswesen ist Koordination oft eine Frage von Leben und Tod. Die Cleveland Clinic nutzte Team-of-Teams-Prinzipien für die Patientenversorgung.

Transformation: Weg von der „Arzt-Zentrierung“ hin zu multidisziplinären Teams auf Augenhöhe.

Erfolg: Verbesserte Patientenzufriedenheit und signifikant reduzierte Fehlerquote bei Übergaben.

3. Deutsche Beispiele & IT-Systemhäuser

Das Konzept im deutschen Mittelstand zu finden ist spannend – die deutsche Unternehmenskultur ist oft noch sehr hierarchisch geprägt. Dennoch gibt es Vorreiter, auch unter dem Label „Agile Skalierung“ oder „Soziokratie“.

3.1 Sipgate (Düsseldorf) – Das IT-Musterbeispiel

Transformation: Klassische Abteilungen komplett abgeschafft. Stattdessen cross-funktionale Teams, die wie kleine Unternehmen im Unternehmen agieren.

Team-of-Teams-Ansatz: Koordination über ein engmaschiges Netz aus Open-Frühstücken, internen User Groups und radikalem Informationsfluss.

Erfolg: Extrem innovationsfähig und zieht Top-Talente an, während Wettbewerber mit klassischer Struktur träger reagieren.

3.2 Bosch – Connected Mobility Solutions

Transformation: Nutzung des Spotify-Modells (Tribes, Squads, Chapters) – im Kern eine Implementierung von Team of Teams.

Erfolg: Wissen wird über Chapters (Expertengruppen) geteilt, während Squads vollkommen autonom an ihren Produkten arbeiten.

3.3 Netlight & codecentric

Shared Consciousness (Netlight): Das „Edge“-Konzept – ein internes Wissensnetzwerk mit Echtzeit-Zugriff auf das Wissen tausender Kollegen weltweit.

Empowered Execution: Kaum klassische Hierarchien. Teams vor Ort entscheiden über technologische Stacks.

Erfolg: Beide Firmen wachsen organisch und gehören zu den profitabelsten Adressen in der IT-Beratung.

3.4 Warum das für IT-Systemhäuser besonders gut funktioniert

In einem Systemhaus ist Wissen oft in Köpfen von Spezialisten gefangen. Team of Teams löst das durch:

1. Tägliche Syncs (O&I): Ein kurzes, unternehmensweites Meeting (max. 15 Min.) zum Teilen der wichtigsten Blocker und Erkenntnisse.
2. Multidisziplinäre Teams: Techniker, Vertrieb und Support in einem Team für einen bestimmten Kundenstamm.
3. Radikale Transparenz: Alle Projektdaten und Dashboards für jeden Mitarbeiter einsehbar.

3.5 Hürden in Deutschland

Das „Kästchendenken“: Man will Agilität, aber der Arbeitsvertrag muss genau eine Stellenbeschreibung enthalten.

Haftung & Hierarchie: Viele Führungskräfte haben Angst, die Kontrolle zu verlieren, obwohl das System durch Shared Intent stabiler ist.

4. Das O&I-Meeting – Drehbuch für 6.000 Mitarbeitende

Bei 6.000 Mitarbeitenden in einer behördennahen Struktur ist das größte Gift die „Informationsasymmetrie“ – oben wird entschieden, was unten nicht verstanden wird, und unten existieren Probleme, von denen oben niemand weiß.

4.1 Rahmenbedingungen

• Teilnehmer: Ca. 50–70 „Liaisons“ (Vertreter der Fachbereiche, Key-Account-Manager, Projektleiter)
• Zuschauer: Der Rest der 6.000 Mitarbeitenden via Stream (transparent, aber stumm)
• Moderator: Ein „Facilitator“ (nicht zwingend der CEO!), der extrem streng auf die Zeit achtet

4.2 Ablauf: 09:00 – 09:30 Uhr

Phase 1: Lagebericht (09:00 – 09:10) – Shared Consciousness

09:00–09:03 | Strategischer Kontext (Management): „Wir haben gestern das Signal vom Ministerium erhalten, dass Projekt X Priorität 1 hat. Alle Ressourcenfragen werden ab heute daran gemessen.“

09:03–09:07 | Operatives Lagebild (SOC/Rechenzentrum): „Großstörung im Netzsegment Nord behoben, aber wir sehen instabile Latenzen. Wartungsfenster heute Nacht 22 Uhr bleibt bestehen.“

09:07–09:10 | Marktlage/Kunde (Vertrieb): „Ausschreibung für Rahmenvertrag Z ist raus. Wir brauchen bis Freitag Zuarbeit von der Security-Abteilung.“

Phase 2: Blocker & Vernetzung (09:10 – 09:25) – Identifikation, nicht Lösung

Teams melden Hindernisse. Regel: Keine Diskussion der Lösung im Meeting! Nur: „Wer muss mit wem reden?“

Beispiel: Team Cloud: „Wir kommen bei Projekt Alpha nicht weiter, weil uns die Freigabe vom Datenschutz fehlt. Wir hängen seit 2 Wochen fest.“

Reaktion: DSB-Liaison: „Ich nehme das mit. Ich brauche 5 Minuten mit dem Cloud-Lead direkt nach diesem Call.“

Phase 3: Sustained Momentum (09:25 – 09:30)

09:25–09:28 | Deep Dive (optional): Ein Team stellt kurz (3 Min.) eine neue Technologie oder einen Erfolg vor.

09:28–09:30 | Abschlusswort: Kurze Zusammenfassung der wichtigsten Erkenntnisse durch die Geschäftsführung (Context, not Control).

4.3 Die 3 Goldenen Regeln

• Redeverbot für Status-Updates: Es zählt nur Information mit Vorhersagewert für andere.
• Keine Hierarchie im Wortbeitrag: Der Junior-Admin mit dem kritischen Bug spricht vor dem Abteilungsleiter, wenn die Info wichtiger ist.
• „Beat the Bureaucracy“: Wenn ein Blocker benannt wird, ist es die Aufgabe des Managements, diesen Prozess sofort zu bypassen.

4.4 Warum das in einer „Behörde“ funktioniert

In klassischen Strukturen werden Probleme in Protokollen vergraben und über Wochen nach oben eskaliert. Im O&I-Meeting wird das Problem öffentlich. Wenn 500 Leute im Stream sehen, dass der Einkauf seit drei Wochen eine Unterschrift verweigert, entsteht ein gesunder sozialer Druck („Social Accountability“), der bürokratische Starre auflöst.

5. Ebenengerechte Kommunikation im Team of Teams

In einer behördennahen Struktur mit 6.000 Mitarbeitenden ist „ebenengerechte Kommunikation“ oft ein Codewort für Filterung. Im Team of Teams wird das radikal umgedeutet: Es geht nicht darum, was man vor wem verheimlicht, sondern darum, welchen Kontext die jeweilige Ebene benötigt.

Merksatz: Ebenengerecht im Team of Teams heißt: Gleiche Wahrheit, unterschiedliche Detailtiefe.

5.1 Von der „Holschuld“ zur „Kontext-Bringschuld“

Operative Ebene (Teams): Braucht technische Details und unmittelbare Abhängigkeiten (z.B. „Schnittstelle X ändert sich morgen“).

Mittleres Management (Ermöglicher): Braucht Infos über Ressourcen-Blocker und bereichsübergreifende Konflikte.

Top-Management (Strategen): Braucht das „Big Picture“ und externe Einflüsse (z.B. politische Prioritäten).

5.2 Vergleich: Klassisch vs. Team of Teams

Kommunikationstyp	Klassisch (Behörde)	Team of Teams
Richtung	Kaskadierend (Top-Down)	Synchron (Radial/Netzwerk)
Ziel	Kontrolle & Absicherung	Shared Consciousness
Ebenengerechtigkeit	Information vorenthalten/vereinfachen	Relevanz und Kontext stiften
Geschwindigkeit	Langsam (über Dienstwege)	Echtzeit (im gemeinsamen Call)

5.3 Das Context-Impact-Ask Schema (3-Satz-Regel)

Damit Techniker und Teamleiter im O&I-Meeting effizient kommunizieren, nutzen sie dieses Schema:

• Context (Was ist los?): „Wir migrieren gerade das Verzeichnisdienst-Backend für Kunde X.“
• Impact (Warum betrifft das andere?): „Es gibt Inkompatibilitäten, die heute Nachmittag alle VPN-Logins stören könnten.“
• Ask (Was brauche ich?): „Ich brauche bis 11:00 Uhr einen Netzwerk-Spezialisten für einen Quick-Check.“

5.4 Kommunikations-Matrix

Informationstyp	Team (lokal)	O&I (System)	Filter-Kriterium
Technik / IT	Bugfixes, Code-Reviews, interne Sprints	Kritische Infrastruktur-Änderungen, Sicherheitsvorfälle	Sobald ein anderes Team betroffen sein könnte
Ressourcen	Urlaubsplanung, interne Aufgabenverteilung	Kapazitätsengpässe bei Schlüssel-Experten	Wenn ein Projektstopp droht
Kunde / Stakeholder	Detail-Absprachen zu User Stories	Strategische Kursänderungen des Hauptkunden	Wenn die Änderung andere Teams beeinflusst
Blocker	Lokales Geräteproblem	Einkauf blockiert Cloud-Lizenzen seit 4 Wochen	Wenn Dienstweg versagt hat und Verzögerung > 5 Tage
Innovation	Neues Tool im Team getestet	Prozess-Template mit 50% Zeitersparnis	Wenn ein Standard für die gesamte Org gesetzt werden kann

5.5 Steuerung des Informationsflusses bei 6.000 Mitarbeitenden

Zwei Filter-Stufen halten das Modell stabil:

1. Team-Filter: Jedes der ca. 600 Teams (à 10 Personen) hält sein eigenes Daily. Nur systemrelevante Informationen werden an den Liaison Officer gemeldet.
2. Cluster-Filter (optional): Cluster wie „Public Sector“, „Internal IT“, „Cloud Services“ destillieren die 2-3 wichtigsten Punkte für das unternehmensweite O&I.

5.6 Die Rolle der Führungskraft in dieser Matrix

Kein Postbote: Sie leitet keine E-Mails mehr weiter.

Qualitätsmanager: Sie trainiert Mitarbeiter darin, Informationen „O&I-tauglich“ – ebenengerecht und präzise – aufzubereiten.

Blocker-Löser: Sobald im O&I ein Blocker identifiziert wurde, greift die Führungskraft zum Hörer, um den bürokratischen Knoten zu durchschlagen.

6. Die Rolle des Liaison Officers (LO)

In einer behördenartigen Struktur mit 6.000 Mitarbeitenden ist die Versuchung groß, einfach die bestehenden Abteilungsleiter als Liaison Officers zu bestimmen. Das ist oft ein Fehler.

Ein LO ist kein „Berichterstatter“, sondern ein Netzwerkknoten. Er muss die technische Tiefe verstehen, aber die politische Sprache der Organisation sprechen können.

6.1 Das Skill-Profil: „Der T-Shaped Kommunikator“

Tiefe Fachkenntnis (The „T“): Er muss verstehen, wenn ein Techniker sagt: „Das API-Gateway blockiert den Deployment-Cycle.“ Er darf nicht „bullshittable“ sein.

Synthese-Fähigkeit: Die Gabe, 60 Minuten technisches Chaos in 3 Sätzen für das Management zusammenzufassen.

Netzwerk-Autorität: Er braucht das Vertrauen seiner Basis. Wenn er eine Zusage macht, müssen seine Kollegen diese umsetzen.

6.2 Erforderliche Soft Skills

Low Ego: Es geht nicht um persönliche Profilierung, sondern um den Informationsfluss. Er muss bereit sein, Fehler offen zuzugeben.

Courage: Er muss bereit sein, Hierarchien zu ignorieren, wenn ein Blocker benannt wird – auch wenn das bedeutet, den Dienstweg zu verkürzen.

Aktives Zuhören: Er muss heraushören, wo andere Teams Probleme haben, die sein Team lösen könnte.

6.3 Ausschlusskriterien – Wer ist NICHT geeignet?

• Der Protokollant: Personen, die nur vorlesen, was auf einem Zettel steht, ohne den Kontext zu verstehen.
• Der Gatekeeper: Führungskräfte, die Informationen als Machtmittel horten und nur das „Schöne“ präsentieren.
• Der Detail-Verliebte: Experten, die sich in technischen Kleinstdetails verlieren und das Zeitlimit sprengen.

6.4 Die 5-Fragen-Probe zur Auswahl

1. Akzeptanz: Gehen die Techniker zu dieser Person, wenn es brennt?
2. Klarheit: Kann diese Person ein komplexes Problem einem fachfremden CEO in 60 Sekunden erklären?
3. Entscheidungskraft: Darf diese Person im Namen ihres Bereichs Ressourcen zusagen oder Prioritäten verschieben?
4. Belastbarkeit: Bleibt die Person ruhig, wenn kritische Fragen vor 6.000 Zuschauern gestellt werden?
5. Vernetzung: Kennt die Person die informellen Wege im Haus?

6.5 Strategischer Tipp: Rotation alle 6–12 Monate

Durch regelmäßige Rotation der LO-Rolle wird verhindert, dass sich neue „Silos der Kommunikatoren“ bilden. Nach zwei Jahren entsteht ein Korps von 100–200 Mitarbeitenden, die die gesamte Organisation verstanden haben.

7. Die Gardener-Rolle: Vom Schachspieler zum Gärtner

In der Team-of-Teams-Philosophie verschiebt sich die Rolle der obersten Führungsebene radikal: Vom Schachspieler zum Gärtner. Während der Schachspieler versucht, jede Figur selbst zu bewegen, konzentriert sich der Gärtner auf das Ökosystem.

Kernphilosophie: „Eyes On, Hands Off“ – Ein Gärtner lässt die Teams selbst wachsen. Er zieht nicht an ihnen (Mikromanagement), sondern sorgt dafür, dass die Bedingungen stimmen.

7.1 Die drei Hauptaufgaben des Gärtners

1. Den Boden bereiten (Kultur & Struktur)

Der Gärtner beseitigt strukturelle Gifte: Er identifiziert veraltete Dienstanweisungen oder Freigabeprozesse, die das Tempo drosseln, und schafft Ausnahmen für agile Teams durch. Ziel: Eine Umgebung, in der Vertrauen und Transparenz gedeihen können.

2. Wässern und Düngen (Ressourcen & Kontext)

Der Gärtner sorgt dafür, dass strategische Informationen ungefiltert bis an die Basis gelangen und Budgets sowie Prioritäten freigeschaufelt werden.

3. Unkraut jäten (Hindernisse entfernen)

Wenn im O&I-Meeting ein Blocker gemeldet wird, den Teams nicht selbst lösen können, greift der Gärtner ein – aber nicht fachlich, sondern um das Hindernis aus dem Weg zu räumen, damit das Team wieder eigenständig laufen kann.

7.2 Die 3 Todsünden des Gärtners im IT-Haus

1. Technical Deep Dive: Der Gärtner darf im O&I-Meeting nicht über die Wahl der Datenbank-Architektur diskutieren. Das ist Sache der Teams.
2. Einzelanweisungen: Er darf keine Befehle an einzelne Personen an den Teamleitern vorbei geben (Schachspieler-Modus).
3. Informations-Hortung: Ein Gärtner, der „Geheimwissen“ nutzt, um Macht auszuüben, vergiftet den Boden.

7.3 Selbsttest für das Management: Bin ich ein Gärtner?

Check	Frage	Ziel
Entscheidungs-Check	Wie viele Entscheidungen habe ich heute getroffen, die meine Teams selbst hätten treffen können?	Nahe Null
Hürden-Check	Welches bürokratische Hindernis habe ich heute aus dem Weg geräumt?	Mind. 1/Tag
Kontext-Check	Habe ich sichergestellt, dass meine Teams verstehen, WARUM wir dieses Projekt machen?	Täglich
Zuhör-Check	Habe ich im O&I-Meeting mehr Fragen gestellt als Antworten gegeben?	Fragen > Antworten

7.4 Warum das für 6.000 Leute überlebenswichtig ist

In einer Organisation dieser Größe kann eine Handvoll Schachspieler an der Spitze niemals die Komplexität von tausenden IT-Projekten erfassen. Sie werden zum Flaschenhals. Der Gärtner hingegen skaliert: Er schafft 600 kleine Treibhäuser (Teams), die alle autonom wachsen, weil er den Rahmen vorgibt.

Merksatz: Der Schachspieler ist stolz auf seine Züge. Der Gärtner ist stolz auf seine Ernte – die Ergebnisse der Teams.