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.

Flow state increases the quality of output and creativity

When developers are fully immersed in problems they enjoy working on, the quality, creativity, and speed of their output is significantly higher. This is better than establishing arbitrary productivity metrics that create the wrong incentives. For example, rewarding developers for the number of deploys they do will not provide better quality software.

Optimizing for flow can also lead to a number of other benefits that contribute to making the team more effective, including: 

• Improved communication
• Clearer vision and purpose as a result of better leadership
• Less time wasted on menial tasks
• Better hiring and onboarding practices
• Becoming more attractive to potential hires
• Fewer redundant processes
• Better tooling
• Better-quality outcomes (which in turn can translate to happier customers and more money)
• Psychological safety
• Better working environments
• More streamlined engineering practices

As a result, teams can do more to deliver against their organizational goals. 

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.

Developer Experience (DevEx) is not equal to User eXperience (UX), but user experience is a huge part of the DevEx

A lot of the content that’s been published about DevEx has equated the term DevEx with user experience (for developers). This isn't the case, however. The user experience is just one piece of the puzzle when it comes to DevEx.

Meanwhile, user experience is often conflated with the user interface (UI), but it actually encompasses the entire user journey. Your CLI, API, and even libraries can have terrible user experience too, it’s not just the UI. 

Remember, developers are users too—they are internal users of other teams and tools. As such, a platform engineer implementing a developer portal needs to treat the developers as their users, and learning about user experience as a discipline will help them design tools that are easy to use and intuitive.

The UX of the tooling you pick or create will play a crucial part in your DevEx. We cover this topic in detail later in the series. 

Improving DevEx is not about catering to pampered, lazy developers, or implementing AI super tools to save money on staff

Like with any seemingly disruptive concept, there are some vocal critics of DevEx that interpret it as a fad. They suggest that DevEx initiatives just exist to make developers lazy or coddle them so they don’t leave. Other critics have insinuated that DevEx is just an excuse to implement AI so companies can hire cheaper developers. But none of this is true. 

A DevEx strategy should be based on hiring the best possible people to do the job. Individuals that are eager to learn, self-driven, and an adequate cultural fit. However, it doesn’t make sense to hire the best people if you then hinder their contributions by not allowing them to get into the flow of work. That’s just a recipe for wasting your engineering resources and increasing developer churn.

As we mentioned, tooling is also very important when it comes to your DevEx strategy, but that doesn’t mean it can replace high quality contributors. AI tools are just there to make things easier. For example LLMs may be great as dynamic template generators like generating YAML with certain parameters or writing pieces of code that would be otherwise tedious (for example, create some unit tests for this function, or give me a function to do x). They are great assistants, but they are decades away from replacing a human being. They still get things wrong a lot of the time and it requires a human to understand and optimize the outputs, and put them into a bigger context.

DevEx is also not about pampering engineers. You could buy a Ferrari for each person on your team, and they certainly would report great feelings of happiness (at least for a while), but that doesn’t necessarily mean you would be improving the quality of your software output.

What critics don’t seem to understand is that the companies that led the charge in DevEx—even before it was referred to as such—like Google, weren’t doing these things just to be kind and generous. They were doing them to keep engineers in the flow and increase the quality of their outputs. (An engineer that doesn’t have to worry about washing their clothes, or making lunch may be able to stay far more focused on their job than one who does.)

When you look at DevEx in the context of achieving a flow state, you will be able to discern the difference between a frivolous optimization and changes that will ultimately increase the creative juices and quality of software company-wide.

Great DevEx is not just the job of leadership, it’s a joint engineering effort

There’s no question that leadership must support and encourage DevEx in all key areas in order to improve flow state, but it isn’t just their responsibility. It requires input and commitment across the engineering organization. 

For example, it doesn’t matter how much the CEO or CTO preaches about great DevEx if all the work produced by engineering teams is difficult to understand and use. It is important that your entire company learns to see other colleagues and teams as their customers/users and deliver work that makes their job easy.

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

‍

‍

‍

‍