Understanding developer experience is vital when you want to improve the work engagement and productivity of the developers within your engineering organization. We’ll cover what developer experience is, why it is important, and how to measure and improve it.
Note: We first published this article back in February 2023, but we've given it a fresh update in September 2025 with the latest info and some clearer explanations. Enjoy!
Developer experience (DevEx, DX) is the overall experience of a developer when they are building software in a team. It describes how developers perceive, feel about, and value their work.
The three components of developer experience are:
In research these three components are known as cognition, affect, and conation. In this guide we’ll keep things practical and refer to them as infrastructure, feelings about work, and the value of work.
Improved developer experience boosts both the productivity and work engagement of the engineers in your organization. Streamlining your development processes and tools helps developers complete their tasks faster with less pain. People with high engagement are more likely to produce better quality software, collaborate better, and have lower turnover rates.
Reseach has shown that human factors are the most critical factors affecting software development productivity and quality. Developer experience gives you a lens to your engineering organization that allows you to improve both the human factor as well as the tools and methods you use — ultimately leading to better business performance.
If you’re just getting started, talk to your managers, team leads, and developers. What are the top 5-10 things causing a bad experience for your developers and breaking their flow? Select the most impactful problems to solve and set a measurable goal.
At this stage, companies commonly start improving things like compile times or number of flaky tests and measure things related only to their development infrastructure.
In the long run, you need to be able to address bigger problems like company culture or the way you structure your teams. To achieve this, you need to measure all three components of developer experience: infrastructure, feelings about work, and value of work. This requires multiple measures from multiple different angles. Specifically, you should track both engineering metrics as well as developer feedback.
For engineering metrics, common things to measure include wait times, DORA metrics, and your investment balance. Wait time metrics include compile times, test suite duration and flakiness, CI/CD build times, pull request cycle time, and issue cycle time. DORA metrics help you achieve and maintain continuous delivery. Tracking your investment allows you to balance feature work and developer experience improvements. (More on these metrics below.)
Developer feedback allows you to measure satisfaction and wellbeing. It also gives context to complex, nuanced problems like cross-team collaboration or changes in how teams work. Developer feedback is invaluable when ensuring that your engineering metrics reflect reality.
If your teams have a high level of psychological safety and trust, 1-1s and retrospectives are the best ways to get genuine and timely developer feedback. It should also be easy for developers to report issues when they face them.
You can — and should — run developer experience surveys, and you should also try to find ways of tracking real-time signals whenever you can.
Improving developer experience is a big topic, but this section includes six of the most impactful things you can do.
You will notice that none of the suggestions is linked to just a single component of developer experience. The components are intertwined, so changes in, for example infrastructure will affect how people feel about and value their work.
The number one driver of developer experience is flow. And the number one enemy of flow is unnecessary wait times and interruptions.
Flow state allows developers to focus on their work, get a sense of accomplishment, and enjoy tackling challenging problems. Unnecessary wait times and interruptions make developers frustrated and unproductive.
Common causes preventing developer flow are poor developer tooling, impractical team processes, and unproductive company culture. Examples include flaky tests, slow code reviews, and wasteful meetings. The larger your organization gets, the more things can break people’s flow.
To tackle wait times and interruptions in your development tooling, you analyze what happens when developers write code and run your CI/CD pipeline.
How long does it take to compile code, run tests, or deploy to production? The wins here are often small (seconds or minutes), but they have substantial compounding effects since they happen so frequently.
When analyzing the flow of developing features end-to-end, you need to understand your lead times, most commonly, issue and pull request cycle times. How long does it takes to ship a feature from start to finish and for code to get from the first commit to production (to your customers)? What interrupts developers when they try to complete their tasks?
Common issues include poor collaboration, working with too large pull requests and stories, and not agreeing on ways of working together.
Tackling wait times is an iterative process where you improve things step-by-step. You should:
Nothing demonstrates the importance of developer experience like a chaotic working environment full of breaking tools, bugs, and constant firefighting. A mistake many organizations make is trying run their engineering organization as a feature factory with 100% efficiency. As a result, they’re overwhelmed with managing complexity and struggle to keep the lights on.
Instead of creating chaos, you want to ensure developers have a healthy environment to build and maintain features. To achieve this, you need to track your investment balance. It lets you see where your time goes and continually invest in paying back technical debt.
The investment balance above uses a categorization originally developed at Dropbox that divides work into four categories based on its impact: “building new stuff,” “improving things,” “improving developer productivity,” and “keeping the lights on” (KTLO).
Categorizing your work into these buckets allows you to:
Continuous deployment practices have a proven relationship with better developer experience. The DevOps Research and Assessment (DORA) team’s studies have shown that teams that ship consistently are more motivated, ship higher-quality code, have less deployment pain and burnout, and have higher levels of job satisfaction.
To make deployments fast and safe:
Most developers have experienced it: Unclear goals and requirements. Unreasonable deadlines. Arguments over roadmap and priorities. High-priority task overriding everything else – no one knows why. Subpar product outcomes as problems are half-solved.
Product management is a common source of discontent among developers. A solution many organizations employ is adding more processes and formal roles. More people and layers between the customer and the developer. This is a dead-end.
The better option is to build empowered product teams that own the customer experience of a feature or parts of the product end-to-end. These teams have higher autonomy, grasp the impact of their work, and encounter fewer blockers. These are all things that contribute to great developer experience.
To create empowered teams:
You can have an office full of developers with the fastest possible development environments shipping very little code. Even if they are cranking a ton of code, they might not care about building the right thing. This is where work engagement comes into play.
Developers with high engagement are persistent, dedicated to work, and want to ship quality software. They are proactive and willing to support the rest of the organization. They are also the most likely people do great work even when your developer experience is still lacking.
High work engagement stems from the right balance of stimulation (cognitive load, challenges, and stress) and pleasure (feelings of success, learning, purpose, and connectedness). When people have the right amount of stimulation and enjoy their work, they become excited and engaged.
To drive great developer experience through work engagement, you should:
Developer experience surveys give you a systematic way to understand what’s working and what’s breaking flow across your organization. While engineering metrics show you what’s happening, surveys reveal why it’s happening and how engineers feel about it.
Think of surveys as your regular team health check. Just like you track deployment frequency or cycle time, you need to track developer sentiment over time and build a continuous feedback loop that drives concrete improvements.
Engineering surveys aren’t your typical employee engagement questionnaires. They need to capture the specific realities of software development work. Good engineering surveys focus on:
The hardest part about surveys for most organizations is knowing what to do with survey results. Luckily for you, my coworker Miikka wrote a whole article on how to run a developer survey retrospective. But in short, here’s how to make your survey program drive real change:
Remember: surveys are just one tool in your toolkit. They work best when combined with regular 1-1s, retrospectives, and easy ways for engineers to report issues when they encounter them.
Developer experience isn’t an island – it’s deeply connected to both developer productivity and business outcomes. These three pillars of engineering effectiveness support and reinforce each other in ways that might not be immediately obvious.
When developer experience improves, productivity naturally follows. Engineers who aren’t fighting their tools can ship faster. Teams with psychological safety collaborate better. Developers who understand their impact write better code.
Productivity gains create space for better experience. When teams ship consistently and predictably, they build trust with the business. This trust translates into more autonomy, less firefighting, and time to invest in improvements.
Both feed directly into business outcomes. Happy, productive engineers don’t just ship more features – they ship the right features. They stick around longer, reducing costly turnover. They become advocates for your company, helping you attract top talent.
Engineering effectiveness is never “done”. Technology changes, teams evolve, and new challenges emerge. Sure, when you’re performing well (as in, things are running smoothly, the business is growing, and people are happy) you’re probably not thinking about increasing your engineering effectiveness. But you can’t only start thinking about these things when things start to go downhill.
This means you need to have a combination of these things continuously:
The three pillars give you a framework for thinking about improvements holistically. When you’re considering a change, ask yourself: How will this impact developer experience? Will it help or hurt productivity? Does it align with our business outcomes?
Sometimes the answer means saying no to things that optimize just one pillar at the expense of others. That new monitoring tool might give you better observability (productivity), but if it adds another context switch for developers (experience), is it worth it?
Developer experience improvements need to become habits, not one-off projects. Start with one frustrating thing that affects many developers – maybe flaky tests or slow local setup. Fix it well, celebrate the win, and use that momentum to tackle the next issue. The compound effect of these little improvements will transform how your teams experience building software at your company.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
