Skip to main content

Command Palette

Search for a command to run...

Developer Experience is a business problem, not an engineering one

Updated
2 min read

Developer Experience is usually treated as an engineering concern.

Better tooling. Cleaner APIs. Better docs.

All important. All incomplete

The reason Developer Experience keeps resurfacing as a problem is that it’s rarely owned as a business outcome.

Poor DX doesn’t just frustrate engineers. It slows delivery, increases risk, and quietly taxes the organisation, every integration takes longer, every new feature hits the same friction, every team rebuilds similar solutions.

When DX is framed purely as an engineering issue, a few things tend to happen:

  • Investment is reactive rather than intentional

  • Trade-offs are made locally instead of systemically

  • Improvements struggle to compete with feature work

None of that is surprising. Engineering teams are incentivised to ship features for users, not optimise the experience of building for other engineers. That's not wrong, it's just incomplete when no one owns the system-level view.

The moment DX becomes a business problem, the conversation changes.

Instead of asking, “How do we improve tooling?”, the questions become:

  • Where are we losing time repeatedly?

  • What friction shows up across multiple teams?

  • What’s the cost of not fixing this?

Those questions create space for prioritisation, not just goodwill.

Another shift is accountability.

When DX is owned at a product or platform level, decisions about standards, abstractions, and constraints become deliberate. The goal shifts from 'make everything possible' to 'make the common path easy and the exceptions explicit.

In my experience, the best DX work is almost invisible.

It shows up as:

  • Fewer exceptions

  • More predictable delivery

  • Teams spending less time on plumbing and more on value

That’s not an engineering win alone.

That’s a business one.

In one organisation, we measured that authentication setup took new services 2-3 days. Not because it was technically hard, but because the process was undocumented and inconsistent. Standardising it to a single afternoon wasn't a feature launch, but it saved every new team 1-2 days from that point forward.

That's DX as a business outcome.

Good DX reduces costs you never see on a spreadsheet.

If building is hard, scaling is harder.

More from this blog

L

Leverage Points - Product & Tech

37 posts

Insights on product strategy, platform thinking, and career decisions that create disproportionate impact. For PMs who want to understand where effort matters most.