I’ve led Design Systems across two different organizations recently in my career. In both instances the Systems served Design as a mechanism for Governance and collaborative influence across cross-functional teams.

Design systems as cross-functional discipline

At Ozmo, I convened Design and Engineering together to steward our design system into a token-based React component platform, built to WCAG 2.1 AA, rather than dictating a direction from Design alone. The group chose Material UI collectively as the underlying library, so Engineering co-owned the decision from the outset instead of inheriting it after the fact. I also made every designer a required contributor to the system, keeping craft and consistency a shared, actively modeled standard instead of something that ran through me personally as a bottleneck.

At Block.one, the same underlying problem showed up in a more structural form where our design system lived cleanly within Design, but standard design-to-dev handoffs weren't closing the gap between what Design specified and what actually shipped. Rather than treating that as a process problem to patch with better documentation, I treated it as an organizational design problem where a new role solved the problem.

Here's an example of how I leveraged Design Systems Leadership to close a structural gap between Design and Engineering:

💼 Case:

At Block.one, our design system lived cleanly within my team, but with an expansive, globally distributed Engineering team, standard design-to-dev handoffs were consistently insufficient to keep shipped product faithful to what Design had specified.

⚠️ The problem:

As with every organization, skills and preferences vary. At Block.one, the Engineering organization was mainly focused on deep Blockchain expertise and when it came to Front End acuity, I felt like we were speaking different languages.

Every new component meant another round of interpretation and rework as Engineering rebuilt what Design had already fully specified, component by component. That gap not only cost time, it eroded the system's own credibility, since specification and implementation kept drifting apart, and faithful execution depended entirely on how well any single handoff happened to go.

🛠️ Process:

Rather than adding another documentation step or a stricter handoff process, I identified that what was actually missing was a dedicated Design practitioner who could translate the design system directly into coded components Engineering could consume without reinterpretation. I conceived of a new role type - Design/UX Engineer - to close that gap, defined its scope, recruited for it, and hired the right person. The coded components were built in Storybook and went through the same engineering testing and validation as any other production code before adoption.

✅ Results:

Because the role sat structurally between Design and Engineering, faithful implementation stopped depending on any one handoff going well, and production adoption followed the same rigor as the rest of the codebase. It was an organizational design decision and it's still the model I’d reach for whenever a design system needs a bridge to Engineering adoption.

More recently at Ozmo, I stewarded the design system from a component library into a token-based, WCAG-compliant platform. I kept Engineering as an invested co-owner by convening Design and Engineering cohorts as the Design System came to fruition, collaboratively choosing Material UI as an efficient starting point, keeping both sides involved in a decision neither team owned unilaterally.

Before my departure at Ozmo, I led the cross-discipline team into preparation for AI enablement, structured for agent consumption.