Building Helios.

Why we replaced the old system.

Design and code were out of sync, and adoption was uneven.

The code was hard to scale, too. I argued for replacing the system rather than continuing to extend it. There was significant internal pushback on that decision.

Once Helios was in use, the dashboard we built tracked its adoption alongside the legacy components it was replacing. We could see where teams had moved over and where they needed help.

The tradeoff. Starting over meant spending time on a replacement before teams could use it. It also meant taking on the work of migrating from the old system.

Across the product suite.

Teams needed consistency and room to handle their own product’s needs.

HashiCorp’s infrastructure and security products covered different workflows, and HCP was growing. The components needed to work across that range of interfaces.

We had to decide what should be consistent and where teams needed room to adapt.

The tradeoff. More customization helped teams handle cases we hadn’t covered, but also made it easier for interfaces to diverge.

What we expected from a component.

Documentation, accessibility, and Figma parity were part of the work.

A component needed to be documented, accessible, and ready for the different ways teams would use it. The Figma library and the code had to agree.

The tradeoff. That took longer than shipping the code alone, and sometimes meant a product team had to wait.

We built what the products needed.

Product teams had work to ship while we were building and changing the system.

We worked with teams to understand what they were building and how they would use a component. That shaped what we built and how it worked.

I also led discovery and proofs of concept for our move to TypeScript and GTS.

The move from Helios to IBM Carbon is happening incrementally too, so teams can adopt it alongside their product work without having to rewrite their applications.

The tradeoff. Working from current product needs meant some requests had to wait.

Accessibility had an owner.

We hired for accessibility expertise alongside design and engineering.

I recruited and backed the leader who built HashiCorp’s accessibility function. That work helped us build accessibility into the components and support teams across the company.

An improvement to a shared component could then carry through to the products using it.

The tradeoff. This required dedicated people and time, including work that wouldn’t appear on a product’s feature roadmap. It also helped us produce stronger VPATs and support enterprise deals.

Working with product teams.

We needed feedback from the people using Helios.

I defined the roles and hiring profiles for engineering, design, and accessibility in one group. The team was responsible for both the Figma library and the code.

Designers and engineers worked through disagreements within the team and kept the two implementations in sync.

Guilds, office hours, and regular conversations with product teams helped us understand the problems they were running into and work through the migration.

The tradeoff. Some of those conversations were difficult. We couldn’t always do what a team was asking for, and sometimes we decided not to.