# Retention and Team Topologies
In 2019, Spotify's data organization hit a wall that most CDOs eventually meet. The company had scaled its famous "squad" model into data—embeddingembeddingAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.Voir la définition complète → analysts and engineers directly inside product tribes. It worked beautifully for velocity and terribly for craft. Data engineers reported to product managers who couldn't evaluate their work, career ladders evaporated, and the people who understood dimensional modeling best were being asked to ship dashboards for the next sprint. Attrition among senior data talent climbed. The fix wasn't hiring more people. It was rewiring the *topology*—how the team was structured relative to the business it served.
This is the trap. Most CDOs treat org structure as a one-time decision made during a reorg and retention as an HR problem solved with comp bands. They're the same problem. The way you wire the team determines who burns out, who stagnates, and who leaves. Your operating model is your retention strategy, whether you designed it that way or not.
You already know the three archetypes. What you need is a clear-eyed view of what each one *costs you in people*, because every topology optimizes for something and quietly taxes something else.
Centralized puts all data talent in one function reporting up to the CDO. Its retention advantage is real: strong craft culture, clear career ladders, senior people who mentor juniors, and peer review that keeps standards high. This is where deep technical talent wants to live. The failure mode is the ticket queue. The central team becomes an order-taker, disconnected from business context, drowning in requests it can't prioritize. Engineers experience their work as an endless intake form. The best ones—who want impact, not throughput—leave first. You retain craft but lose relevance, and eventually the business routes around you by hiring shadow analysts.
Embedded places data people inside business units, reporting into those units. The retention advantage is context and visibility—analysts see their impact directly and business leaders fight to keep them. The failure mode is what killed Spotify's early model: professional isolation. A lone data scientist in the marketing org has no one to learn from, no code review, no ladder that means anything, and a manager who rates them on responsiveness rather than rigor. Skills atrophy. They plateau. They realize they'd grow faster elsewhere and go.
Hub-and-spoke tries to capture both: a central hub owns platform, standards, and career development while spokes embed in the business. The retention advantage is that it *can* deliver context and craft simultaneously. But it has the subtlest and most dangerous failure mode—the dual-reporting whipsaw. When the hub and the spoke both have real authority over the same person, that person absorbs the conflict. Their business lead wants the model shipped Friday; their functional lead wants the peer review and the documentation. The employee becomes the negotiation surface for an unresolved organizational disagreement. That is a quiet, grinding source of burnout that never shows up in an engagement survey until the resignation letter does.
The judgment call is this: there is no correct topology, only a correct match between topology and your organization's data maturity plus the volatility of your demand.
Since most CDOs at the deepen stage land on hub-and-spoke, let's go deep on the mechanism that determines whether it retains or repels people: the reporting line and the promotion authority.
The single most important decision is *who owns the career*. My strong recommendation: the hub owns the career, the spoke owns the mission. Concretely, a data scientist embedded in Supply Chain has a solid-line report into the Data function (their manager, their reviews, their promotions, their raises) and a dotted-line into the Supply Chain leader (their priorities, their roadmap, their day-to-day work). This is the inverse of what Spotify originally did, and it's the fix they moved toward.
Why this way? Because career progression requires someone who can *evaluate the craft*. A supply chain VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.Voir la définition complète → cannot fairly assess whether your feature engineering is sound. When the person who signs off on promotions can't judge the work, two things happen: technical excellence stops being rewarded and politically visible work gets over-rewarded. Both drive out your best builders.
But the dotted line to the business must have *teeth*, or you recreate the centralized ticket-queue problem. Give the business leader:
Here's a lightweight way to make the allocation explicit rather than a source of constant renegotiation:
# Q3 data allocation — Supply Chain spoke
spoke: supply_chain
business_sponsor: vp_operations
allocation:
data_scientist: 2.0 # solid-line to Data, dotted to Ops
analytics_engineer: 1.0
review_split: # weight in performance review
hub_manager: 0.6 # owns craft, ladder, growth
business_sponsor: 0.4 # owns impact, priorities
escalation_path: cdo_ops_council # meets biweeklyThe review_split line is the whole ballgame. When it's written down—60/40, not "we'll figure it out"—the employee knows exactly who they answer to for what, and the ambiguity that causes whipsaw burnout disappears. You've turned an interpersonal negotiation the employee had to conduct into a governance rule the leaders own.
The most useful idea to import from the Team Topologies literature is cognitive load—the total mental burden a team carries. Data teams fail on this axis constantly because they accumulate responsibilities like a hoarder: this team owns three pipelines, two dashboards, an ML model, the metrics layer, ad hoc requests from four stakeholders, *and* on-call. No single item is unreasonable. The sum is crushing.
When you design spokes, cap their cognitive load explicitly. A spoke that owns a domain (say, marketing analytics) should not *also* be responsible for platform maintenance—that belongs to the hub as a "platform team" whose entire job is to reduce the cognitive load of everyone else via self-service tooling. If your embedded analysts are debugging Airflow at 11pm, your topology is broken regardless of the org chart, because you've pushed platform load onto delivery teams. That's the number-one burnout signal in data organizations, and it's structural, not personal.
Comp gets people in the door and prevents the most cynical departures, but at senior levels comp is table stakes—your competitors match it. People with rare, mobile skills leave for three reasons the org chart controls: stalled growth, meaningless work, and manager quality. Topology drives all three.
Growth. In an embedded-only model, growth stalls because there's no ladder and no peer to learn from. The structural fix is a hub that runs a real technical career track independent of business hierarchy—a Staff/Principal path where an IC can out-earn a manager. Without this, your best engineers hit the ceiling of "senior" and the only way up is into management, which many of them are bad at and none of them wanted. You lose them to a company that offers a Principal title.
Meaningful work. This is where rotation matters. A data scientist stuck in the same spoke for three years, optimizing the same churn model, gets bored regardless of comp. Build a rotation mechanism into the topology: every 18–24 months, an IC can move between spokes while keeping their hub home and their ladder position. Because the hub owns the career, the move doesn't reset their progression—it enriches it. This is only possible in hub-and-spoke; it's the model's underappreciated retention superpower. Rotation also spreads institutional knowledge and reduces the bus-factor risk of one person owning a critical domain.
Manager quality. The hub manager who owns careers must actually be able to manage and evaluate data work. This means your span of control matters enormously. A hub lead with 15 direct reports scattered across 6 spokes cannot mentor anyone; they become an approval bottleneck. Keep hub managers at 5–7 reports. If you can't, you don't have a management structure—you have an accounting structure.
One more structural retention lever: protect a fraction of capacity for craft. McKinsey-style delivery pressure will consume 100% of your team's time on business requests if you let it, and a team that never refactors, never learns a new tool, never pays down tech debt is a team that's slowly deskilling—and skilled people can feel themselves getting dumber. Formalize it. Twenty percent of spoke capacity is fenced for platform contribution, learning, and debt reduction, defended at the escalation forum. This isn't a benefit; it's how you keep the asset from depreciating.
Vérification des acquis
1. What is the central argument the lesson makes about the relationship between org structure and retention?
2. In the centralized topology, why do the *best* engineers tend to leave first when the team becomes a ticket queue?
3. What key insight does the Spotify example illustrate about diagnosing data-team attrition?
4. Select ALL correct answers about the retention advantages of the centralized topology.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers describing failure symptoms of the embedded (squad) approach as shown at Spotify.
Sélectionnez toutes les réponses correctes.
Topologies aren't permanent. The CDO's real skill is knowing *when* the current structure has outlived its match and re-wiring before attrition forces your hand. Watch for these signals:
When you do restructure, sequence it to protect people. Announce the *why* before the *who*. Reorgs that reshuffle reporting lines without explaining the logic read as threats, and the first people to leave during an ambiguous reorg are exactly the ones with options—your best. Name the new topology, name what problem it solves for the team (not just the business), and give people a clear picture of their new manager, ladder, and mission within the first week. Ambiguity during transition is the single most expensive thing you can allow, because your talent market prices it as risk and departs.
1. Match topology to maturity and demand volatility, not fashion. Centralize to build craft when you're early; move to hub-and-spoke as you mature and demand fragments across units. The topology *is* your retention strategy.
2. In hub-and-spoke, the hub owns the career, the spoke owns the mission—and write the review split down (e.g., 60/40). Explicit weighting eliminates the dual-reporting whipsaw that quietly burns out your best people.
3. Manage cognitive load as a first-class metric. Never let delivery spokes carry platform maintenance. After-hours firefighting is a structural failure, not a personal one—fix it by standing up a platform team whose job is reducing everyone else's load.
4. Build a real Staff/Principal IC ladder and an 18–24 month rotation mechanism. These are hub-and-spoke's retention superpowers: growth without forcing people into management, and renewed meaning without resetting careers.
5. Fence 20% of capacity for craft and read attrition signals as topology diagnostics. Senior IC departures point to reporting-line problems; shadow hiring points to a ticket-queue central team. Re-wire before attrition forces the decision, and always announce the *why* before the *who*.