For a government department whose twelve service teams share one design system, how would you choose between centralized, federated and hybrid governance, and when would you change it?
answer
- no model is right forever
- maturity, scale, product diversity
- where consistency is non-negotiable
- queues signal loosen, divergence signal tighten
- ownership needs funded time
basics
~20 sChoose by maturity, scale, product diversity, funding and where consistency is non-negotiable. Often that means central authority over foundations and accessibility, federated ownership of domain components, and shifting the balance when review queues or divergence signal it.
solid answer
~50 sThere is no permanently right model, so I'd choose against a few factors: **maturity** (early systems need a central team to set foundations), **scale and product diversity** (twelve teams in different domains hold knowledge no central team has), **risk** (for a benefits service, accessibility and trust failures harm users and carry legal exposure, so that authority stays central), and **funding** (federation fails if contributors have no protected time). For this department that usually lands on a **hybrid**: a core team owns foundations, the accessibility bar and approval of shared components; service teams own domain components under those standards; a council of representatives shapes the roadmap and breaking changes. Then I'd watch the signals: **growing queues and teams building around the system** mean loosen; **divergent quality and duplicate components** mean tighten. Changes of model are announced, piloted and funded, not declared.
go deeper
Recall that the choice between governance models depends on the organisation's situation, and that many organisations land on a hybrid of central foundations and team contributions.
Explain which factors push toward central authority and which toward federation — maturity, scale, diversity, risk, funding — and why they often point different ways.
Show how you would read queue and divergence signals from a real system, and pilot a change in decision rights with evidence rather than declaring it.
Own the call: justify a model for a specific organisation, including where authority must stay central, how ownership is funded, and what evidence would make you change it.
## No model is right forever A **design system's governance model** decides who owns it and who holds the decision rights: a **centralized** model gives both to one system team, a **federated** model shares them among product-team representatives, and a **hybrid** splits them — a core team for foundations and approval, product teams for contribution and domain components. Choosing between them is a judgement, not a lookup, and the right answer changes as the organisation and the system mature. ## The factors that decide it | Factor | Pushes toward central authority | Pushes toward federated ownership | |---|---|---| | System maturity | Early: foundations still being set | Mature: stable foundations, clear standards | | Number of teams | Few consumers | Many consumers, more requests than one team can serve | | Product diversity | Similar products | Distinct domains with specialist knowledge | | Risk of inconsistency | High harm from failures, e.g. accessibility | Lower harm, local variation tolerable | | Funding | A funded system team | Product teams given protected time for system work | | Expertise | Scarce specialists best concentrated | Expertise spread across teams | No factor decides alone. A department with twelve service teams scores 'federated' on scale and diversity and 'central' on risk, which is why hybrids are common. ## A likely answer for the department Consider a benefits department whose services cover eligibility checking, applications, evidence upload, appointments and case status. - **Central authority** over foundations (tokens, type, spacing), the **accessibility bar** and final approval of shared components. People claiming benefits include many disabled, older and digitally excluded users, and public services often carry legal accessibility obligations, so inconsistent quality here is a harm, not a style issue. - **Service-team ownership** of domain components, such as an eligibility result or a case-status tracker, built to system standards and maintained by the teams that understand them. - **A council** of service representatives with a real say over the roadmap and over breaking changes, since their teams pay for migrations. ## Signals that it is time to change Watch for symptoms in both directions: - **Loosen toward federation** when review queues grow, time to decision stretches, and teams start building around the system. - **Tighten toward the centre** when components from different teams diverge in quality or accessibility, duplicates appear, and nobody holds the overall vision. - **Re-examine funding** when federated contributions stall: that usually means contributors' system work is losing to product deadlines. ## How the model tends to evolve Many systems move through a recognisable sequence, though not every organisation needs every stage: 1. **Start central**: a small funded team sets foundations and the first components, because early decisions need one coherent owner. 2. **Open to contribution**: as demand outgrows the team, product teams contribute under the core team's review — the beginning of a hybrid. 3. **Delegate domains**: mature service teams own domain components outright, and a council gains a say over the roadmap. 4. **Re-centralize selectively**: if drift appears, authority over the affected area — often foundations or accessibility — moves back to the core, without undoing the rest. ## Changing the model without losing trust 1. **Name the problem** the change solves, with the evidence — queue lengths, duplicate counts, audit findings. 2. **Publish the new decision rights** before they take effect: who approves what, and how disputes escalate. 3. **Pilot** with one domain or a few services before applying it everywhere. 4. **Fund it**: federated ownership needs time written into service teams' plans; central authority needs core-team capacity to match. 5. **Review** after a set period against the same signals that triggered the change. ## Pitfalls - Choosing by fashion or by copying another organisation's model without its context. - Declaring federation to save money, with no protected time — contributions dry up and the system decays. - Keeping a centralized model after the organisation has outgrown it, so the system becomes a queue. - Confusing the governance model with team composition; who sits on the team is a separate decision from who holds which rights.
- How would you tell whether a federated model is failing for lack of funding rather than lack of interest?Look at where contributions stall. If teams propose components and then stop part-way, or contributions spike only between product deadlines, the interest exists but the time does not. Interviews with contributors and their managers usually confirm it. The fix is protected time in product plans or a small funded core, not more encouragement.
- Why keep accessibility approval central even when component ownership is federated?Because an accessibility failure in one shared component reaches every service that uses it, harms real users and, for public services, can breach legal obligations shared across the department. Concentrating that review in specialists applies one consistent bar, while federation still lets domain teams build the components themselves.
saying these in an interview costs you the question
- The best governance model can be chosen once and kept forever.
- Federation is a cheap option because product teams contribute in spare time.
- The model should copy what a well-known organisation does, whatever the context.
- More central control always produces a more consistent product.
- Changing the governance model only requires announcing the new structure.