How I took a drifting component library and turned it into a governed system that engineering actually adopted, across all ten product teams at Nextens.
At Nextens, a Dutch tax-software company inside RELX, design and development handoff was a bottleneck. Components existed in Figma but drifted from what shipped, and there was no governance over how the system evolved or who owned it. I led the work to make the system authoritative rather than aspirational, and to design that governance around engineering's existing workflow so it would survive.
Inconsistent components meant inconsistent interfaces in a product where clarity is a compliance concern, not a nicety.
Drift between design and build burned engineering time on rework and slowed every feature through repeated refinement.
No ownership and no change rules meant the system could not be trusted as a source of truth, so people worked around it.
I owned the system end to end: the architecture, the governance model, and the adoption. The hard part was never the components; it was getting a standard adopted by teams that never reported to me. So I designed the standard to fit the workflow engineers already had, rather than imposing a parallel process, which is where most governance quietly dies.
The approach: audit the real drift, consolidate aggressively, connect tokens and components through Storybook into the build pipeline, then attach explicit ownership and change rules. Complexity had to be earned; if a simpler version got eighty percent of the value, it won, because adoption was the metric, not elegance.
I cut 20 button variants down to 4 and replaced 20+ dropdown variants with a single configurable component before adding any rules.
Trade-off: short-term disruption to in-flight work, in exchange for a system small enough to actually govern.
Tokens and components flowed through Storybook into the pipeline, so the system was where engineers already worked rather than a separate library to remember.
Outcome: adoption became the path of least resistance instead of an extra task.
Every component got explicit ownership and an agreed process for how it could change, so the system stayed authoritative over time.
Trade-off: a real governance overhead, justified by the drift it prevented.
Governance is a human problem wearing a technical costume. The components were the easy part; the durable win came from designing for adoption and trust rather than compliance. Given more time, I would formalise the contribution model earlier so the system scales its maintainers, not just its users.