The Machine That Does the Work
Rebuilt a strong-but-overlooked design system into shared infrastructure for a multi-thousand-person org — the groundwork for AI-era speed.
The record
CE/W-02Context
GoDaddy ships product across dozens of surfaces, applications and brands. At that scale, a design system isn’t just a UI kit. It’s the layer that determines whether several thousand people can make decisions independently without the product falling apart in front of customers.
When I was charged with taking over the design systems team, that layer existed in name only. I quickly found out the team itself wasn’t the problem; the talent on it was strong, and it’s the reason most of what followed was possible. The problem was that none of it was visible or usable from the outside. Three things were true at once:
- The team worked out of view. Nobody outside it knew what was being worked on, what was coming, or why it mattered. None of it was legible to the rest of the org, and a systems team nobody can see can’t earn adoption.
- The record didn’t match reality. Design documentation was incomplete and didn’t match the engineering docs, and what existed in both had drifted from what was actually live in production. When the sources of truth aren’t true, every team consuming the system inherits the uncertainty, and most respond rationally by building their own version. A wise mentor once told me: “Our documentation is the product.”
- There was no embedded engineering capacity. The team had no design technologist or UXE function, which meant no ability to ship components or move the needle on the company’s highest-priority work. The system could describe intent but couldn’t deliver it.
Three shortcomings, three different kinds: visibility, truth, and capacity. All three together meant the system wasn’t infrastructure that the rest of the company could rely on; it was strong work but out of reach.
When I joined, the org’s own survey put documentation clarity and system flexibility at roughly 5 out of 10, and the team had never been measured as moving either one. That was the floor we started from.
The rebuild
We took the three in order: make the team visible, make the record true, then build the capacity to ship.
Making the team visible. The work was already there, so this was a communication problem, not a production one. Attention is the scarcest thing to earn inside an org that size, so we made noise, and made it fun: Figma release updates, a monthly design-advocates forum that doubled as intake, and enough kitschy Slack theatrics to get people to actually look. Under it was real listening; some of it stung, and all of it was essential.
Making the record true. You can’t push people to adopt what they can’t find. One designer was working a careful audit, chipping at the docs over time; instead, we put the whole team on it and stood up a complete baseline in two weeks, then polished from there. Complete-but-rough beat thorough-but-slow: a full set unblocked every consuming team at once. The more durable fix was the operating rhythm with our sister engineering team, who owned the platform. This required a lot of teamwork, meetings, and 1:1s to get the team in a much more collaborative state.
Building UXE. Building UXE didn’t start from scratch. We had several UXEs in the broader UX org, but they were spread across different teams. Bringing them together into a center of excellence under a UXE Manager was the first step. From there we continued to hire and augment the team. The charter was narrow on purpose: component delivery, architectural advisory, and deploying against the company’s highest priorities. First cycles against high-priority work built the delivery credibility that made the rest possible.
The second act (ongoing)
Fixing visibility, truth, and capacity gets you a functioning system. It doesn’t yet get you infrastructure. That’s the second act, and it’s the one we’re in now: moving the system from the receiving end of decisions to the table where they get made.
Moving UX Engineering upstream. We’re moving it from implementation to architectural advisory, into the rooms where product and engineering decide how things get built, not just how they look once decided. My part was making the case for that seat and protecting it; the team’s standing is what earns it.
Moving standards to where the code is written. As AI-assisted coding arrives, the existential question for design systems becomes: do your standards live where the code is now being generated? We’re building tooling that embeds our UX standards directly into AI coding tools, so the system travels into the work as it’s written instead of waiting in documentation nobody’s agent reads. In an early pilot, it caught non-conforming patterns in about a third of runs — work that would otherwise have shipped off-system, caught before it reached review.
None of this is settled. The system can sit at the table now; making sure decisions actually route through it is the daily work, and plenty still route around it. Holding the position is a standing argument, not a milestone already passed.
Outcomes
Measured against the org’s own twice-yearly survey, baselined at the point I joined and tracked across every cycle since. All scores out of 10.
- Documentation clarity rose 40%. The “truth” problem, closed: the record now matches production, and teams trust it enough to build on it.
- Confidence in contributing to the system rose 20%. The team opened up, and people moved from outsiders to participants.
- Component adoption: high-6s → high-8s, in a single cycle once UXE and the manager cohort were in place. The capacity build, showing up as teams actually using the system rather than forking it.
- Team-support and cross-team collaboration: mid-7s → low-9s. Evidence the work raised an already-functioning team, not just repaired a broken one.