Developer Experience is a business problem, not an engineering one
I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. I focus on maturing complex systems, improving the experience for both users and developers and strengthening the foundations that make products reliable, scalable and easy to build on. I care about clarity, good judgement and creating the processes and environments that help teams deliver consistent, long-term impact. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovation competitions.
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.