Cognitive Load messen — was Team Topologies nicht zu Ende denkt

Wenn ich in Team-Workshops frage, wie hoch die kognitive Last im Team gerade ist, bekomme ich meistens eine von zwei Antworten. Entweder ein Schulterzucken. Oder eine Zahl aus der Hüfte — „sieben von zehn” — gefolgt von einem leicht verlegenen Lachen. Beides ist ehrlich. Und beides zeigt dasselbe: Cognitive Load ist in den meisten Organisationen ein Begriff, kein Instrument.

Das ist erstaunlich, denn das Konzept steht im Zentrum eines der einflussreichsten Organisations-Bücher der letzten Jahre. Matthew Skelton und Manuel Pais machen in Team Topologies die kognitive Last zum Dreh- und Angelpunkt für Teamschnitt, Platform-Design und Interaktionsmuster. Die These ist klar: Überlastete Teams produzieren schlechte Architektur, schlechte Entscheidungen und schlechte Stimmung. Die Konsequenz wäre genauso klar — man müsste die Last messen können, um sie zu steuern.

Genau hier hat das Buch seinen blinden Fleck. Cognitive Load wird postuliert, nicht operationalisiert. Und solange wir sie nicht messen, bleibt die Idee Folklore.

Was Team Topologies verspricht — und was nicht

Skelton und Pais übernehmen das Konzept der kognitiven Last aus der Arbeit des Kognitionspsychologen John Sweller und übertragen es auf Teams. Ein Team hat eine endliche Kapazität, Komplexität zu halten. Wenn diese Kapazität überschritten wird, entstehen Abkürzungen, Fehler und irgendwann Resignation. Die Konsequenz: Teamgrenzen, Platform-Services und Enabling Teams sollten so gestaltet sein, dass die Last pro Team in einem tragbaren Bereich bleibt.

So weit die Theorie. In der Praxis verweisen die Autoren auf eine Team Cognitive Load Assessment-Vorlage — im Kern eine Selbstauskunft, bei der das Team auf einer Skala von 1 bis 10 einschätzt, wie überlastet es sich fühlt. Das ist besser als nichts. Aber es ist kein Messinstrument, es ist ein Stimmungsbild.

Das ist keine Kritik an den Autoren. Sie haben pragmatisch abgekürzt, weil die Alternative — eine saubere Operationalisierung — ein eigenes Buch füllen würde. Aber wer Team Topologies ernst nimmt, muss diesen Schritt selbst gehen.

Sweller in fünf Minuten

Bevor wir über Messung reden, lohnt sich ein Blick auf die Theorie, die dahintersteht. John Sweller hat 1988 die Cognitive Load Theory formuliert — ursprünglich für den Unterrichtskontext, aber mit erstaunlich guter Übertragbarkeit auf Wissensarbeit.

“

Working memory is limited. Problem solving requires that limited resource to be used efficiently — or not at all.

Sweller unterscheidet drei Arten von kognitiver Last:

• Intrinsic Load: Die inhärente Komplexität der Aufgabe selbst. Ein Zahlungssystem ist komplexer als ein Blog. Daran ist nichts zu ändern — intrinsische Last ist der Preis der Domäne.
• Extraneous Load: Vermeidbare Last durch schlechte Werkzeuge, unklare Prozesse, widersprüchliche Anforderungen oder Reibung an den Teamgrenzen. Das ist die Last, die wir senken können und müssen.
• Germane Load: Die produktive Last — Lernen, Verstehen, das Bauen mentaler Modelle. Die einzige Art von Last, die man mehr haben möchte, nicht weniger.

Die zentrale Einsicht: Das Arbeitsgedächtnis ist ein Nullsummenspiel. Jede Einheit extraneous Load frisst Kapazität, die für germane Load — also echtes Lernen — fehlt. Ein Team, das den ganzen Tag mit einer kaputten CI-Pipeline kämpft, wird nicht besser in seiner Domäne. Es wird nur müder.

Für die Messung heißt das: Wir brauchen Proxies für genau diese drei Arten. Und wir brauchen sie in Daten, die ohnehin im Team anfallen — sonst wird Messen selbst zur extraneous Load.

Warum Velocity, Story Points und Ticket-Zähler nichts aussagen

Die erste Versuchung ist groß: Wir haben doch bereits Metriken. Velocity, Durchlaufzeit, WIP, Burn-Down. Warum nicht einfach die für Cognitive Load heranziehen?

Weil sie das Falsche messen.

Velocity misst Output, nicht Last. Zwei Teams mit gleicher Velocity können völlig unterschiedliche Lastprofile haben — das eine läuft im Wohlfühltempo, das andere am Limit. Durchlaufzeit misst das System, nicht das Team. Ein Ticket, das vier Wochen liegt, kann an einem überlasteten Team liegen oder an einem Abhängigkeitsproblem. WIP ist näher dran, aber zählt Einheiten — nicht, was diese Einheiten kosten.

Das Kernproblem: Alle diese Metriken wurden entworfen, um Lieferung zu optimieren. Kognitive Last ist aber kein Lieferungs-, sondern ein Kapazitäts-Phänomen. Man kann sie nicht an dem ablesen, was aus dem Team herauskommt — man muss hinschauen, was im Team passiert.

Wir brauchen also andere Proxies. Die drei Metriken, die ich im Folgenden vorstelle, sind keine Erfindung — sie fallen in den meisten Teams ohnehin an, werden aber selten unter dem Gesichtspunkt der kognitiven Last zusammengelesen. Das Ganze ist bewusst kein geschlossenes Messmodell. Es ist ein pragmatisches Raster aus Indikatoren, die jeweils einen anderen Aspekt der Last beleuchten und zusammengenommen ein tragfähiges Bild ergeben.

Drei Metriken, die ohnehin anfallen

1. Context-Switch-Rate

Der präziseste Indikator für extraneous Load ist die Häufigkeit, mit der Teammitglieder zwischen unzusammenhängenden Kontexten wechseln müssen. Gloria Mark hat in ihren Studien zur Wissensarbeit gezeigt, dass nach einer Unterbrechung im Schnitt 23 Minuten vergehen, bis die ursprüngliche Konzentration wiederhergestellt ist. Wer diese Rechnung ein paar Mal pro Tag durchspielt, kommt schnell zu dem Ergebnis, dass ein großer Teil des Arbeitstags gar nicht für produktive Arbeit zur Verfügung steht.

Die Context-Switch-Rate lässt sich mit Daten erfassen, die ohnehin anfallen:

• Aktive Tickets pro Person und Woche (aus dem Ticketsystem). Alles über drei gleichzeitig aktive Themen ist ein Warnsignal.
• Meeting-Fragmentierung (aus dem Kalender). Wie viele zusammenhängende 90-Minuten-Blöcke bleiben in einer Arbeitswoche übrig? Bei den meisten Teams, die ich sehe, ist das eine einstellige Zahl.
• Anzahl unterschiedlicher Repositories oder Services pro Person und Woche (aus Commit-Historie oder Deployment-Logs). Wer in fünf Services arbeitet, hält fünf mentale Modelle.

Die Zahlen sind nicht absolut zu interpretieren. Ein Team, das bewusst als Collaboration-Modus nach Skelton/Pais arbeitet, darf fragmentierter sein — so lange der Modus bewusst gewählt und zeitlich begrenzt ist. Der Alarm geht an, wenn Fragmentierung der Normalzustand ist und niemand mehr merkt, dass es anders sein könnte.

2. Onboarding-Kurve

Der unbestechlichste Indikator für intrinsische Last ist die Zeit, die neue Teammitglieder brauchen, um produktiv zu werden. Ein Team, in dem Onboarding drei Wochen dauert, trägt eine andere Last als eines, in dem sechs Monate normal sind.

Drei Meilensteine lohnen sich, zu messen — idealerweise als Median über die letzten vier bis sechs Onboardings:

• Zeit bis zum ersten produktiven Beitrag: Erster gemergter PR, erster Ticket-Abschluss, erstes Deployment — was immer im Team als Signal dient.
• Zeit bis zur selbständigen Change: Ab wann kann die Person ein Feature eigenverantwortlich — ohne Pairing, ohne ständiges Rückfragen — abliefern?
• Zeit bis zur vollen operativen Verantwortung: Ab wann kann die Person Fehler in Produktion eigenständig einordnen und beheben — ohne Rückfall auf ein bestimmtes Original-Teammitglied?

Die letzte Zahl ist die härteste — und die aussagekräftigste. Denn sie misst nicht nur Einarbeitung, sondern Tiefe des notwendigen Modells. In Teams mit gesunder Last liegen zwischen Punkt eins und Punkt drei Wochen. In Teams mit überhöhter intrinsischer Last liegen Monate dazwischen — und manchmal wird der dritte Punkt nie erreicht, weil vorher jemand wieder geht.

3. Druck aus operativer Verantwortung

Die dritte Metrik ist am stärksten kontextabhängig — aber dort, wo sie greift, liefert sie die ehrlichsten Signale. Überall, wo ein Team die operative Verantwortung für das trägt, was es gebaut hat, wird systemische Überlast früh sichtbar. Das kann ein klassischer Bereitschaftsdienst sein, muss es aber nicht: eine Incident-Rotation innerhalb der Arbeitszeit, ein Supportkanal, den das Team selbst bedient, oder die schlichte Regel, dass Produktionsfehler im eigenen Team liegen. Das Muster ist dasselbe — wenn ein Team die Konsequenzen seiner Arbeit selbst spürt, wird unzureichend abstrahierte Komplexität messbar.

Was es lohnt anzuschauen:

• Dichte und Verteilung operativer Unterbrechungen. Nicht die absolute Zahl — sondern wie konzentriert diese Unterbrechungen auf einzelne Personen fallen und wie oft sie produktive Arbeitsblöcke zerschneiden.
• Transferfähigkeit des Betriebswissens. Können Incidents und Supportfälle von Teammitgliedern bearbeitet werden, die das betroffene Teilsystem nicht selbst gebaut haben? Wenn nicht, lebt der Betrieb im Kopf einzelner.
• Belastbare Rotation. Wie viele Personen im Team können operative Verantwortung tatsächlich übernehmen — in der Breite, nicht nur auf dem Papier?

Für Teams ohne formalisiertes Betriebsmodell ist das eher ein Gedankenexperiment als eine Metrik: Wenn ihr heute die Verantwortung für den eigenen Code in Produktion selbst tragen müsstet — wie schmerzhaft wäre das? Die Antwort sagt oft mehr über die kognitive Last im Team als jede Retro.

Was folgt daraus praktisch?

Die drei Metriken liefern keine Wahrheiten, sondern Gesprächsanlässe. Ihr Wert entsteht erst dadurch, wie man sie nutzt:

• Als Diagnose, nicht als Bewertung. Die Zahlen sagen etwas über das System aus, in dem das Team arbeitet — nicht über die Personen im Team. Wer sie für Performance-Beurteilungen oder Bonus-Kopplungen heranzieht, macht genau den Fehler, vor dem die Cognitive Load Theory warnt: Sobald eine Zahl entscheidet, wer was bekommt, wird sie optimiert — nicht das dahinterliegende Phänomen.
• Als Zeitreihe, nicht als Momentaufnahme. Ein einzelner Wert sagt wenig. Entscheidend ist die Bewegung: Wächst der Druck, entspannt sich das Onboarding, stabilisiert sich die Fragmentierung? Und Teams lassen sich damit nicht gegeneinander vergleichen — ein Stream-aligned Team im Zahlungsverkehr wird andere Zahlen haben als ein Platform-Team, und soll das auch.
• Als Einstieg in Strukturfragen. Wenn eine Metrik dauerhaft rot leuchtet, ist selten das Team das Problem. Die Antwort liegt weiter oben: Teamzuschnitt, Plattformunterstützung, Schnittstellen zu Nachbarteams, WIP-Grenzen, Meeting-Last, Betriebsmodell. Genau die Hebel, die Team Topologies adressiert.
• Im richtigen Raum besprochen. Die Zahlen gehören ins Team und — mit Sorgfalt — zu den Menschen, die für Organisationsdesign verantwortlich sind. Nicht in HR-Systeme, nicht in Steuerungsgremien, nicht in Quartals-Decks. Sobald sie in eine andere Logik überführt werden, verlieren sie ihre diagnostische Qualität.

Fazit

Team Topologies hat Cognitive Load als Begriff in den Mainstream gebracht — und genau darin liegt die Gefahr. Ein Begriff, der überall verwendet und nirgends beobachtet wird, verliert seine Schärfe. Dann steht er am Ende in jedem Organigramm-Workshop auf einem Post-it, ohne dass sich an der Realität des Teams irgendetwas ändert.

Wer die Idee wirklich nutzen will, kommt um drei Perspektiven nicht herum: sich ehrlich anschauen, wo extraneous Last entsteht (Context-Switch-Rate); sehen, wie tief das notwendige Wissensmodell ist (Onboarding-Kurve); und dorthin schauen, wo operative Verantwortung die Qualität des Systems ungeschönt sichtbar macht.

Keine dieser Metriken ist perfekt. Jede ist ein Proxy, jede hat Bias, jede lässt sich missbrauchen. Aber sie haben einen entscheidenden Vorteil gegenüber der 1-bis-10-Skala aus dem Buch: Sie liegen in Daten, die ohnehin entstehen. Wir müssen sie nur anschauen — und das Gespräch dorthin tragen, wo es hingehört.

Ein Framework ist so gut wie die Fragen, die es uns zwingt zu stellen. Cognitive Load ist eine der wichtigsten dieser Fragen. Sie verdient eine bessere Antwort als ein Schulterzucken.

---

Neugierig, wie man Cognitive Load im eigenen Team operationalisiert? In unseren Schulungen zu Team Topologies und Agile Coaching arbeiten wir genau an diesen Fragen — mit Teams, die das Buch gelesen haben und jetzt wissen wollen, wie sie davon in der Praxis profitieren.