Track / Adoption
The hard part isn't building it. It's getting other teams to ship on it. Treated here as a diagnosable problem: six reasons adoption stalls, four moves that work, the metrics that matter, and the anti-patterns that look like adoption work but kill it.
01 / The diagnosis
These are the reasons teams give when you actually ask them. Not the reasons in the strategy deck. Run through the six and count the ones that describe your org. Two is typical for a stalled system — and each one is roughly a quarter of work to fix.
“It doesn't have the component we need.”
The most common reason. Teams hit a missing component on day one, fork their own, and never come back. Audit your most-active product teams' actual UI needs before you assume your component list is complete. Coverage doesn't have to mean comprehensive — it has to mean the top 20 surfaces work end-to-end without escape hatches.
“It's slower than just writing the markup ourselves.”
If using your Button takes 8 lines of import + 4 lines of prop config versus 3 lines of raw JSX, teams pick raw JSX. Every percent of friction compounds across hundreds of components. Audit the median use case — not the powerful one — and make the median trivial.
“The docs are out of date.”
Hand-maintained docs lag the source. Teams get burned once, lose trust, and route around. Type-checked MDX, auto-generated prop tables, and CI rules that fail on stale examples are the only patterns that actually hold up.
“Nobody told us it existed.”
Your design system has a great Storybook. Five teams have never opened it. Fix it with an internal launch, an obvious top-level link in your dev portal, a Slack channel that surfaces new releases, and a Cmd-K-searchable docs site. Any of those beats another blog post about the system.
“Their requests sit in a queue for months.”
Teams ask for a new variant, hear “next quarter,” and ship their own. A federated contribution model with a published RFC process, clear acceptance criteria, and a 2-week SLA on first response prevents the inevitable forking that follows a closed shop.
“Leadership doesn't measure us on it.”
Adoption that's never on a roadmap, never on an OKR, never in a code-review checklist gets out-prioritized every sprint. Adoption needs at least one upstream forcing function — a lint rule, a CI check, a section of the PR template, a quarterly metric. Pick one; ship it.
02 / The funnel
Discovery → trial → adoption → contribution → maintenance. Each stage has a typical drop-off and a typical reason. Knowing which stage you're bleeding at tells you what to fix; trying to fix everything at once tells you nothing.
% that reach each stage
The drop to watch is Trial → Adoption. Discovery losses are cheap to recover — announce again, fix the link. Teams lost between trial and adoption hit friction and rarely try twice. Halve the install time, halve the import boilerplate, halve the prop ceremony, and this is the stage that re-converges.
03 / Four moves that work
Four moves cover most of the leverage. They compound: champions distribute, pilots prove, lint rules enforce, RFCs absorb contribution pressure. Pick one to start (champion program first if you're green-fielding; lint rules first if you have existing-but-stalled adoption); add the next within a quarter.
Champion program
Champions distribute.
Pilot projects
Pilots prove.
Lint rules and CI checks
Lint rules enforce.
RFC process
RFCs absorb contribution pressure.
Identify one motivated person on every product team. Give them early access to roadmap, a private Slack channel, and a direct line to the system team. They become your distribution layer. In practice, champion teams adopt first and pull neighboring teams along — the gap shows up in your usage grep within a quarter.
Don't try to convert the whole org at once. Pick 2-3 high-visibility, low-stakes projects on motivated teams. Provide white-glove support — pairing sessions, on-call channel, dedicated reviews. Use the pilot wins as the evidence for broader rollout.
Code review at scale doesn't work. Lint rules and CI checks do. Block hex literals in components, fail on imports from deprecated paths, warn on missing accessibility props. The compiler is the cheapest governance mechanism you'll ever ship.
Federated contribution that scales. A published template, clear acceptance criteria, a public queue with status labels, and a 2-week SLA on first response. Teams stop forking because they know the path through the front door is actually open.
04 / What to measure
The metric tax is real: every metric you track has a cost in attention and report prep. Three are worth that cost. The other two are vanity — they go up while adoption goes down. Track the three. Stop tracking the rest.
How to measure: Automated grep across product repos for system imports vs custom equivalents
Why: The single most informative number. Tracks the only thing that matters: are people actually using the system?
≥ 75%
How to measure: GitHub data + npm install logs per repo
Why: Wide-but-thin (every team uses 1-2 components) is healthier than deep-but-narrow (one team uses 50, the rest use 0). Coverage forces breadth.
100% of product teams shipped ≥ 1 system component this quarter
How to measure: Issue timestamps in the RFC repo
Why: Contribution latency predicts adoption decline 6 months out. If RFCs sit, teams fork.
First response within 10 days · 30-day decision
How to measure: Storybook analytics
Why not: Vanity metric. People hit Storybook to copy-paste; pageviews tell you nothing about whether the system shipped.
How to measure: Just count them
Why not: Bigger isn't better. A bloated catalog with 200 components and 30% coverage is worse than a focused catalog with 30 components and 80%.
05 / Anti-patterns
Each of these gets proposed in every stalled-adoption meeting. Each of them feels like it should help. None of them do — and three of them actively make things worse by burning trust with the teams you most need to convert.
What's wrong with it
Internal marketing is downstream of friction. If using the system is harder than not using it, the prettiest brand book in the org won't move the needle.
What to do instead
Fix the friction. Then announce the fix.
What's wrong with it
Mandates without coverage produce compliance theatre — teams use the Button but wrap it in a custom div. The numbers go up; the consistency doesn't.
What to do instead
Earn adoption by being the best choice. Mandates work only on the last 10%, not the first 90%.
What's wrong with it
If usage is at 30%, the answer isn't 50 more components — it's making the existing 20 frictionless. New components for unmet edge cases is the right move only after the median use case is trivial.
What to do instead
Audit the top 20 actual product surfaces. Cover those end-to-end before building anything new.
What's wrong with it
Perfect doesn't ship. Two years of internal beta means two years of teams shipping without you, building habits and tooling around the absence of your system. They won't migrate when v2 finally lands.
What to do instead
Ship v0.1 with three components. Iterate in production. Trust your champions to give you the right pain signals.
Most adoption stalls trace back to choices made in the first quarter — the wrong base library, the wrong distribution mechanism, the wrong people on the team. If you're in the diagnostic phase, the playbook chapter on distribution is the companion to this piece. If you haven't started building yet, the “which one” piece will save you a year of the wrong commitments.
