Let me do the math for our 80-person engineering org:
1-point DX improvement = 10 hours/year/developer
80 developers × 10 hours = 800 hours annually
At k average fully-loaded cost = ~/hour
ROI: ~,000 per year from a 1-point DX improvement
And that’s just the productivity calculation. It doesn’t account for:
Reduced turnover (happier developers stay longer)
Better hiring (strong DX is a competitive advantage)
Higher quality output (developers in flow state ship better work)
Faster ramp time for new hires
Yet most organizations still treat DX as “nice to have.”
We invest heavily in infrastructure: CI/CD pipelines, monitoring, deployment automation. Those are seen as essential. But DX investments—better build times, streamlined local development, reduced cognitive load—often get deprioritized.
Why the gap? Infrastructure failures are loud and visible. Poor DX is silent and chronic. A deployment pipeline breaking stops everyone immediately. Slow builds and context switching tax every developer every day, but gradually.
The questions for engineering leaders:
Do you track DX metrics as rigorously as infrastructure reliability?
Are you investing in DX proportionally to the ROI?
What would need to change to make DX a first-class investment category?
I’m trying to shift this at our org. Making the case that DX isn’t a perk—it’s infrastructure for developer productivity.
This resonates deeply. I’ve been fighting this battle for years: getting budget allocation for DX investments.
Your point about loud vs silent failures is exactly the problem. When CI breaks, everyone notices immediately and leadership asks what’s being done to fix it. When builds are slow, context switching is high, or local dev setup takes 2 hours, it just becomes “how things are.”
Making the business case with data helps.
Here’s what worked for us:
Survey developers quarterly on the three DX dimensions (feedback loops, cognitive load, flow state)
Track the DX Core 4 metrics: build time, deployment frequency, PR cycle time, onboarding time
Calculate ROI exactly like you did—convert time savings to dollar value
Present to leadership with specific proposed investments and projected returns
Once we had data showing that reducing build time from 15 minutes to 5 minutes would save k annually across our team, the budget approval became straightforward.
The challenge: DX improvements often require sustained investment, not one-time fixes. It’s engineering infrastructure work—refactoring build systems, optimizing CI, improving tooling. These aren’t features the business can see, so they compete poorly against product work in prioritization.
What’s worked: Treating DX as technical infrastructure with dedicated capacity (we allocate 20% of platform team time to DX improvements). Not a side project, not “when we have time”—a permanent allocation.
This is EXACTLY the same challenge we face with design systems. The ROI is obvious once you measure it, but getting initial buy-in is hard.
Design systems parallel:
When we pitched our design system rebuild, the response was: “Why invest 3 months when we could ship features instead?”
The answer: Because every designer and developer wastes 2+ hours per week recreating components, checking for consistency, and fixing visual bugs. Multiply that by the team, and we’re burning hundreds of hours annually on repeated work.
Once we built the design system, the value became undeniable:
Component reuse went from 30% to 85%
Design-to-dev handoff time cut in half
Visual inconsistencies dropped 90%
New feature development sped up 40%
But here’s the key: we needed executive champions.
Luis’s approach of data-driven ROI cases is critical. But equally important: finding leadership who intrinsically understands that infrastructure enables velocity.
In our case, our CTO championed design systems because they understood that every hour saved in implementation is an hour gained for innovation. DX investments are the same—they’re force multipliers.
The question I ask skeptical stakeholders: Would you rather have developers spending time building features or fighting tooling? Because slow builds, painful deploys, and context-heavy workflows all mean less time on actual product work.
From a product perspective, better DX directly translates to better product velocity.
This isn’t just an engineering concern—it’s a product delivery concern. When I’m planning roadmaps and setting quarterly OKRs, DX is a critical input.
Here’s how I think about it:
If our engineering team can ship 8 features per quarter with poor DX, maybe they could ship 10-12 features with optimized DX. That’s a 25-50% increase in product delivery capacity.
That extra capacity means:
Faster response to market opportunities
More experiments to find product-market fit
Reduced time-to-market for competitive features
Better ability to tackle technical debt alongside feature work
DX should be an OKR-level metric, not a side project.
In our quarterly planning, we now include “Developer Experience Score” alongside product delivery metrics. This makes DX visible to the entire leadership team, not just engineering.
When product, design, and engineering leadership all understand that DX improvements = faster delivery, the prioritization conversation changes. It’s no longer “DX work vs feature work.” It’s “short-term features vs long-term feature velocity.”\n\nMaya’s point about executive champions is crucial. Once your CPO or CEO understands that DX investment accelerates every future feature, it becomes strategic, not discretionary.