Ownership by Relevance

The situation

The design system was maturing past individual components into patterns: reusable, cross-product solutions that would pull a set of separate legacy products into one unified platform. That is exactly the work that turns a component library into a real platform language. But it stalled, and not on the design problem. Whose job it was became contested, and while that stayed unresolved, the patterns didn't get built.

The work was too cross-cutting to belong to any single team, so every attempt to hand it to one owner was the reason it kept stalling. The question the org kept asking (who should own this) was the wrong question.

The approach

Rather than wait for the ownership question to resolve, or let it get dumped on one overloaded person, I designed a model where ownership is distributed by relevance. The core idea: a pattern belongs to the people closest to it (whoever designed it, or uses it most in their product), with everyone else participating in a defined, relevant capacity. Leadership, the design system group, subject-matter experts, and engineering each step in where their expertise actually applies. Everyone gets a real seat; no one carries the whole weight.

I engineered this for this team's specific makeup and dynamic, and that is the point, not a disclaimer. An operating model has to fit the actual people and how they work, so this one was built around our roles, our review rhythms, and the exact friction we needed to move past. It would not port to another team without doing that same analysis first.

What I built

Two artifacts that together form the system. First, a working-group model, the who: five groups with explicit composition and responsibilities, so participation is defined rather than negotiated pattern by pattern. The Patterns Working Group (leadership, design system, and operations) sets the roadmap and governs; Pattern Drivers do the hands-on design and documentation; and the SME, Final Review, and Code Build groups each enter where they add value, pulling in accessibility, content, platform, and engineering expertise at the right moment.

Second, a pattern process flow, the how: the lifecycle a pattern travels, from identification and prioritization, through driver assignment and a documented design phase in a shared Figma template, through staged SME and Final reviews with iteration, into code build and ongoing maintenance.

The mechanism worth calling out: a "Pattern Driver" is not a fixed role or team; it is whoever is closest to that particular pattern. Ownership rotates by pattern and by relevance, which is exactly what dissolved the who-owns-it stall. The answer became "the right people for this pattern, this time," not "that team, forever."

The outcome

I took the model through many rounds of iteration and feedback with the leaders who had been at odds over it, and finally with the Head of Design, and it earned approval from all parties to begin implementing. We kicked off a pilot on the platform's filtering patterns (a genuinely thorny set), and it was about halfway through when my role there ended.

What it had already done was break the stall: it got leaders who had been in contention to agree on a shared way to move the work, and it put the first patterns into motion through a process the whole team had a stake in.