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.
What is developer experience (DevEx, DX)?
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:
- How developers perceive the development infrastructure. This includes both the technical infrastructure (e.g., development tools, issue trackers, programming languages, cloud platforms, libraries) and ways of working (e.g., working agreements, processes, and methods).
- How developers feel about their work. Do they feel respected? Do they care about their work? Do they feel like they belong in their team?
- How developers value their work. Do they feel they’re making an impact? Are their values and goals aligned with those of the company?
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.
Why is developer experience important?
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.
How to measure developer experience?
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 — also run developer experience surveys, but if you run them too often with too many questions, people won't reply. So they’re practically always a lagging indicator, and you should try to find ways of tracking more real-time signals whenever you can.
How to drive great developer experience
Improving developer experience is a big topic, but this section includes five 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.
1. Reduce developer wait times and interruptions
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:
- Build observability into your development process. This allows you to understand the full impact of the changes you make. You don’t want to optimize a small part of developer experience at the expense of the whole.
- Tackle issues one by one, starting with the simpler ones. This forces you to prioritize and makes it easier to evaluate impact.
- Give developers easy access to tools. This is one of the simplest and cheapest ways to improve flow. Seemingly trivial things like timely notifications can remove a whole category of unnecessary wait times.
2. Invest in maintaining a healthy codebase
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:
- Continually pay back tech debt. 10% is a great goal for many teams, but sometimes making more significant investments in issues with major impact makes sense.
- Understand what causes firefighting. High levels of KTLO contribute to developer burnout and attrition. Understanding what causes KTLO helps you prioritize tech debt improvements.
- Improve developer motivation. Developers feel heard when they know that “improving developer productivity” is a company goal.
- Communicate impact. Developers want to build great things. Ensure they know how the things they build contribute to the product's success.
3. Make deployments safe and fast
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:
- Work in small batches. Instead of using long-lived feature branches, continuously integrate work to the main branch.
- Invest in automated tests. If developers are afraid to deploy on a Friday, you probably need to increase your test coverage or quality.
- Automate repetitive tasks. Enforce code style with linters and use code analysis tools. Code reviews should have very few (if any) “nitpicking” comments.
- Automate your deployment process. With web applications, deploy every pull request when you merge. Otherwise, make sure you can create a new release with a few clicks.
4. Empower teams
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:
- Build cross-functional teams. Teams should be able to tackle customer problems and features end-to-end – with minimal or no help from other teams.
- Let teams own the problem and the solution. When teams have full control over the end result, it creates shared accountability – a collective responsibility over the success or failure of the whole solution, not just parts of it.
- Run blameless retrospectives. When something goes wrong, don’t ask “who” but “why.” This builds psychological safety among the team and promotes collaboration over competition.
5. Optimize for high work engagement
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:
- Invest in engineering leadership. Managers account for the majority of variance in team engagement. Make sure your leaders know how to support great developer experience.
- Support personal growth. The right level of stimulus and sources of pleasure are very personal. Help people identify what motivates them and what they enjoy at work.
- Enable career progression and continuous learning. Support job crafting and ensure developers know how to progress in their career.
- Build connectedness. Invest in empowered teams where people create impact together.
Wrapping it all up
Understanding developer experience is vital when you want to improve the lives of the developers in your teams. Having a systematic approach to improving developer experience will help you improve both the work engagement and productivity of your developers and, as a result, improve the business performance of your organization.
