What is Developer Experience (DevEx)?

The Developer Experience Series

This blog is part of a series of blogs on developer experience, you can view the index of the rest of the posts right here.

At OpsLevel, we’ve had the privilege of working with some of the world’s best performing engineering teams. This has not only shaped how we go about building our internal developer portal, it’s also given us a clear understanding of what makes a strong and effective engineering team. And what we’ve found is that one of the biggest, most impactful drivers in any team is a great Developer Experience (DevEx or DX). 

As we continue to contribute to positive DevEx with our technology, we’re eager to share some of what we’ve learned in our latest content initiative: The OpsLevel DevEx Series. 

Over the next few weeks, you’ll see a series of articles covering the value of a great DevEx, why it’s important, how it can be achieved, and best practices for measuring it. To get started, we’re defining what great DevEx looks like. 

In this article, you’ll learn about: 

• What great Developer Experience is (and isn't)
• Why it’s important to achieve and maintain flow state at work
• How a positive Developer Experience supports business goals

Introduction

Great developer experience (DevEx or DX) is what you get when developers can easily get in and maintain flow state at work. Flow state must be the goal of great DevEx for the following reasons:

• It makes developers happier, more creative and far more engaged in their work
• It increases the quality of software delivered by the developers

Addressing flow state issues has other positive side-effects too such as the improvement of the following areas:

• Communication
• Engineering practices
• Working environment
• Vision
• Planning
• Feedback loops
• Less context switching
• Less cognitive load

DevEx is important because the act of writing, releasing and operating software quickly is the ultimate goal of your organization, therefore anything that adds constraint in this area, hurts your company’s bottom line.

Before we go further, it's important to point out some misunderstandings. There are a lot of opinions out on the internet, but in general, Developer Experience is not:

• Equal to user experience, but the engineer's experience is a huge part of DevEx (just not the whole thing)
• Not about catering to lazy developers; It's about hiring the best talent and creating the best conditions for them to work efficiently
• Just leadership's responsibility—it’s a joint engineering effort

What makes a great developer experience (DevEx)? 

If you do a quick search online, most definitions of DevEx tend to center around how developers feel and whether they’re happy with the work they’re doing.

And while we theoretically agree with these definitions, using “happiness” and “feelings” as a basis for optimizing DevEx can be problematic because these are very subjective terms. This makes it difficult to set tangible goals and targets, which in turn makes it difficult to yield meaningful results against software delivery and organizational effectiveness.

To make it easier for teams to understand what needs optimizing, it’s far more helpful to define what great DevEx is:

Great developer experience (DevEx) is what you get when developers can easily achieve and maintain flow state at work.

What is flow state? 

Flow state is what’s often referred to as “being in the zone.” (This state is also known as “deep work,” as defined by Cal Newport’s bestseller). It is a mental state in which a person is fully immersed in an activity and experiences a feeling of energized focus, enjoyment, and timelessness. To achieve this state, the activity often needs to be challenging enough to be engaging, but not too easy that it gets boring. It also shouldn’t be so complicated that it causes anxiety. 

Consider the graph below, based on Csikszentmihalyi’s flow model, for a visualization of where flow state resides:

‍

‍

Achieving flow state is a core element in the creative process. It is present across all of the greatest inventions, works of art and scientific discoveries in history. For example, Albert Einstein, Isaac Newton, Nikola Tesla, Michelangelo (not the turtle, the Italian artist) all described intense feelings of energy and elation when working on their masterpieces, to the point that some of them even forgot to eat and sleep. As creative individuals, developers should be able to tap into these same experiences.

However, too often, companies and their leadership seem to go out of their way to prevent their engineers from entering flow state. Let’s look at it this way. If we consider Dr Schaffer’s 7 Flow Conditions (listed below), it’s easy to articulate how poorly executed leadership and processes can get in the way of these important elements:

1. Knowing what to do → Leadership lacks vision and doesn’t provide adequate context, or adequate planning.
2. Knowing how to do it → Engineers have difficulty finding the right tooling, team, or documentation to do their job. Developers are often given tasks out of the scope of their role, such as infrastructure tasks, without meaningful abstractions or good tools, leading to needless cognitive load.
3. Knowing how well one is doing → Insufficient feedback loops and observability to gauge impact and get feedback tend to leave developers in the dark about their performance.
4. Knowing where to go → lack of a developer portal, platform, or hub to help orientate developers within the company. Plus, any existing documentation is often disorganized and it is difficult to find relevant information. 
5. High perceived challenges → Developers have to sort through tedious, menial work that’s not challenging or creative. The goals are either too lofty or not engaging enough - or non-existent.
6. High perceived skills → Engineers lacking the ability to foster learning or tackle meaningful challenges that build a skillset relevant to their career goals. Using tooling that’s not relevant to their job or career or drowned in tedious processes that are pointless.
7. Freedom from distractions → Developer time is taken up by too many pointless meetings peppered throughout the day, Slack distractions, noisy offices, too much context switching etc.

These are just a few examples of the many areas where flow can be negatively impacted. Over the course of this series, we will explore many more. For now, we just need to understand that it is the responsibility of a company to create the most ideal conditions for developers to enter flow state, and that includes removing all unnecessary distractions, cognitive load, convoluted processes, and bad tooling.

Why choose flow state as the core goal of a great DevEx? 

There are a few crucial reasons why we opted to focus our efforts on flow state as a strategy for DevEx. We address a couple of them below.

Flow state makes developers happy at work

‍

Developers have described achieving flow state as the purest form of bliss while at work, and as one of the pillars of a meaningful, happy life. It’s why developers tend to seek out this approach to work in their roles.

A company may not be able to make an engineer happy in all areas of their life, but it can at least create the best possible conditions for flow to occur in their most productive hours, significantly increasing engagement and well-being.

Why is a positive developer experience so important?

The processes, environments, tools, and documentation that inform how your developers write software and the overall DevEx have a direct impact on a company’s ability to deliver high-quality software. In other words, if your engineers aren’t equipped to deliver great code, the quality of the product—and the company’s ability to build trust with customers—will suffer. As such, taking the time to optimize DevEx so that writing, delivering, and operating software is seamless becomes a core driving force in delivering a product that the rest of your company, your stakeholders, and your customers can get behind. 

Why focus on flow state instead of productivity?

‍

Much of the literature found online around DevEx revolves around productivity as a goal.

While this may make it more palatable to executive leadership and engineering managers under pressure to deliver more output, it’s the wrong approach.

The issue with using productivity as a metric in software development is that it creates the wrong incentives for developers. For example, you can set aggressive OKRs based on DORA metrics, but if developers have strong incentives to reach an arbitrary number of deployments, they are likely to look for shortcuts to get there, regardless of the quality of the software delivered. To put this into an analogy, you can’t make a team of writers to give you the next Harry Potter series by forcing them to write 1,084,170 words, just like you can’t get developers to turn your company into a unicorn by doing 1,000 deployments per quarter.

That’s not to say that DORA metrics are not helpful performance indicators, but it’s important that leaders don’t create the wrong incentives for your developers. Otherwise, you risk getting the wrong results.

Productivity metrics may change from quarter to quarter. Forcing targets and/or incentivizing them top-down will hurt quality of outcomes by creating the wrong outcomes. These metrics are better left for teams to decide and tweak accordingly based on their experience and expertise. 

‍

‍

Measuring what hurts engineers from entering and maintaining flow state is the art of measuring what’s NOT productive. Leadership will do more harm than good by arbitrarily defining what productivity is and forcing it on teams. Leadership instead must aim to implement a culture of measuring everything that hurts flow state and make it a joint responsibility to improve that—that's how you improve the quality of outcomes and yes, indirectly, become productive.

What DevEx is not

Now that we’ve defined what a great DevEx can look like, let’s take a moment to  dispel common misconceptions around DevEx.

What about metrics? We need metrics!

This post is the beginning of a series that will cover multiple areas that affect flow state in detail. We felt that covering it all in one post wouldn’t allow us to invest enough time in each topic. As we continue this series, you’ll find that each article will provide example metrics to help optimize flow in your company.

Note, the metrics we use will always be examples, and we will aim to be as comprehensive as possible based on our experience and what we’ve learned from our customers. Before you implement any metrics, we recommend taking the time to fully understand the context of what you’re trying to improve and how it applies to your company. That way you’ll be better able to define what needs measuring.

Conclusion

The concept of optimizing for flow to achieve a great DevEx is not new. In fact, all the current unicorns are doing this or have done it at some point in the past. Companies that don’t respect engineers' time and introduce processes, tooling and culture that makes flow state difficult will generally deliver software at a much slower pace and lower the quality of output produced. Removing those barriers and enhancing how developers are able to write, ship, and maintain code can only lead to higher quality products. 

About the Author

Fernando Villalba is our Developer Relations at OpsLevel, he has over a decade of miscellaneous IT experience. He started in IT support ("Have you tried turning it on and off?"), veered to become a SysAdmin ("Don't you dare turn it off") and later segued into DevOps type of roles ("Destroy and replace!"). He has been a consultant for various multi-billion dollar organizations helping them achieve their highest potential with their DevOps processes. Now he is passionate about platform engineering, developer portals and DevEx, which he feels is where the future of software delivery shines brightest.

Follow Fernando Villalba in LinkedIn or Twitter

‍

‍

‍

‍