Ask five design system leads who should be allowed to submit a new component, and four of them will say "anyone, through a contribution process." Ask what happens when two teams submit conflicting versions of the same modal in the same sprint, and the room goes quiet. That's the real test of centralized versus federated ownership — not who writes the code, but who resolves the disagreement when it happens.
Hub-and-Spoke and Federated Aren't Points on a Dial
The instinct is to think of centralization as a slider — more central, more consistent; more federated, more velocity. That's the wrong model. As a recent framework on organizational design puts it, the two structures differ in constitution, not degree: in a hub, "the center holds the capability and lends its output downward," while in a federated model, "the nodes hold the capability and cede a defined slice of authority upward, to a protocol they helped write" (Milen Vasilev).
That distinction matters more for design systems than for almost any other internal platform, because the "protocol" in a federated design system isn't abstract — it's the actual set of decisions about what a component's states mean. A button that pauses a destructive action and a button that confirms a completed one can share identical chrome and completely different intent. One practitioner working on an enterprise operations product described exactly this failure: the same modal and surface pattern were reused across a workflow tool until "the same chrome could mean three different things," because the state model was never documented (Sebastian Balderas Espinosa). Federation without an agreed protocol isn't federation — it's just uncoordinated centralization, minus the coordination.
Where Centralized Ownership Actually Earns Its Keep
The hub-and-spoke framework names the real reason centralized design system teams exist, and it's not control — it's pooling. "If eight business units each need 0.4 FTE of a specialist, you cannot hire 0.4 of a person eight times" (Milen Vasilev). A three-person design systems team serving twelve product squads is a queueing solution, not a governance mandate. That's worth remembering the next time someone frames a centralized team's backlog as a bottleneck to be dismantled rather than a symptom of under-resourcing.
But the same source names the tell that a hub has outlived its usefulness: teams start requisitioning headcount to build their own version of what the hub already provides (Milen Vasilev). If your platform team is centralized and you're seeing shadow component libraries appear inside individual squads, that's not a discipline problem you fix with a stricter contribution policy. That's a demand signal the hub failed to meet, and no amount of Slack reminders about "using the system" will fix it.
The Missing Layer Federation Actually Needs
Where federated contribution models tend to fail in practice isn't at the component level — it's above it. One design leader described this gap precisely: "The system covers the component layer... The layer above it covers how those parts get assembled into a flow," and in a squad-based org that layer "belongs to whichever squad touched it last," which in practice means nobody (Design Outcomes). A federated contribution model can work fine for adding a new input variant. It falls apart the moment two squads need to agree on what a shared header or navigation pattern should do — because there's no protocol node for that decision, only components that happen to sit next to each other.
If you're going to federate contribution, you need something closer to the git-first governance pattern some distributed teams have adopted: version-controlled proposals with traceable review, rather than decisions made "through Slack messages or Figma comments, which are ephemeral and lack traceability" (CoolSpace). The mechanism matters less than the principle: federation only works when the protocol nodes agreed to is durable and auditable, not tribal knowledge held by whoever's been on the team longest.
The Practical Split
I'd draw the line like this: centralize the token layer and the primitives, because that's where inconsistency compounds silently across every product surface. Federate component implementation once teams have proven they understand the underlying decisions, not just the visual output. And explicitly assign someone — not a committee — to own the layer above components, the flows and shared experiences that no single squad's contribution touches but every squad's work depends on.
Most teams pick a model based on org chart aesthetics rather than where their actual failure mode lives. Before you federate anything, ask which failure you'd rather have: a queue, or drift. Then build the ownership model that fails in the direction you can tolerate.
