The Problem

Our development teams were using different front-end technologies. We had Blazor, Angular, React, jQuery… agreeing to one framework was a long ways off. They were frequently using the same components, then having to edit each individually any time an improvement was needed for accessibility or usability.

Sprint after sprint, velocity was declining. Stories were taking longer than estimated, and developers were frustrated. I talked to several. Each had their own ideas on how to improve, but they often didn’t consider what other team were doing.

The issue? Poor developer experience (DX) in our own internal tools and codebase.

The Insight

As a product leader who codes, I noticed something others might have missed:

• Developers were spending 40% of their time fighting tooling and infrastructure
• The component library was inconsistent and poorly documented
• The company had recently invested in a brand refresh, and we weren’t seeing any of it in our applications
• CSS & stylesheets were all over the place
• The question we kept hearing - “what should this look like?”

UX isn’t just for end users — it’s for developers too.

The Solution

I led a 8-week initiative to improve developer experience:

1. Component Library Overhaul

• Pioneered a comprehensive design system
• Built reusable, well-documented components
• Technology agnostic
• Documented with copy & paste implementation guides for the first 12 components
• Created CI/CD pipeline with version control for a new theme that could be referenced in any web or mobile application, regardless of framework.

2. Documentation & Onboarding

• Created step by step setup guide in Confluence
• Provided documentation on how to improve the new theme stylesheet

3. The Emergence of a New Design System For All

• Enough said

The Results

Within a few weeks of implementation:

• 30% increase in development velocity
• New engineer onboarding time reduced from days to hours
• Developer satisfaction scores increased from 5.2 to 8.7/10
• The question “what should this look like” changed to, “how do I add to the system?”

Key Takeaway

Product thinking applies to everything you build—including internal tools. Invest in developer experience and you’ll see returns across every metric that matters.

As a product leader who codes, I bridge the gap between user experience and developer experience. Both matter. Both deserve the same level of craft and care.

I hate the term “technical debt”. I use, “technical opportunity”. Everything a team builds results in some debt (technical or UX). If we change our teminology to technical opportunity and dedicate at least 30% of each sprint, we should never find ourselves faced with the dreaded “rewrite” or “modernization effort”.