What Is Developer Experience (DevEx) and Why It Matters
How to measure Developer Experience with self-reported and system data like DORA metrics?
At PlatformCon, one thing became clear to me: Platform Engineering and Developer Experience are inseparable. You can’t build a successful platform without thinking about how it feels to use, not just how it works.
Platform Engineering isn’t only about software and systems engineering anymore. It’s also about discovery and delivery — understanding what developers need and building the right things in the right way. That means embracing:
➤ Product Mindset – treating your platform as a product
➤ Developer Experience – reducing friction and cognitive load
➤ Metrics – so you can measure what matters and improve it
In short, DevEx is what makes your platform usable, valuable, and adopted. And that’s why it should be at the heart of how you approach Platform Engineering.
DevEx at Twilio
At Twilio, Developer Experience is treated as a core cultural and strategic priority. While the company had already implemented DORA metrics and a consistent review process, they found that these performance indicators didn’t fully capture the developers’ lived experience.
Recognizing this gap, Twilio shifted toward a more holistic, sentiment-driven approach by launching structured Developer Experience surveys in partnership with DX.
The initiative quickly gained traction, achieving a 90% response rate and rich qualitative feedback. Over eight quarters, these insights have directly shaped the internal platform roadmap and helped teams identify and act on local improvement opportunities. DevEx at Twilio isn’t just about metrics — it’s about actively listening to developers and embedding their voice into how the platform evolves.
Listen more about it in this panel discussion led by Dominique Simoneau-Ritchie, Chief Technology Officer at Affinity, David Betts, Senior Engineering Manager at Twilio, Abi Noda, Co-Founder at DX, Mayanna Rayko, VP of Engineering at TrueLayer and Adam Rogal, Director of Engineering at DoorDash.
Involving Application Teams
While Twilio’s Developer Experience (DevEx) surveys provided valuable insight, one of the biggest challenges was helping engineering leaders understand how to act on the data.
There was a common misconception that the platform engineering team alone was responsible for fixing all identified issues, from documentation to on-call experience.
To address this, the platform team not only used the survey results to shape their own roadmap but also focused on educating team leads. They guided them on how to interpret the feedback and take local ownership of improvements.
By distributing responsibility and enabling teams to act on specific drivers, Twilio turned DevEx into a shared, organization-wide effort rather than a siloed initiative.
Qualitative vs Quantitative Data
When it comes to measuring Developer Experience, Abi Noda, Co-Founder of DX, leans into using both quantitative and qualitative data.
They break it down simply:
Quantitative = system-based metrics,
Qualitative = self-reported by developers.
The truth is, system data is great when it’s available and relevant, but a lot of the real pain points developers face don’t show up in dashboards.
There are questions that probably no organization in our industry can answer well:
How much are developers interrupted?
How good is the documentation?
How much time do developers spend daily or weekly dealing with painful infrastructure issues?
How easy is it for developers to actually understand and work with the code that they're supposed to be modifying?
How often do weeks of work get wasted because a project wasn't defined well in the first place?
That’s why self-reported insights from DevEx surveys are so valuable. They help capture the human side of developer productivity — the stuff no script or log file will ever fully tell you.
According to Abi Noda. Those are all very common questions in the industry.
Developer Experience Pitfalls
That reminded me of a recent conversation with Anita Zbieg, CEO of Network Perspective, and Jon Kern (Co-Author of Agile Manifesto) about Developer Experience. They create robust DevEx Surveys at their company, Network Perspectives.
They are doing very insightful and important work on understanding Developer Productivity and Developer Experience.
Here are a couple of points from our conversation:
➤ Emphasis on meaningful work - strong focus on delivering real value (rather than just looking good on paper or hitting easily gamed metrics).
➤ Concern for developer motivation – recognition that motivation is critical, and that when developers stop caring or even stop complaining, it’s a warning sign.
➤ Pragmatic approach to process – asking the right questions is more valuable than layering on procedures, which may lead to “Frankenstein processes.”
Adam Rogal, Director of Engineering at DoorDash, made an interesting comparison of those typical issues we repeatedly find:
If you ask someone what bothers them about getting to work, they'll probably mention traffic, crowded trains, or tolls - the usual suspects. You can make improvements, but those are going to show up time and time again.
Adam Rogal, Director of Engineering, DoorDash
It might sound obvious, but it was honestly a relief to see that everyone faces similar challenges. Even when you fix some of them, they may creep up in a different form some time later.
So instead of getting frustrated, we accept this as part of the journey. Let’s keep trying to make the most of what we can. And just as importantly, celebrate the wins and the hard work of the teams.
Celebrating and Showcasing the Wins
Twilio keeps developer survey engagement high by closing the feedback loop.
When a new platform feature is released and leads to improved sentiment in a specific area, they highlight that connection in their next survey follow-up.
We want to make the developers feel like they're investing the time in providing this data results in valuable changes. And I think that's why we continue to see a 90% participation rate in our quarterly survey.
David Betts, Senior Engineering Manager, Twilio
At OutSystems, where I work as a Principal Technical Program Manager for Platform Engineering Initiatives, we faced a significant challenge. In 2024, our quarterly developer surveys consistently showed that the deployment experience had the lowest satisfaction score.
To address this, we decided to build a new CI/CD platform, aiming to dramatically improve this core development journey. Our target was ambitious: reduce lead times by 10x without sacrificing quality. We're proud to say we delivered on that promise.
Our data reveals a stark contrast: on the legacy platform, some teams spent over 200 hours to deploy a change to production. Today, with the new platform, those same changes take under 24 hours. This truly represents a 10x improvement.
This dramatic enhancement not only streamlines our development process but also positions us among the Elite Performers according to DORA metrics.
Be the Chief Evangelist of the Platform Team
If you lead a platform team, you’re not just building tools — you’re building belief.
If you are a leader of a platform team, you need to be the chief evangelist. You need to be out there constantly talking about what your peers are doing at the company and what awesome stuff they're coming up with.
Adam Rogal, Director of Engineering, DoorDash
Create internal buzz. Run early-access or insider programs. Empower developer advocates from within. Build energy, trust, and a strong internal network around your platform.
Pair that with a commitment to closing feedback loops and celebrating the wins, and you’ll start building the one thing that makes all the difference: trust.
Because at the end of the day, Developer Experience isn’t just a nice-to-have — it’s what makes Platform Engineering actually work. And that only happens when we listen deeply, build intentionally, and treat our platform like a product that developers love.
Let’s build that kind of platform.