Every company I’ve worked with has at least one platform that exists, that people are required to use, and that nobody would choose if they had an alternative.
A few years ago I worked with a large manufacturing enterprise. Seven hundred developers. A platform team of nine — experienced, well-resourced, genuinely motivated. They spent six months building a golden path: standardised pipelines, curated tooling, a documentation site that actually looked maintained. They launched it. They sent the announcement. They mandated it.
Then I asked to see the Slack channel.
Fourteen messages over six months. Eleven of them from the platform team itself. Then I asked when they last observed a developer actually using their platform. They never had.
The developers weren’t obstructionist. They were using the tools they already knew — the ones that fit how they worked — and quietly routing around the new ones whenever they could. Nobody was sabotaging anything. Nobody needed to.
This isn’t a story about a bad platform team. It’s a story about what happens when a platform gets built for the organisation instead of for the developers using it. And it’s far more common than most engineering leaders want to admit.
The awareness gap isn’t the gap
Most engineering leaders already know developer experience (DX) matters. That awareness is no longer the problem.
The problem is the distance between knowing it matters and doing something structured about it — and specifically, between building what you think developers need and finding out what they actually need before you commit.
That distinction sounds minor. The cost of getting it wrong is not.
What poor DX actually costs
The numbers rarely make it into the conversations where platform investment decisions get made. They should.
Developers lose roughly 22% of their time to inefficiencies — context switching, broken tooling, unclear documentation, slow pipelines. DX Research puts the aggregate cost at $1.55 billion in lost productivity, based on an average fully loaded developer cost of $250,000. At scale, that’s not a workflow problem. It’s a strategic one, compounding silently in ways that don’t surface on any dashboard.
Retention is where it gets expensive fast. According to SHRM, replacing a developer costs between 50% and 200% of their annual salary — before you factor in the institutional knowledge that walks out, or the momentum that stalls while a replacement gets up to speed. Developers talk. Poor DX builds a reputation long before it shows up in exit interviews.
Then there’s the compounding return of getting it right. When Spotify deployed Backstage internally, they cut developer onboarding time by 55% — measured not by paperwork, but by time to the 10th pull request. That kind of improvement shows up in product velocity, hiring pitch, and the ability to scale without endlessly increasing headcount.
Underneath all of it: developers who fight their environment don’t just produce less. They disengage. The team lead is usually the last to know, and by the time it surfaces, you’ve lost something harder to recover than throughput.
The four excuses
I’ve heard all of them. You’ve probably said at least one. I did.
“We don’t have the bandwidth right now.” There’s always a delivery deadline, a migration, a reorg. The research gets deprioritised. The platform gets built on assumptions instead. This is understandable — it’s also how you end up six months later explaining to leadership why adoption is being enforced rather than earned.
“We ran a survey last year.” A survey is not a discovery. Aggregate satisfaction scores tell you what developers think when you ask them a direct question in a format that constrains what they can say. They don’t tell you why the CI pipeline makes people want to quit, or what the workaround is that everyone uses but nobody documents. Surveys measure. Discovery understands. Both are useful. They are not the same thing.
“The team will adopt it once it’s better.” It’s been eighteen months. Adoption is still mandated. The Slack channel has a handful of messages in it, most of them from the platform team. At some point, “once it’s better” becomes a way of avoiding a harder question: better for whom?
“We already know what developers need.” This one does the most damage, because it sounds the most reasonable. You’ve been a developer. Your platform leads are developers. You have strong instincts and years of pattern recognition. Surely that’s enough.
It isn’t. The reason is structural, not personal. The false consensus effect (the tendency to assume others share your experiences and pain points) leads people to project their own reality onto their users. Being a developer — or having been one — doesn’t make you a proxy for your users. It makes you a particularly confident one. That confidence is exactly what gets in the way.
Why it keeps happening
The root cause is almost never bad intentions or bad developers. It’s a structural imbalance in how platform decisions get made.
I think of it as a triangle. Three forces shape every internal platform: enterprise architecture requirements, business goals and constraints, and developer reality — what developers are actually trying to do, where friction lives, what they’ll adopt. In a well-functioning organisation, all three carry real weight.
In practice, the platform almost always drifts toward the first two.
Business urgency creates momentum. New technology creates excitement. And in that momentum, the people who will use what gets built never factor into the decision.
Here’s the mechanism. Business urgency creates a forcing function — a cost target, a delivery commitment, a strategic initiative that needs tooling support by Q3. New technology creates excitement that makes inaction feel irresponsible. And in that momentum, the developers who will use what gets built either get consulted too late or not at all. By the time they’re in the room, the decisions have already been made. Their feedback becomes a post-hoc sense-check, not an input.
The triangle tilts. The platform reflects the organisation’s priorities and the technology team’s instincts. And the developers get something they’re required to use, built on assumptions that were never tested.
Four situations where this shows up
The adoption problem surfaces in recognisable patterns. See if any of these fit.
You want to improve developer experience, but you can’t point to where the friction lives. The intent is there. The investment case isn’t — because nobody can say with certainty what’s worth fixing, or what fixing it would actually return.
Something in your development lifecycle is slowing teams down. You have signals — complaints in retros, slow cycle times, workarounds that have become standard practice. Not enough to act on with confidence. Too consistent to ignore.
You’re building or evolving a platform and need to validate the direction. The business case exists. What’s missing is clarity on who you’re building for, what they’ll adopt, and whether your current direction maps to the actual problem.
You have a platform with low adoption. Usage is mandated. Voluntary uptake is close to zero. You suspect the platform isn’t solving the right problem — but without structured evidence, the conversation with leadership stalls.
In each case, the gap is the same: too much uncertainty to commit, too little evidence to prioritise. And if you build anyway, you already know where it ends.
What closes the gap
A Developer Experience Discovery (DX Discovery). Not a survey, not a workshop — a structured research effort scoped to the right cohort of developers, asking the right questions at the right level of the organisation, that produces one thing: confidence. The kind that lets you make a sound investment decision, take it into a funding conversation, or walk away before the cost of being wrong gets high.
The methodology I use has four phases: Frame, Research, Analyse & Ideate, and Define & Prioritize. The next article in this series covers each one in depth. The short version: discovery tells you who your developers are and what they’re actually trying to do, where the friction lives and what it costs, and whether what you’re planning to build will earn adoption or merely mandate it.
It doesn’t have to be heavy. A well-scoped discovery moves in weeks, not months. The bottleneck is almost never the research. It’s the decision to start.
The platform teams getting this right aren’t the ones with the biggest budgets. They’re the ones who found out before they committed.
Next in this series: why scoping your research correctly matters more than the research itself — and the methodology that puts it into practice.