We Finally Measured DevEx. Now Our Leaders Are Burning Out Creating It

General
1

Six months ago, we implemented comprehensive Developer Experience metrics at my financial services company. Time to first deploy. Onboarding duration. Platform adoption rates. Manual intervention frequency. All the leading indicators the research told us would predict delivery speed and stability.

And it worked. Beautifully.

Our retention improved 25%. We’re saving each developer 13 minutes per week. We have clear leading indicators that surface risk before it becomes missed deadlines or attrition. We can finally prove the business value of our platform engineering investments.

But Here’s What Nobody Talks About

Last month, I attended a LeadDev meetup. A survey of 617 engineering leaders revealed that 22% of us face critical burnout levels right now. Not mild stress. Not “busy season.” Critical burnout.

I looked around the room. Then I looked at my own team. Two of my platform engineering leads are working 55+ hour weeks. One told me last week she’s “hanging on by a thread.” Another is looking for jobs.

We’re building better developer experience by destroying leadership experience.

The Data Is Stark

  • 83% of developers report burnout
  • 47% cite high workloads as the top cause
  • 42% of platform engineers say leadership overrides their technical decisions
  • 45.3% of platform teams cite developer adoption as their top challenge—not because of technical complexity, but cultural resistance
  • 68% of developers cite lack of trust from leadership as a burnout contributor

Source: 2026 Tech Trends for Engineering Leaders, Platform Engineering DevX Strategies, Leadership Strategies to Scale Engineering Teams

The Paradoxes Are Everywhere

We’re measuring flow state for developers while engineering leaders context-switch constantly between strategy and firefighting.

We’re tracking cognitive load for ICs while directors shoulder the organizational change management of platform adoption.

We’re building tools to reduce toil while platform teams drown in TicketOps because executives see DevEx as “something engineers do for each other” rather than a funded product initiative.

We’re emphasizing trust and psychological safety when leaders are too burned out to show up authentically.

I’m Not Anti-DevEx

To be clear: measuring developer experience is good. The metrics work. DORA’s research shows that speed and stability aren’t tradeoffs—they’re correlated. Leading indicators surface problems early. DevEx improvements boost retention and make engineering organizations more effective.

But we’ve created a sustainability crisis for the people building and enabling these improvements.

When platform teams are understaffed, when they’re seen as cost centers rather than product teams, when they’re expected to deliver world-class internal tools on nights-and-weekends energy—we’re not building sustainable organizations. We’re just shifting the burnout from ICs to leaders.

The Questions That Keep Me Up

  • How do we create great developer experience without sacrificing leadership wellness?
  • What does it look like to fund DevEx properly rather than treating it as “giving back”?
  • Should platform teams have product managers? Career paths? Rotation models for TicketOps?
  • At what point do we measure platform team health as rigorously as we measure developer productivity?

I’d love to hear from other engineering leaders: Have you found ways to improve DevEx sustainably? What models actually work for protecting the people who build platforms?

And if you’re a platform engineer reading this: what would make your job sustainable? What support do you actually need?

2

Coming from the design systems world, I see this exact same pattern. Design systems are basically DevEx for designers and frontend engineers, and we face the identical paradox.

My Burnout Story

Last year, I built a comprehensive design system for our product org. Component library. Design tokens. Figma plugin. Adoption metrics. Documentation. The works.

Our design team went from 2 weeks to ship a feature to 4 days. Frontend engineers stopped reinventing buttons. Brand consistency improved. Accessibility improved. Every metric said: success.

But my team of 3 burned down to 1. Me. And I nearly quit.

We Call This “Invisible Infrastructure Tax”

In the design systems community, we have a name for this: the invisible infrastructure tax. Because design systems work requires:

Education - No one teaches this in design school or bootcamps
Evangelism - Selling adoption to designers who have “their way” of doing things
Maintenance - Keeping up with design trends, framework updates, new use cases
Support - Answering questions, debugging issues, holding hands
Strategy - Roadmap planning, prioritization, saying no to feature requests

All while your “real” work—the designs you’re actually measured on—still needs to happen.

The Failure Pattern I’ve Seen Everywhere

  1. Start as 1 person side-hustle (“20% time”)
  2. Gets momentum, becomes “strategic initiative”
  3. Still 1-2 people, now with visibility and metrics
  4. Burnout becomes inevitable

Sound familiar?

What Actually Works

The only teams I’ve seen succeed treat systems work as a separate product team with dedicated headcount.

Not “engineers who also maintain the platform.”
Not “20% time for design system work.”
A real product team with:

  • Dedicated roles (not borrowed capacity)
  • Product management (someone who says no and sets roadmap)
  • Support rotation (no permanent on-call hell)
  • Success metrics separate from feature delivery

At my previous company (before I joined my current role), the design system team had 5 people: 2 designers, 2 engineers, 1 PM. They ran sprints. They had a roadmap. They had a support SLA.

That team didn’t burn out. Because they were resourced for the actual job.

My Question for Engineering Leaders

Do your platform teams have product managers? Should they?

I’m genuinely curious because in design, the successful teams treat it like a product. But I hear a lot of platform teams are “engineers managing themselves” which… seems like a recipe for exactly what Luis described.

What’s the model that works?

3

CTO perspective here. I think what we’re seeing is a resource allocation failure, not a DevEx problem.

The Root Cause: We Treat DevEx as Free

Organizations treat platform engineering like engineers “giving back” to engineering. It’s volunteerism dressed up as a job function.

Here’s why the math doesn’t work:

40 developers × 13 min/week saved = 8.7 hours/week total
2 platform engineers @ 55 hours/week = 30 hours/week overtime

Net result: losing 21.3 hours/week of sustainable capacity

We’re destroying value, not creating it.

What Real Investment Looks Like

When I joined my current company as CTO, I inherited a 2-person platform team supporting 50 engineers. Both were senior engineers working weekends. One had a therapist on speed dial.

Here’s what I changed:

1. Dedicated Platform Team (Not “20% Time”)

  • Hired 3 more platform engineers
  • Made it a real team with career paths
  • Stopped pulling people “temporarily” for feature work

2. Product Management for Internal Tools

  • Hired a PM specifically for platform
  • Platform team has roadmap, says no to requests
  • Success metrics separate from feature delivery

3. Rotation Model for Support

  • Created TicketOps rotation (2 weeks on, 6 weeks off)
  • Escalation paths so platform team isn’t always first responder
  • Support metrics that flag when to hire

4. Buffer Capacity

  • Platform team runs at 75% planned capacity
  • 25% slack for experimentation, tech debt, emergencies
  • No “everyone at 100% utilization” death march

5. Board-Level Visibility

  • DevEx is a board metric alongside revenue, retention
  • Platform team budget justified same way as product teams
  • Leadership burnout tracked quarterly

The Business Case

When I presented this to our board, I showed them:

Cost of current model:

  • 2 burned-out engineers @ K = K/year
  • Estimated replacement cost when they leave: K (hiring + ramp)
  • Productivity loss during burnout: ~K/year
  • Total annual cost: ~.15M

Cost of proper investment:

  • 5-person platform team = M/year
  • PM for platform = K/year
  • Total: .18M/year

For an extra K/year, we get a sustainable model that doesn’t destroy people.

The board approved it in 15 minutes.

But Here’s the Hard Question

How do you prove a platform team is understaffed vs. inefficient?

I use:

  • Time to fulfill requests (SLA-based)
  • TicketOps volume per engineer
  • Unplanned work ratio (firefighting vs. roadmap)
  • Team sentiment (pulse surveys)

But I’m still figuring this out.

Challenge to the Room

Has anyone successfully justified platform team growth to their board or executive team? What metrics convinced them?

Because I think this is the core unlock: if we can’t prove the ROI of proper staffing, we’ll keep under-resourcing these teams and burning people out.

4

Product perspective here, and I think Michelle hit on something critical: internal tools suffer from the “non-paying customer” problem.

I’ve worked at Google, Airbnb, and now a fintech startup. I’ve seen this pattern everywhere.

The Cost Center Trap

Here’s how platform teams get stuck:

  • No clear customer - “Everyone” is not a customer persona
  • No revenue attribution - Can’t tie DevEx to dollars directly
  • Gets cut first during budget pressure because impact is “fuzzy”
  • Measured on happiness (subjective) not business outcomes (objective)

This is a product management failure, not an engineering failure.

Controversial Take: DevEx Needs Product Management

Platform teams should run like product teams. Full stop.

That means:

1. Define Internal Customers

Not “developers” generically. Specific teams, roles, use cases:

  • Frontend engineers shipping customer features
  • Backend engineers managing services
  • Data engineers building pipelines
  • DevOps maintaining infrastructure

Each has different needs. Each is a customer segment.

2. Measure Like SaaS

  • Adoption rate - what % of engineers use your tools?
  • NPS - would they recommend to other teams?
  • Retention - do teams stick with your tools or route around them?
  • Time to value - how fast can new users be productive?

3. Build Roadmap Based on Customer Development

  • Customer advisory boards (engineer representatives)
  • Regular user research (yes, with internal users)
  • Usage analytics (which tools/features actually get used?)
  • Ruthless prioritization (say no to feature requests)

4. Track Business Outcomes, Not Activity

Don’t measure “tickets closed” or “features shipped.”

Measure:

  • Deployment frequency → shipping speed → revenue impact
  • Onboarding time → time-to-productivity → hiring ROI
  • Platform adoption → reduced tech debt → quality/security
  • Developer retention → hiring cost savings

Example: Airbnb’s Internal Tools Team

At Airbnb, the internal tools team ran exactly like this. They had:

  • Product managers who said no to requests
  • Usage analytics tracking tool adoption
  • Quarterly business reviews with exec team
  • Success metrics tied to company objectives

When they pitched for headcount, they showed:

  • “Our CI/CD improvements saved 2.3 hours per engineer per week”
  • “That’s 230 hours/week across 100 engineers”
  • “At K average salary, that’s .7M/year in productivity gains”
  • “We’re asking for K in additional headcount”

The CFO approved it immediately. Because it was a business case, not a feelings case.

The Question Platform Teams Should Ask

Instead of “how do we get engineers to adopt our tools?”

Ask: “What business outcome would change if adoption went from 40% to 80%?”

If you can’t answer that, you don’t have a product—you have a hobby project.

But Here’s the Risk

Adding product management overhead might increase burnout if it’s just more process on top of understaffed teams.

So I’d ask the engineers in the room: Would treating platform like a product team help or hurt?

Would having someone who:

  • Says no to requests
  • Prioritizes roadmap
  • Justifies ROI to execs
  • Shields you from stakeholder chaos

…make your job easier? Or just add another layer of bureaucracy?

I genuinely don’t know. In product orgs, PMs reduce chaos. But I’ve heard engineers say “we don’t need PMs, we need more engineers.”

What’s the right model?