This is the story of building Compass, a design system in a large, process-driven organization with many competing priorities and a cautious approach to resourcing. It’s not a neat or polished story. It unfolded over several years, with repeated starts and stops, and at a time when the design team itself was in need of morale and direction.

Along the way, there were real failures—and, ultimately, hard-earned learnings about what it actually takes to make a foundational initiative like a design system succeed in an organization where its value has to be continually argued for and protected.

Three Years of Struggle and Start-and-Stops

Compass started from the design side.

In 2020, designer morale was low due to not having time to work on craft and foundations, and leadership agreed in principle that this mattered. There was also a shift happening toward focus on quality of the product instead of growth at all costs. That opened the door for grassroots work: craft time for designers to align on patterns, document what existed, use Hack Days, and begin designing foundational components together. That effort wasn’t wasted. Designers were engaged, quality conversations improved, and the absence of shared foundations became obvious across the product.

Over time, some engineering support was introduced, and a first version of Compass was released. But resourcing was never focused. The work lived alongside product priorities, without clear ownership or sustained capacity. Design system work was verbally prioritized, but rarely reflected concretely in roadmaps.

Progress was not continuous and felt like going against the stream. A lot depended on individual motivation, renegotiating verbally the importance of a design system, and progress easily came to a halt. Over the years, talking about the design system without being able to properly invest in it created fatigue across the organization.

The Final Attempt That Unlocked Progress

When I came back from a sabbatical, it was clear the approach wasn’t working anymore. There was organizational fatigue, slowed progress, and some strained relationships between departments after a period where the work had been pushed too forcefully, and in an attempt to get engineering resourcing, conversations were turning into blaming “the other”.

What changed this time was sponsorship and my own approach to securing true buy-in.

The CPO said he would get us the resourcing from the top if I could create a sound strategy with buy-in from the organization. At the time, I used the guidance in “Good Strategy, Bad Strategy” as a frame to write a document that laid out where Compass actually was, what problems it needed to solve, and what it would take to make real progress. It was opinionated and detailed on the action plan.

That document became a working artifact: I discussed it repeatedly with the CPO, CTO, product and engineering leaders, integrating feedback, changing many of the initial ideas and finally aligning on a shared point of view — a true opinionated approach that would work for our organization.

We shifted how we worked. We set concrete goals and metrics for adoption and coverage. We optimized for speed by starting small, reducing dependencies on other teams, and minimizing complexity. We focused on creating the conditions for progress rather than trying to push progress through willpower alone.

Outline of the Compass Strategy Document

For the first time, Compass was treated as infrastructure, with sponsorship, clarity, and a path forward. It was not easy to make progress post this point but it was the first time we had resourcing and clear ownership from both engineering and design, with the top and mid level leaders agreeing to give the project a shot. Then came many cultural obstacles and other not-so-obvious challenges, but we were making progress in a way that didn’t feel like a side project requiring negotiation as a priority every quarter.

The decisions we made

Focus on small, self-contained components

Although mission teams were asking for complex, domain-specific components, we made a deliberate shift toward smaller, self-contained ones. More complex components required reliance on business logic and close coordination with mission teams, which consistently slowed progress. Focusing on self-contained components allowed us to move forward with fewer dependencies and speed up progress early.

Final scope & distribution of ownership (after many feedback rounds)

Prioritize execution speed

While shared ownership with mission teams was the long-term goal, we recognized that trust hadn’t yet been established and there wasn’t a critical mass of components to make contribution feel worthwhile. We deliberately chose to have the design system team execute first, with the intention of enabling broader contribution once the system had proven its value.

Establish clear dual ownership across design and engineering

We put explicit ownership in place from both disciplines: a lead designer and a lead engineer, both fully focused and operating with real agency. This clarity removed ambiguity and made decision-making faster and more credible.

Relax gatekeeping to lower the cost of contribution

Our early emphasis on high quality and strict process unintentionally created the perception of gatekeeping and made contribution feel hard. We chose to relax constraints and accept short-term inconsistency, because imperfect contribution was better than no contribution at all at that stage.

Actively enable contribution through hands-on support

Opening up contribution required more than permission. The design system designer invested heavily in supporting other designers—helping shape components, guiding documentation, assisting with library integration, and communicating expectations clearly. The goal was to make contribution feel achievable and supported, rather than risky or burdensome.

Learnings for leaders

Design for the reality of the organization

Design systems come with plenty of best practices, but none of them matter if they don’t fit the reality of the organization. Designing a system that may not be perfect for the long term, but is fit for getting things off the ground, is often far more effective than aiming for an ideal end state too early.

Sponsorship must come with real resourcing

Executive sponsorship is meaningful only when it translates into concrete commitments—time, people, and prioritization. Without those, initiatives remain aspirational and quickly lose out to competing work. It’s important to secure sponsorship at the level where resourcing decisions are actually made and to acknowledge that hierarchy plays a real role in whether progress happens.

The power of written strategy

We’ve all probably heard of the 1-pagers, strategy and working backwards docs, etc. Before this project, I underestimated the power of a clearly written strategy with an explicit point of view. It became the best way to facilitate discussion with intent, force explicit alignment, and create clear accountability.

Foundational work is hard to prioritize in fast-moving organizations

Even with top-level alignment that quality matters, foundational investments often compete with short-term metrics and delivery pressure. Navigating that tension requires ongoing communication, reassurance, and repeated alignment, so that it moves beyond wishful thinking.

Blame kills the very progress foundational work needs

When resourcing is unclear, frustration easily turns into pressure or blame. What actually unlocks progress is shared ownership, mutual accountability, and explicit agreements. Influence rarely comes from the loudest person forcing change, but from a strong point of view paired with listening, trust, and real compromise.

Leadership & Influence

This experience reshaped how I think about leadership without authority. Making change at scale is not about pushing harder, but about understanding power, hierarchy, and relationships, and having the humility of working with them deliberately.

It also showed me the leverage of writing. A clear point of view, made explicit, can move conversations in ways persistence alone cannot.

Designer’s Notebook

Building a Design System Is an Organizational…