Rebuilding Trust at Scale

The chapter model: making cross-functional work stick

Better tooling and a design system were necessary — but not sufficient. Multiple contractors, disciplines, and org lines meant there was no structural home for cross-functional work. I built one.

What I walked into

The platform was mid-migration — AngularJS to React — under a directive from leadership: "1:1, as fast as possible." UX hadn't been involved early. The codebase was a mix of legacy markup, incomplete design system adoption, and one-off UI patterns accumulated over years. Storybook existed but was unorganized, unowned, and open to contribution from 30+ developers with no guidelines. Engineering best practices lived nowhere official.

The fragmentation wasn't just technical. Multiple contractor firms were working on the same product, each with separate reporting lines and working norms. No standing forum existed for design and engineering to solve problems together. Every cross-functional decision required ad hoc coordination — which meant the loudest voices set the agenda, not the teams doing the work.

Taking ownership

Nobody assigned me this problem. I identified the engineering tech lead as the right co-owner — someone with credibility on the engineering side who shared the same frustrations — and proposed a standing structure we could both lead. The chapter met biweekly, included designers and developers from across contractor groups, and had a live shared agenda anyone could add to. I facilitated the design side; he facilitated engineering; we jointly owned anything cross-functional.

The co-leadership was a deliberate choice. A design-led working group would have been dismissed as design's agenda. Engineering-led, the same problem in reverse. Co-leading signalled shared investment — and it worked. Attendance was self-reinforcing because the chapter was genuinely useful, not mandatory.

Reframing the React migration

The "1:1 as fast as possible" directive would have ported the existing problems directly into the new codebase. AngularJS and React don't map 1:1, and we were also adopting a new design system. Copying markup would have preserved every inconsistency and baked in technical debt from day one.

I worked with engineering leads to reframe the goal: not pixel-for-pixel parity, but functional equivalence — same user outcome, cleaner implementation. I ran a component audit, used New Relic usage data to prioritize high-traffic components over stagnant ones, and created a migration scorecard that let engineers ship without waiting on me.

The scorecard covered seven criteria: functional equivalence, performance budget (p95 route transitions tracked in New Relic), WCAG 2.1 AA / Section 508 accessibility (verified with ANDI), design system token compliance, code quality (SonarQube), variant reduction, and Storybook documentation. Each migrated component had to pass before it shipped. Engineers had clear standards to work to; I had a consistent quality bar to hold.

Taming Storybook

Storybook was the developers' primary component reference, but it had no governance: 30+ contributors, no usage guidelines, no compliance requirements, no owner. Components existed in multiple conflicting versions with no indication of which was current or correct.

I reorganized it — establishing usage guidelines, compliance standards, and a clear ownership model. The migration scorecard included a Storybook documentation requirement, so every migrated component arrived with updated stories linked from the PR. Over time, Storybook became a reliable source of truth rather than a source of confusion.

Building the documentation site

Engineering best practices had no permanent home. I built one: a documentation website using Docusaurus (a React-based framework), written and maintained by me, with contributions from members of my UX team and engineers from across contractor groups who I recruited to help. No one was officially assigned to this. I identified the need, proposed the solution, built the initial site, and created a contribution model that kept it current without requiring my involvement in every update.

The site documented the design system, migration guidelines, accessibility standards, and component usage patterns — everything that had previously existed in scattered Confluence pages, outdated PDFs, or someone's head.

Results

Design-system-compliant screens went from approximately 35% to 75%, with full compliance in reach. Route transitions got faster. One-off UI variants were systematically eliminated as components migrated. Engineers moved faster because they weren't tripping over inconsistencies — and the double-work of porting broken patterns into the new codebase was avoided entirely.

The chapter itself became the default venue for cross-functional decisions. Problems that had required multi-week escalations started getting resolved in a single session. The shift from reactive to collaborative wasn't cosmetic — it changed how the teams operated day to day.