Developer Experience Is a Business Driver—And It’s Time We Treated It Like One

By Guillermo Manzo, Director of Developer Experience at Expedia Group

It’s 2025, and Developer Experience—what we call DevEx—isn’t just an engineering buzzword anymore. It’s becoming a real focus for modern tech orgs, and for good reason.

DevEx isn’t just about making developers feel good (though that helps). It’s about making software delivery faster, smoother, and more predictable. When we get DevEx right, teams waste less time, ship higher-quality code, and recover faster when things go sideways.

In other words, this isn’t just a “developer thing.” It’s a business performance thing.

That said, I’ve noticed that DevEx still feels a little fuzzy outside of engineering leadership. If you’re a CFO or COO, you probably hear a lot about speeding up delivery, improving productivity, and “investing in platforms.” But it’s not always clear how that connects to business results, especially when we start throwing around acronyms like “CI/CD” and metrics like “cycle time”.

So, I wanted to break it down.

DevEx Is About Smoothing the Path to Delivery

Let’s start with what Developer Experience actually means. Think of it this way: DevEx is everything that shapes how developers get their work done, from the tools they use to the workflows they follow to the time it takes to go from idea to shipped feature.

In practical terms, that covers a lot: writing code, reviewing it, testing it, deploying it, and responding when something breaks. But it also includes how easily developers can find the info they need, collaborate across teams, or onboard onto a new repo or system.

When DevEx is good, work flows. When it’s not, you get friction. And friction—slow builds, broken pipelines, unclear processes—shows up as delays, bugs, rework, burnout, and, eventually, attrition.

Our job in DevEx is to smooth that path. We reduce bottlenecks, clean up broken tools, standardize workflows, and help developers stay focused on what matters.

Why Developer Experience Matters (Beyond Engineering)

Now, you might be thinking: Okay, that sounds nice, but what’s the actual impact?

Here’s the deal. Every minute a developer spends fighting a flaky test suite, waiting on a code review, or trying to figure out how to deploy something, is time they’re not spending delivering value. Multiply that across dozens (or hundreds) of engineers, and it adds up quickly.

We’re not talking about abstract benefits here. The numbers back this up. GitHub found that developers working in high-flow environments where DevEx is strong are 50% more productive, and 75% say they’re significantly happier in their jobs. Gartner projects that companies investing in DevEx will double developer retention by 2027 compared to those that don’t.

That’s not just good for morale. That’s better throughput, lower recruiting costs, and more consistent delivery.

How to Talk About DevEx in Business Terms

Here’s where I think we (engineering folks) sometimes miss the mark—we explain DevEx using metrics that matter to us, but not necessarily to the rest of the business.

We talk about things like “lead time for changes” or “deployment frequency.” But we need to reframe those metrics in terms of business outcomes.

If we speed up code reviews, we can launch products or features sooner, and respond to customer feedback more quickly. Reducing cognitive load (a fancy way of saying we make things less mentally exhausting) leads to fewer mistakes and lower turnover. And when we clean up our CI/CD pipeline, we reduce the number of outages and unplanned work, which means teams can focus on roadmap goals instead of constantly putting out fires.

In business terms, that means: faster time to market, lower costs from rework and downtime, higher retention and easier hiring, fewer outages and incidents, and better planning and delivery forecasts.

The best DevEx teams I’ve seen aren’t just making improvements behind the scenes, they’re showing how those improvements drive results. They’re tying engineering metrics to OKRs like delivery capacity, customer satisfaction, or churn reduction.

That’s when DevEx started being taken seriously—not just as an engineering initiative but as a lever for business performance.

How AI and Automation Is Changing DevEx

Let’s talk about AI for a second, because it’s a huge part of where DevEx is headed.

With tools like GitHub Copilot, large language models, and SEI platforms, we can now automate all kinds of tedious tasks—from generating code snippets to routing pull requests to the right reviewer. We can flag risky changes, auto-merge safe ones, and run security scans on every commit.

All of that reduces toil, speeds things up, and gives developers more time to focus on complex, high-value work. But it also adds complexity. That’s where DevEx teams come in again—we help govern this new landscape. We make sure AI-generated code is still reviewed. We enforce test coverage. We build compliance directly into the pipeline instead of tacking it on at the end.

These aren’t massive transformations. They’re small, targeted improvements that compound over time. Think of them like compound interest for your engineering org.

Scaling DevEx: What’s the ROI?

If you’re wondering how to evaluate whether DevEx is “worth it,” start by asking some simple questions.

How long does it take to onboard a new developer? How much time does your team lose to broken builds, flaky tests, or unclear deployment processes? What would happen if you shaved 20% off your average lead time? What’s the cost of an outage that could’ve been caught with better testing or observability?

These are the kinds of questions we ask ourselves every day in DevEx—and the kinds of results we can start measuring once we make targeted improvements.

When we pair that data with before-and-after stories, industry benchmarks, and clear outcomes, it becomes a lot easier to make the case. DevEx stops sounding like a developer wish list and starts sounding like what it is: a strategic investment in speed, stability, and scale.

Final Thoughts

Developer Experience is the foundation for how modern engineering teams build, ship, and scale. And in a world where software is at the heart of everything, that foundation really matters.

If we want engineering leaders to move faster, hire better, deliver more predictably, and retain top talent, we have to treat DevEx as a core business function, and not just a side project.

It’s not about adding more tools. It’s about removing friction. It’s not about making developers happy for the sake of it. It’s about helping teams do better work, faster.

And ultimately, it’s not just about engineering. It’s about outcomes the whole company can feel.