For years, we’ve been hearing a lot about developer work and how to improve it. Something along the lines of “how can we help our developers achieve more, quicker?” This focus on developer productivity makes sense because today, software is the backbone of nearly every major company, and when developers achieve more, companies thrive. But, as the expectations placed on developers grow, so do negative consequences like burnout, mistakes, and decreased retention. At the Developer Experience Lab, a joint Microsoft and GitHub research initiative, we saw this play out globally during the pandemic which led us to a revelation: the best way to help developers achieve more is not by expecting more, but by improving their experience.

This was a shift in the paradigm: the prominent conversation is no longer about outcomes like developer productivity or developer velocity, it’s now about how to achieve these outcomes in sustainable ways using developer experience (DevEx). DevEx is about helping developers not only write code, but write code in an environment that is optimized for writing code.

DevEx is not just about individual developer satisfaction; it directly influences the quality, reliability, maintainability, and security of software systems. A well-optimized environment for writing code facilitates getting into the flow, fosters connections and collaborations, and provides high-quality feedback, contributing to broader team performance and organizational missions.

Other organizations are recognizing the importance of DevEx, too. As Thomas Newton, VP of Developer Experience at UKG puts it, “Developer experience is an investment aimed at improving engineering effectiveness. It’s a virtuous cycle: by reducing friction and waste from developers’ daily work, they’re able to ship high quality software faster, while also improving happiness and engagement.”

We’ve been talking about DevEx for a few months now (see my last blog post about navigating the SPACE between productivity and developer happiness and the accompanying research paper on helping hybrid development teams thrive), but one key thing has always been missing—hard data to actually quantify the impact of an improved DevEx.

Today, I’m excited to announce that we finally have some data to bolster the discussion.

Improving and measuring developer experience

Our recent study,“DevEx in Action: A Study of Its Tangible Impacts” seeks to quantify the impact of improved DevEx at three levels: individual, team, and organization. For individual developers, positive outcomes included improved job performance, creativity, and learning. For teams, we found improved code quality and technical debt, which reflects the system in which a team works. At the organization level, positive outcomes included improved retention, innovation, profitability, and the organization’s ability to achieve its goals.

We partnered with DX for this research because their experience with improving DevEx and their developer experience platform gave them unique insight and expertise to inform the study. Our data comes from more than 2000 developers at various companies around the world. Here’s what we found.

Positive impact at three levels

At a high-level, our results are promising. Our research model investigated how flow state, feedback loops, and cognitive load impacted developer, team, and organizational outcomes. There’s strong support for the positive impact of flow state and low cognitive load on individual, team, and organization outcomes. We also found that feedback loops—which in our study focused on the speed of answering questions and completing code reviews—have positive impacts at the team level. We talk about these findings in more depth in the paper.

You may be thinking to yourself, “Okay cool, but what do I do with this?” I’m so glad you asked. We also used an analysis method called Importance-Performance Map Analysis (IPMA) to identify items with outsized impact—or to put it another way: which action items could give teams the most bang for their improvement buck. We found that individual outcomes benefit most from deep work and engaging work, while organizational outcomes benefit most from deep work, engaging work, intuitive processes, and intuitive developer tools. We go on to outline what strategies teams and organizations can use to improve these areas, as well as concrete steps they can take to start measuring and improving their own DevEx. As CJ Dotson, Senior PM of Developer Productivity at Adobe notes, doing so is a worthwhile investment: “When Technology is what you sell, investments in Developer Experience are not optional. Adobe’s investment in Developer Experience leads to higher developer satisfaction and better business outcomes.”

For more detailed findings from our study, be sure to check out the paper here. We’ve included a few teasers below:

Flow state:

Developers who had a significant amount of time carved out for deep work felt 50% more productive, compared to those without dedicated time. Our data shows that dedicating time to deep work is a practice that pays high dividends in terms of productivity. Encouraging developers and teams to carve out time to focus is important, but their environment needs to support this practice by minimizing interruptions.

Developers who find their work engaging feel they are 30% more productive, compared to those who found their work boring. It can help to think carefully about how tasks are distributed between individuals or teams. Are the same developers stuck with boring projects? This could lead to burnout.

Cognitive load:

Developers who report a high degree of understanding with the code they work with feel 42% more productive than those who report low to no understanding. It’s common for fast-moving teams to overlook making their code clear, simple, or well documented, but this can hinder long-term productivity, so tooling and conventions that help make code understandable are invaluable. As my co-author Eirini Kalliamvakou notes, “Certain technologies like GitHub Copilot can help developers better understand their code and future-proof their productivity.”

Developers who find their tools and work processes intuitive and easy to use feel they are 50% more innovative, compared to those with opaque or hard-to-understand processes. Unintuitive tools and processes can be both a time sink and a source of frustration, severely hindering creativity.

Feedback loops:

Developers who report fast code review turnaround times feel 20% more innovative compared to developers who report slow turnaround times. Code reviews that are completed quickly allow developers to move on to their next idea quickly, laying the groundwork for innovation.

Teams that provide fast responses to developers’ questions report 50% less tech debt than teams where responses are slow. It helps to document FAQs from developers and put tooling in place so that developers can easily and quickly find the answers they need. This, and implementing good coding practices, creates less tech debt.

The future of DevEx

Our findings are clear—improving and measuring developer experience is worth the effort. It will lead to happier and more productive developers, stronger teams, and more successful organizations.

We hope that this new research will prove valuable for people looking for actionable insights to improve their DevEx, as well as those advocating for DevEx investments within their organizations. In our paper, we provide a roadmap for pursuing such investments. By collecting DevEx data, setting and communicating clear goals, sharing progress, and repeating this process, organizations can make informed decisions to continually enhance their developer experience.

Read the full research paper here: DevEx in Action: A Study of Its Tangible Impacts.