+180 XP

Retention & Team-Topologien

Retention und Team-Topologien

2019 stieß die Data-Organisation von Spotify an eine Wand, an die früher oder später fast jeder CDO stößt. Das Unternehmen hatte sein berühmtes „Squad“-Modell auf Data übertragen und Analysten und Engineers direkt in die Produkt-Tribes eingebettet. Für Geschwindigkeit funktionierte das hervorragend, für das Handwerk furchtbar. Data Engineers berichteten an Product Manager, die ihre Arbeit nicht bewerten konnten, Karrierepfade verschwanden, und die Leute, die dimensionale Modellierung am besten verstanden, sollten Dashboards für den nächsten Sprint ausliefern. Die Abwanderung unter erfahrenen Data-Talenten stieg. Die Lösung war nicht, mehr Leute einzustellen. **Sie lag darin, die *Topologie* neu zu verdrahten, also die Struktur des Teams im Verhältnis zum Business, das es bedient**.

Genau das ist die Falle. Die meisten CDOs behandeln Organisationsstruktur als einmalige Entscheidung im Rahmen einer Reorg und Retention als HR-Problem, das man mit Comp-Bändern löst. Es ist dasselbe Problem. Wie Sie das Team verdrahten, bestimmt, wer ausbrennt, wer stagniert und wer geht. Ihr Operating Model ist Ihre Retention-Strategie, ob Sie es so entworfen haben oder nicht.

Die drei Topologien und ihre Failure Modes

Die drei Archetypen kennen Sie bereits. Was Sie brauchen, ist ein klarer Blick darauf, **was jede einzelne *Sie an Menschen kostet*, denn jede Topologie optimiert auf etwas und besteuert im Stillen etwas anderes**.

Zentralisiert bündelt alle Data-Talente in einer Funktion, die an den CDO berichtet. Der Retention-Vorteil ist real: starke Craft-Kultur, klare Karrierepfade, erfahrene Leute, die Junioren mentoren, und Peer Review, das die Standards hoch hält. Hier will tiefes technisches Talent arbeiten. Der Failure Mode ist die Ticket-Queue. Das zentrale Team wird zum Order-Taker, abgeschnitten vom Business-Kontext, überrollt von Anfragen, die es nicht priorisieren kann. Engineers erleben ihre Arbeit als endloses Eingangsformular. Die Besten, die Impact wollen und nicht Throughput, gehen zuerst. Sie behalten das Handwerk, verlieren aber die Relevanz, und irgendwann umgeht das Business Sie, indem es Shadow-Analysten einstellt.

Embedded setzt Data-Leute in die Business Units, mit Berichtslinie in diese Units. Der Retention-Vorteil ist Kontext und Sichtbarkeit, Analysten sehen ihren Impact direkt und Business-Leader kämpfen darum, sie zu behalten. Der Failure Mode ist das, was Spotifys frühes Modell erledigt hat: professionelle Isolation. Ein einzelner Data Scientist in der Marketing-Organisation hat niemanden, von dem er lernen kann, kein Code Review, keinen Karrierepfad, der etwas bedeutet, und einen Manager, der ihn nach Reaktionsgeschwindigkeit statt nach Sorgfalt bewertet. Fähigkeiten verkümmern. Man erreicht ein Plateau. Man merkt, dass man woanders schneller wachsen würde, und geht.

Hub-and-Spoke versucht, beides einzufangen: Ein zentraler Hub verantwortet Plattform, Standards und Karriereentwicklung, während die Spokes im Business sitzen. Der Retention-Vorteil ist, dass es Kontext und Handwerk gleichzeitig liefern *kann*. Aber es hat den subtilsten und gefährlichsten Failure Mode, den Whipsaw der doppelten Berichtslinie. Wenn Hub und Spoke beide echte Autorität über dieselbe Person haben, absorbiert diese Person den Konflikt. Ihr Business-Lead will das Modell am Freitag ausgeliefert haben, ihr Funktions-Lead will das Peer Review und die Dokumentation. Der Mitarbeiter wird zur Verhandlungsfläche für eine ungelöste organisatorische Meinungsverschiedenheit. Das ist eine leise, mahlende Quelle von Burnout, die in keiner Engagement-Umfrage auftaucht, bis das Kündigungsschreiben kommt.

Die Beurteilung lautet: Es gibt keine richtige Topologie, nur eine richtige Passung zwischen Topologie und der Data Maturity Ihrer Organisation plus der Volatilität Ihrer Nachfrage.

  • Frühe Maturity, exploratives Demand → zentralisiert. Sie müssen Handwerk und Standards aufbauen, bevor Sie Talente sicher verteilen können. Schwaches Talent ins Business zu verteilen, vervielfacht nur schlechte Muster.
  • Hohe Maturity, stabiles und gut verstandenes Demand → embedded funktioniert, weil Plattform und Standards im Tooling verankert sind und nicht von der Nähe zu erfahrenen Peers abhängen.
  • Hohe Maturity, hohe Demand-Volatilität über viele Units → Hub-and-Spoke, aber nur, wenn Sie das Problem der Berichtslinien lösen können, was die meisten Unternehmen nicht tun.

Wie Hub-and-Spoke tatsächlich funktioniert

Da die meisten CDOs in der Deepen-Phase bei Hub-and-Spoke landen, gehen wir tief in den Mechanismus, der darüber entscheidet, ob es Menschen hält oder abstößt: die Berichtslinie und die Beförderungshoheit.

Die wichtigste Einzelentscheidung ist, *wem die Karriere gehört*. Meine klare Empfehlung: Dem Hub gehört die Karriere, dem Spoke die Mission. Konkret: Ein Data Scientist, der in Supply Chain eingebettet ist, hat eine durchgezogene Berichtslinie in die Data-Funktion (Manager, Reviews, Beförderungen, Gehaltserhöhungen) und eine gepunktete Linie zum Supply-Chain-Leader (Prioritäten, Roadmap, Tagesgeschäft). Das ist die Umkehrung dessen, was Spotify ursprünglich getan hat, und es ist die Korrektur, auf die sie zugesteuert sind.

Warum so? Weil Karriereentwicklung jemanden braucht, der *das Handwerk bewerten kann*. Ein Supply-Chain-VP kann nicht faire beurteilen, ob Ihr Feature Engineering sauber ist. Wenn die Person, die Beförderungen abzeichnet, die Arbeit nicht beurteilen kann, passieren zwei Dinge: technische Exzellenz wird nicht mehr belohnt und politisch sichtbare Arbeit wird überbelohnt. Beides treibt Ihre besten Builder hinaus.

Aber die gepunktete Linie zum Business muss *Zähne* haben, sonst erzeugen Sie das zentralisierte Ticket-Queue-Problem neu. Geben Sie dem Business-Leader:

  • Eine benannte Allokation (z. B. „2,5 FTE Data Science für die nächsten zwei Quartale“), für die er die Roadmap kontrolliert.
  • Input in Performance Reviews, eine formale, gewichtete Stimme, kein Abnicken.
  • Die Möglichkeit, Prioritätskonflikte an ein gemeinsames Forum mit dem CDO zu eskalieren.

Hier ist ein leichtgewichtiger Weg, die Allokation explizit zu machen, statt sie zur Quelle permanenter Nachverhandlung werden zu lassen:

yaml
# Q3 data allocation — Supply Chain spoke
spoke: supply_chain
business_sponsor: vp_operations
allocation:
  data_scientist: 2.0   # durchgezogene Linie zu Data, gepunktet zu Ops
  analytics_engineer: 1.0
review_split:            # Gewichtung im Performance Review
  hub_manager: 0.6       # verantwortet Handwerk, Karrierepfad, Wachstum
  business_sponsor: 0.4  # verantwortet Impact, Prioritäten
escalation_path: cdo_ops_council   # tagt zweiwöchentlich

Die Zeile review_split ist der ganze Punkt. Wenn es aufgeschrieben ist, 60/40, und nicht „das klären wir dann“, weiß der Mitarbeiter genau, wem er für was Rechenschaft schuldet, und die Ambiguität, die den Whipsaw-Burnout verursacht, verschwindet. Sie haben eine zwischenmenschliche Verhandlung, die der Mitarbeiter führen musste, in eine Governance-Regel verwandelt, die die Führungskräfte verantworten.

Team Topologies in 5 Minutes

Watch on YouTube

Cognitive Load ist die Retention-Metrik, die Sie nicht messen

Die nützlichste Idee aus der Team-Topologies-Literatur ist Cognitive Load, die gesamte mentale Last, die ein Team trägt. Data-Teams scheitern auf dieser Achse permanent, weil sie Verantwortlichkeiten anhäufen wie ein Hoarder: Dieses Team verantwortet drei Pipelines, zwei Dashboards, ein ML-Modell, den Metrics Layer, Ad-hoc-Anfragen von vier Stakeholdern *und* die On-Call-Bereitschaft. Kein einzelner Punkt ist unvernünftig. Die Summe erdrückt.

Wenn Sie Spokes designen, begrenzen Sie ihre Cognitive Load explizit. Ein Spoke, der eine Domäne verantwortet (etwa Marketing Analytics), sollte nicht *zusätzlich* für die Plattformwartung zuständig sein, die gehört zum Hub als „Platform Team“, dessen ganze Aufgabe darin besteht, die Cognitive Load aller anderen über Self-Service-Tooling zu senken. Wenn Ihre embedded Analysten um 23 Uhr Airflow debuggen, ist Ihre Topologie kaputt, ganz unabhängig vom Organigramm, denn Sie haben Plattformlast auf Delivery-Teams verschoben. Das ist das Burnout-Signal Nummer eins in Data-Organisationen, und es ist strukturell, nicht persönlich.

Retention als Design-Problem, nicht als Perk-Problem

Comp bringt Leute in die Tür und verhindert die zynischsten Abgänge, aber auf Senior-Ebene ist Comp Table Stakes, Ihre Wettbewerber ziehen mit. Menschen mit seltenen, mobilen Fähigkeiten gehen aus drei Gründen, die das Organigramm kontrolliert: abgewürgtes Wachstum, bedeutungslose Arbeit und Managerqualität. Die Topologie treibt alle drei.

Wachstum. In einem rein embedded Modell stockt Wachstum, weil es keinen Karrierepfad und keinen Peer zum Lernen gibt. Die strukturelle Lösung ist ein Hub, der einen echten technischen Karriereweg unabhängig von der Business-Hierarchie betreibt, einen Staff/Principal-Pfad, auf dem ein IC mehr verdienen kann als ein Manager. Ohne das stoßen Ihre besten Engineers an die Decke von „Senior“, und der einzige Weg nach oben führt ins Management, in dem viele von ihnen schlecht sind und das keiner von ihnen wollte. Sie verlieren sie an ein Unternehmen, das einen Principal-Titel anbietet.

Sinnvolle Arbeit. Hier kommt Rotation ins Spiel. Ein Data Scientist, der drei Jahre im selben Spoke festhängt und dasselbe Churn-Modell optimiert, langweilt sich, unabhängig von der Comp. Bauen Sie einen Rotationsmechanismus in die Topologie ein: Alle 18 bis 24 Monate kann ein IC zwischen Spokes wechseln und behält dabei sein Hub-Zuhause und seine Position auf dem Karrierepfad. Weil dem Hub die Karriere gehört, setzt der Wechsel die Entwicklung nicht zurück, er bereichert sie. Das ist nur in Hub-and-Spoke möglich, es ist die unterschätzte Retention-Superkraft des Modells. Rotation verteilt außerdem institutionelles Wissen und reduziert das Bus-Factor-Risiko, dass eine Person eine kritische Domäne allein verantwortet.

Managerqualität. Der Hub-Manager, dem die Karrieren gehören, muss Data-Arbeit tatsächlich managen und bewerten können. Das heißt, Ihre Führungsspanne zählt enorm. Ein Hub-Lead mit 15 direkten Reports verteilt über 6 Spokes kann niemanden mentoren, er wird zum Genehmigungs-Bottleneck. Halten Sie Hub-Manager bei 5 bis 7 Reports. Wenn Sie das nicht können, haben Sie keine Managementstruktur, sondern eine Buchhaltungsstruktur.

Ein weiterer struktureller Retention-Hebel: Schützen Sie einen Teil der Kapazität für das Handwerk. Delivery-Druck im McKinsey-Stil wird 100 % der Zeit Ihres Teams mit Business-Anfragen verbrauchen, wenn Sie es zulassen, und ein Team, das nie refactored, nie ein neues Tool lernt, nie Tech Debt abbaut, ist ein Team, das langsam verlernt, und fähige Leute merken, wie sie dümmer werden. Formalisieren Sie es. Zwanzig Prozent der Spoke-Kapazität sind eingezäunt für Plattformbeiträge, Lernen und Debt-Reduzierung, verteidigt im Eskalationsforum. Das ist kein Benefit, das ist die Art, wie Sie verhindern, dass das Asset abschreibt.

Wissenscheck

1. Was ist das zentrale Argument der Lektion zum Verhältnis von Organisationsstruktur und Retention?

2. Warum gehen in der zentralisierten Topologie tendenziell die besten Engineers zuerst, wenn der Failure Mode einsetzt?

3. Ein einzelner Data Scientist in einer Marketing-Organisation wird von seinem Manager nach Reaktionsgeschwindigkeit statt nach Sorgfalt bewertet. Welches Konzept illustriert das?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Retention-Vorteile, die die Lektion der ZENTRALISIERTEN Topologie zuschreibt.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie auf Basis der Lektion ALLE Aussagen, die korrekt beschreiben, wie jede Topologie den Menschen versteckte Kosten auferlegt.

Wählen Sie alle richtigen Antworten aus.

Die Signale lesen und handeln

Topologien sind nicht dauerhaft. Die eigentliche Fähigkeit des CDO ist zu wissen, *wann* die aktuelle Struktur ihre Passung überlebt hat, und neu zu verdrahten, bevor Abwanderung Ihnen die Hand führt. Achten Sie auf diese Signale:

  • Zunehmende „Shadow Data“-Einstellungen in Business Units → Ihr zentrales Team ist zur Ticket-Queue geworden. Das Business umgeht Sie. Zeit für Embedding oder Spokes.
  • Doppelte, inkonsistente Metriken über Units hinweg → Sie haben zu stark embedded ohne starken Hub. Standards sind fragmentiert. Holen Sie Plattform und Definitionen ins Zentrum zurück.
  • Speziell Abwanderung von Senior ICs → prüfen Sie Ihren Karrierepfad und Ihre Review-Hoheit. Ihre besten Leute gehen, weil Handwerk nicht belohnt wird, und das ist fast immer ein Problem der Berichtslinie.
  • On-Call-Beschwerden und Pipeline-Feuerlöschen nach Feierabend → Fehlallokation der Cognitive Load. Ihre Delivery-Teams tragen Plattformlast. Bauen Sie ein Platform Team auf oder stärken Sie es.

Wenn Sie umstrukturieren, sequenzieren Sie es so, dass Menschen geschützt sind. Verkünden Sie das *Warum* vor dem *Wer*. Reorgs, die Berichtslinien umschichten ohne die Logik zu erklären, werden als Bedrohung gelesen, und die Ersten, die während einer ambigen Reorg gehen, sind genau die mit Optionen, Ihre Besten. Benennen Sie die neue Topologie, benennen Sie, welches Problem sie für das Team löst (nicht nur für das Business), und geben Sie den Leuten in der ersten Woche ein klares Bild von ihrem neuen Manager, ihrem Karrierepfad und ihrer Mission. Ambiguität während der Transition ist das Teuerste, was Sie zulassen können, denn Ihr Talentmarkt bepreist sie als Risiko und geht.

Key Takeaways

  1. Passen Sie die Topologie an Maturity und Demand-Volatilität an, nicht an Mode. Zentralisieren Sie, um früh Handwerk aufzubauen, wechseln Sie zu Hub-and-Spoke, wenn Sie reifer werden und das Demand über Units fragmentiert. Die Topologie *ist* Ihre Retention-Strategie.
  1. In Hub-and-Spoke gehört dem Hub die Karriere, dem Spoke die Mission, und der Review-Split wird aufgeschrieben (z. B. 60/40). Explizite Gewichtung eliminiert den Whipsaw der doppelten Berichtslinie, der Ihre besten Leute leise ausbrennt.
  1. Behandeln Sie Cognitive Load als Metrik erster Klasse. Lassen Sie Delivery-Spokes niemals Plattformwartung tragen. Feuerlöschen nach Feierabend ist ein strukturelles Versagen, kein persönliches, beheben Sie es, indem Sie ein Platform Team aufbauen, dessen Aufgabe die Lastsenkung für alle anderen ist.
  1. Bauen Sie einen echten Staff/Principal-IC-Pfad und einen Rotationsmechanismus über 18 bis 24 Monate. Das sind die Retention-Superkräfte von Hub-and-Spoke: Wachstum, ohne Leute ins Management zu zwingen, und neuer Sinn, ohne Karrieren zurückzusetzen.
  1. Zäunen Sie 20 % der Kapazität für das Handwerk ein und lesen Sie Abwanderungssignale als Topologie-Diagnostik. Abgänge von Senior ICs deuten auf Probleme der Berichtslinie, Shadow Hiring deutet auf ein zentrales Team in der Ticket-Queue. Verdrahten Sie neu, bevor die Abwanderung die Entscheidung erzwingt, und verkünden Sie immer das *Warum* vor dem *Wer*.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Die Topologie des Operating Model an die Reife anpassen: von zentralisiert hin zu Hub-and-Spoke entwickeln
  • Eine zweigleisige IC-Laufbahn aufbauen und über interne Beförderungsquoten messen
Vollständiges Action Playbook ansehen →