Good DevEx can raise the bar for your entire engineering organization, but what makes a good developer experience, and why is it still so hard to come by?
Developer experience (DevEx) is a developer-centric approach to measuring organizational success. Instead of just focusing on raw output metrics like Git commits and the velocity at which new features are implemented, DevEx is concerned with “how software developers feel about, think about, and value their work,” according to the authors of a 2023 ACM Queue paper on the topic.
Productivity is obviously a part of that, but it also encompasses a range of different behavioral factors, from the amount of interruptions and unrealistic deadlines developers regularly experience, to how clearly tasks are defined and how well organized the codebase is.
DevEx is proving an increasingly popular concept, but let’s step back and look at what exactly it is, why it matters, and how to start implementing it with your team.
What is DevEx?
That ACM Queue paper identifies three core areas where developers typically meet friction: feedback loops, cognitive load, and flow state. This builds on previous research from the same team that identified 25 key factors that affect developers’ experience in an organization.
Feedback loops
Most developers spend a good portion of their day waiting for things, whether it’s for code to compile, the results of a specific test, or for a response from another person. The shorter the time developers have to wait, the faster the feedback loop between the actions they perform and the results of the action, creating less friction. On the other hand, if developers are stuck sitting around waiting for a code review from another department before they can progress, the more annoyed they are likely to become.
Cognitive load
Software development is a complex task, but it shouldn’t be needlessly complex. It’s one thing for a developer to experience a high cognitive load while solving a challenging and important problem, but it’s another for them to be banging their head against their desk because the codebase is poorly documented, or they keep being asked to implement new frameworks mid-project.
Flow state
Most developers need some amount of uninterrupted, heads-down work to reach a flow state and perform well. Tapping away for a few minutes at a problem between meetings is seldom as effective as having a block of two or three hours to get into it, and it certainly isn’t as satisfying. If teams and organizations can create the optimal conditions for developers to regularly experience flow, they are likely to have a happier and more effective dev team.
When you consider these three dimensions together, you can start to build a solid picture of what friction developers at your company are experiencing, and how it’s impacting their ability to work.
Why DevEx matters
While DevEx might sound hard to quantify, research has consistently shown a strong link between having a happy dev team and company success. For example, a 2020 study by McKinsey found that companies that had better developer work environments showed revenue growth rates four or even five times higher than their competitors. Google’s annual DORA reports have also consistently shown that companies with better software delivery practices have better operational performance and tend to be more profitable.
As a result, optimizing for developer experience can also optimize for developer performance. For example, speeding up feedback loops means developers spend less time waiting and more time working. Keeping a well-documented codebase allows new hires to get up to speed quickly and existing developers to work efficiently. Giving developers enough control of their calendars so they can work for significant blocks of time and get into a flow state means new features can actually get implemented.
Of course, DevEx isn’t the only thing you should measure. Traditional key performance indicators, like release frequency, uptime, and user growth, are all still relevant, but most modern software organizations recognize the need to measure both in tandem to get a useful picture of their team health.
How to implement a DevEx initiative
There are many different ways to successfully approach DevEx, though all start with understanding what problems your developers are encountering and what needs to change.
Abi Noda, CEO of the developer experience platform DX, says the only way to truly understand what your developers are experiencing is to ask them. Developer experience surveys, whether quarterly or annual, are important, but they should be complemented with regular 1:1s, retrospectives, and simply looking at key operational metrics, like build time, that could alert you to potential issues.
While large organizations often have a dedicated DevEx team, you don’t strictly need one. In a podcast interview with Noda, Jean-Michel Lemieux, former CTO of Shopify and VP of Engineering at Atlassian, argues that having a platform team that is responsible for the developer tools and experience across the whole organization can actually be an “anti-pattern”. As Noda explains it, “The work of improving developer productivity and improving things that suck for developers can be owned by the regular product engineering teams, just as well as it could be owned by a dedicated developer productivity team.”
But what a DevEx initiative does take is time and resources. The biggest problem Noda encounters is companies where the executives claim to care about developer productivity and experience, but the developers feel beholden to the product roadmap and don’t have the time or resources to dedicate to improving things. “There’s a disconnect between executive leadership thinking product teams should just be fixing this stuff, when the reality for product teams is that they’re under four layers of engineering and product management.”
When Etsy implemented an 18-month developer experience initiative, the company reportedly dedicated 20% of its engineering capacity towards it. Similarly, Atlassian directs its developers to “use 10% of their time improving the things that make their day job suck.”
And initiatives like these can have operational payback. Etsy used its initiative to stay focused and productive while its engineering headcount grew from 250 to 1,000, while at Atlassian, the Trello team was able to delete 24,000 lines of defunct code. Another team was able to eliminate manual approvals for low-risk updates and increase its deployment frequency by 300%.
How to track a DevEx initiative
A DevEx initiative can take months or years to implement, so you need to track how your developers’ day-to-day experience and satisfaction changes and how this impacts your key performance indicators. Ideally, your developers are going to experience less friction and, as a result, these KPIs will improve.
Start by establishing a baseline to compare progress against. The ACM Queue paper suggests starting by measuring your developers’ day-to-day experience with a survey, even if you haven’t yet decided to formally establish a DevEx initiative. This can “help growing organizations spot and understand trends, decide the right time to begin making investments, and navigate macro shifts such as remote work and AI-powered programming.”
With an initial survey conducted, you should have a clearer idea of what friction developers’ are experiencing. Smaller organizations and startups are more likely to be able to quickly implement changes to address the issues raised, for example, if a specific tool or workflow is holding the team back.
For larger organizations, any specific DevEx initiative will need to be balanced against the resources necessary to implement it. Start small and build a business case by focusing on the outcomes, rather than specific developer gripes.
At some point, a decision will also need to be made as to how much central control you want over your DevEx initiative. Will one VP have ownership over DevEx for your entire organization? Or will each team be responsible for fixing the problems they feel? Or something in between? According to Noda, many different companies have successfully implemented both centralized and decentralized initiatives, it really depends on the specifics of your organization. Though, generally, it is easier for the people who most acutely feel the friction to fix the problem, rather than in response to top-down dictums.
Regardless, throughout the whole process the lived experiences of your developers needs to be respected. While formal surveys may only be conducted quarterly or annually, retrospectives, 1:1s, and other meetings all provide an opportunity for developers to offer feedback on where their experience is lacking.
Final thoughts
Ultimately, DevEx isn’t about making any specific set of changes or implementing one set of principles across every organization. Instead, it’s about listening to your developers and understanding what can be done to reduce the friction that they experience while working.
Instead of trying to increase performance by focusing on the output metrics, a DevEx initiative should focus on the people handling the inputs – your developers – and do what’s necessary to maximize their effectiveness, trusting that it will lead to better organizational outcomes.
