Developer Experience is not an engineering problem. It’s a CEO decision.
Most technical leaders I’ve met are passionate about DX — better tooling, faster pipelines, cleaner workflows. What they often can’t do is get leadership to treat it as a strategic priority. The conversation stalls at “nice to have.” The headcount goes elsewhere. The friction accumulates — quietly, until it shows up in attrition or a slipped roadmap.
That gap is expensive.
Leading DX and Platform Engineering at Booking.com and TomTom — enabling thousands of engineers — I kept seeing the same pattern. The teams that moved fastest weren’t the ones with the best technology. They were the ones where engineers trusted the platform. Where something failing in production was caught before it became their problem. Where shipping didn’t require courage.
That trust is a culture decision. It comes from leadership — not from a tooling choice or a morale initiative, but from a consistent signal that engineering experience is a strategic input to delivery speed. It cannot be delegated to an engineering team working in isolation, however capable they are.
The cognitive load equation is straightforward: an engineer who doesn’t trust the safety net works slowly and carefully. One who does moves fast and builds more. The difference shows up in your release cadence, attrition numbers, and time-to-market — not in an engineering dashboard.
DX investments are hard to measure precisely. That’s not a reason to avoid them. It’s a reason to own them at the top.
You don’t need to understand the tooling. You need to understand that your engineering org moves at the speed its experience allows. The companies that get this right don’t have better engineers. They have leadership that chose not to delegate the culture of engineering.
If you’re a founder scaling past 50 engineers: when did you last ask your team what’s slowing them down — and then act on the answer?
The ones who do are building engineering cultures that actually scale.