Refined over five design system leadership roles. The short version: I try to earn trust before I ask for it. That means absorbing the culture before I propose anything, and picking a small helpful project before I pitch the big structural one. The first three months are for installing trust. The initiatives come after.
Do the small right thing before you propose the big right thing. Most of the rest is a variation on that.
Everything below is really about building three kinds of trust — with the team, with partners, and with the people who use the system. The phases are how I sequence that work. Every signal to advance is a trust checkpoint underneath.
Inclusive, authentic feedback loops. Helping each IC find their leadership voice and link their work to what they actually care about. When people know I'll show up for them consistently, they show up for the work — and for each other.
Consistent delivery. Clear asks. Cross-functional collaboration as a two-way street — I show up for what partners need from us, and I ask cleanly for what we need from them. No opaque roadmaps, no political games.
Being responsive when they ask. Making the system easier to use than to route around. Taking feedback seriously enough to change what we're doing — and telling people when we do, so they know they were heard.
None of the three works on its own. The team trusts you more when they see you build trust outside the team. Partners trust you more when the team behind you is healthy. Users trust the system when they can feel the whole thing operating with intent.
The first three go in order. The next four run in parallel and never really finish. Timeframes are approximate — every org bends them differently.
The diagnostic conversations tell you what the team believes. The audit tells you what the system actually is. I run a 10-station audit against the codebase, docs, Figma, and adoption signals — with AI tools doing the crawling — and get a structured read in a day or two instead of the weeks it takes by hand. What comes back is a clear map of where the system holds up, where it's brittle, and where it can't yet be picked up cleanly by AI.
| Quality | What it asks | Stations |
|---|---|---|
| 01Complete | Does your system have what products need? | 1. Coverage & gaps |
| 02Sound | Is what's in the system actually good? | 2. Best practices · 3. Accessibility · 4. Shared language · 5. Testing & validation |
| 03Synchronized | Are assets connected & orchestrated? | 6. Orchestration |
| 04Extensible | Can you reliably improve, extend, and evolve the system? | 7. Governance & version control · 8. Feedback & adoption |
| 05AI-Ready | Can AI successfully use the design system? | 9. Machine-readable docs & context · 10. Agent access |
The audit sharpens the one-sentence diagnosis. If the interviews say "people don't trust the system" and the audit says "coverage is 40%, accessibility is spotty, tokens don't share a language" — putting those together is much more actionable than either on its own. The audit doubles as the evidence for the diagnosis and a rough map for what to prioritize once the first project ships.
Modernizing tokens, Figma, and code is the part of this phase where AI is genuinely useful — not as a shortcut, but as a way to make months of foundation work take weeks. The catch is that somebody still has to stay on top of the quality decisions. AI does the grunt work; you're still the taste.
This is where my AI + design systems toolkit stands right now — the capabilities I can point at any of the phases above from the first week I join. I keep the list updated because the tools change faster than the practice does.
10-station rubric across five qualities. A day or two of AI-driven crawling replaces weeks of manual reading.
Harmonizing tokens across a system that grew organically. Moving fluently between Figma, Flutter, and Web Components.
Keeping design and code aligned as the foundation shifts. Catching the drift before it becomes a problem worth naming.
Auto-generated docs that agents can pick up as context. Humans and AI reading the same source of truth.
Prototyping and generation where the system — not the prompt — is doing the heavy lifting. On-brand and accessible by default.
Treating the system as infrastructure for an AI-driven product lifecycle. Layerable skills, MCP integration, agent-accessible context.
Fluent via ongoing practice and Brad Frost, Ian Frost & TJ Pitre's AI & Design Systems course. aianddesign.systems
If the same wrong kind of work keeps landing on your team, the ask isn't the problem — the org is. Do the wrong work first if the deadline is real. But name the reason it landed on you, and propose the structural fix. See: the Sprout Social case study.
If your team feels invisible, it isn't their imagination. It's a leadership problem — yours to solve, above and outward. Visibility is a job, not a byproduct.
Watch for when your ideas start being repeated back to you, without attribution. That's success. Don't correct it. The idea living on other people's lips is worth more than the credit.
The measurement work is the leadership work. Do it early, do it consistently. Be honest about the parts that are still anecdotal. If you can defend it in the org's language, the org will defend the team's existence.
As more of the product ships AI-generated UI, the quality gates on that output become part of the design system team's job. Watch for AI making the calls the system should have made. Approvals, security review, and quality standards need to be in place before you ship generative features — not bolted on afterward.
Do the small right thing. Diagnose the real thing. Build the foundation. Grow the people. Repeat the strategy until it's everyone's. Then measure what you did in the language they'll believe.