Centralized vs federated design system team models

WHAT THIS TESTS Whether you understand that a design system is as much an organizational system as a technical one, and whether you can match the operating model to context.

A GOOD ANSWER COVERS In a centralized model a dedicated core team designs, builds, and maintains everything. Benefits are tight consistency, high quality bar, and a single clear owner. Costs are a throughput bottleneck, slower response to product needs, and a sense of the system as someone else's tool. In a federated model many product teams contribute components and fixes. Benefits are scale, faster coverage of real needs, and shared ownership. Costs are inconsistency, duplicated effort, and quality drift unless governance, contribution guidelines, automated checks, and core review exist. The choice depends on org size, maturity, and resourcing; small orgs often start centralized, large ones evolve to a hybrid where the core owns governance and primitives while federated teams extend.

COMMON WRONG ANSWERS Treating one model as universally superior. Ignoring that federation needs heavy governance and review to avoid fragmentation. Assuming centralized scales infinitely. Conflating contribution model with whether the code is in a monorepo.

LIKELY FOLLOW-UPS How do you bootstrap governance for a federated model? How do you measure adoption and quality? When do you transition from centralized to hybrid? How do you handle contribution review load?

ONE CONCRETE EXAMPLE A five-person startup runs a centralized model: one team owns the whole system, keeping it consistent. As the company grows to dozens of product teams, the core becomes a bottleneck, so it shifts to a hybrid: the core team owns tokens, primitives, and review gates, while product teams contribute new components through a documented RFC and review process.