Why the platform team should own the design system
Most design systems fail not because of bad components, but because of ambiguous ownership. Here's the argument for letting platform engineers run it.
A design system is not a product. It's infrastructure.
That distinction matters more than almost anything else you'll decide about how to run one. Infrastructure is owned, maintained, and upgraded by people who care about the platform as a whole — not by people who are accountable to a feature roadmap.
The three places design systems usually live
In my experience, most organizations land in one of three ownership models:
1. Dedicated DS team — A separate team whose entire mandate is the design system. Sounds good on paper. In practice, they're perpetually fighting for priority, their components are always slightly behind what product needs, and when they leave the company the whole thing collapses.
2. Design-owned — Designers maintain Figma components; engineers copy-paste implementations across squads. Drift accumulates. Dark mode gets added to Figma but not the code. Tokens exist in two places with different names.
3. Distributed across squads — Each squad owns "their" components. In theory, everyone contributes. In practice, no one feels the accountability, and you end up with four different button implementations.
None of these are right.
What platform ownership actually looks like
The platform team owns the infrastructure every other team depends on: bundler config, CI/CD, shared auth patterns, API conventions. A design system is exactly that — infrastructure every product squad depends on.
The platform team doesn't build features. They build the ground other people build features on.
When the platform team owns the design system:
- They have the right incentives. Their job is reliability, consistency, and developer experience — exactly what a design system needs to succeed.
- They have the right access. They understand the build pipeline, the token system, the publishing infrastructure.
- They're not distracted. No sprint planning conflict between "ship the login page" and "refactor the button API."
The part that surprises people
The design system shouldn't be built in isolation by the platform team either. The best model I've seen:
- Platform owns the architecture, tokens, publishing, and the contract (the API surface of each component).
- Product squads contribute patterns when they identify them. When a squad solves a problem three times, the solution moves into the system.
- Design collaborates on the component spec before a single line is written — not after.
That last point is critical. "Design then implement" is how you end up with a button that has 23 props. The spec needs to encode constraints, not just possibilities.
What to do when you inherit a mess
If you're reading this and already have a distributed disaster, here's the fastest path to coherence:
Don't try to rebuild from scratch. The rewrite impulse is almost always wrong. Migrate incrementally, one component at a time, and make each migration demonstrably better than what it replaces.
The design system question is ultimately a question about organizational gravity: where does accountability live when things break?
If the answer is "it depends," the system will drift. If the answer is "the platform team," you have something durable.