process
Governance model
Who is allowed to change a design system, and how a contribution gets approved – centralised, federated, or a hybrid of the two.
Once a system exists, someone has to decide who may change it. Get this wrong and one of two failure modes follows: a small team becomes a bottleneck the whole company routes around, or everyone changes things independently and the system quietly stops being a system.
Three models, roughly in order of how systems mature. Centralised – one dedicated team owns everything; strongest consistency, known bottleneck risk. Federated – the core team sets standards, product teams contribute within them; balances the bottleneck against the need for real review discipline. Hybrid – centralised ownership of the foundations (tokens, base components) with federated contribution for higher-level patterns; increasingly the described end-state rather than a starting choice. Which is right is genuinely organisation-specific – the test is whether the model has a working answer to “how does a new component get added” that’s neither a queue nor a free-for-all. Even “one person owns changes for now” is a governance model, and for a small product it’s often the correct one.