Don't: More questions

Our working model of how design-system operations grow. Headcounts are indicative.

Shape: One product team builds and uses the system.
Roles to name: A system owner, and a guild of three who cover design, engineering and accessibility between them.
Rituals to start: A weekly triage and a monthly health review.
What usually breaks next: One person holds everything.
Where we start: A two-week Quick audit. You keep the report, the roadmap and a baseline either way.

Shape: A core team serves several product teams, and contributions are starting.
Roles to name: The area owners, a part-time Ops lead and a support rota.
Rituals to start: Office hours and a release review, added to the weekly triage.
What usually breaks next: Support swamps the core team.
Where we start: A two-week Quick audit. You keep the report, the roadmap and a baseline either way.

Shape: A small core, area owners and product layers.
Roles to name: A guild of five to seven, a dedicated Ops lead and a named sponsor.
Rituals to start: A quarterly roadmap and a cross-team council, added to the weekly triage.
What usually breaks next: Products drift and duplicate each other.
Where we start: Discovery and governance design, over two to four weeks. You keep the operating model as records in your repository either way.

Shape: Layers per brand or region, each with its own owners.
Roles to name: Layer owners, regional guilds and an Ops lead with a team.
Rituals to start: A council per layer and a quarterly leadership review.
What usually breaks next: Layers fork, and leadership loses the picture.
Where we start: Discovery and governance design, over two to four weeks. You keep the operating model as records in your repository either way.

Our engagements start at five people. The free health check and Loom Base, our open-source design system, are for you.