TUI

Most companies care about Customer Experience (CX) for their end consumers and make every effort to improve it. But what about the Developer Experience (DX)? In IT, we often claim that we have the customer in mind when we offer self-service or online services to them. But surprisingly we very often forget that the people who build these services are also customers to other services and teams. I see that a lot of companies expect to solve this with the move to the cloud and the use of portals and services from cloud providers. Unfortunately, the number of growing services and the speed of innovation of cloud providers can lead to a complete information overload and distract developers. Furthermore, not everything that is used is 100 percent seamlessly integrated from Day 1. This is one of the reasons why we see a rise of enabling or platform teams in many organizations, especially when they transition into self-organized autonomous teams where teams have now more responsibilities. The platform teams are often responsible to provide a great Developer Experience inside the company and to create the foundation others can build on. This becomes especially important when you grow your engineering teams.

How does good Developer Experience look like?

This will differ from company to company but for me there are few important things to consider:

 • Reduction of cognitive load for the teams.

 • Self-service and autonomy remain key principles

 • Adoption is not forced

​1.Reduction of cognitive load for the teams

A key driver to improve Developer Experience is to reduce the cognitive load of the developer teams. Many teams have transitioned into DevOps teams overthe last years. They took over more and more responsibilities and integrated new knowledge into their team. This causes a lot of contextswitching due to different tools and processes for the teams. This is often visible when teams have to do unplanned work (e.g .during incident troubleshooting, introduction of new standards and processes). A good Developer Experience would reduce this “noise” for the teams.

2. Self-service and autonomy remain key principles

One often misunderstood part of Developer Experience is that it is not equal with giving away responsibility or ownership to another group. Instead, the goal of a good DX is to have all services which a team needs available via self-service and ideally as an API. This gives teams the opportunity to still have autonomy around their service/product. In an ideal world you would make sure that a team needs as few interactions as possible outside their main responsibility.

"The platform teams are often responsible to provide a great Developer Experience inside the company and to create the foundation others can build on."

3. Adoption is not forced

No matter how you decide to improve your DX – the worst thing you can do is to enforce the usage of it. If your choice is not good enough and removes enough cognitive load for them then you should rethink your approach. For this of course it is important to measure the adoption and usage of your idea.

When it comes to measuring, I would like to recommend two approaches. I call them the “soft” and the “hard” approach:

The “soft” approach comes back to my initial question about Customer Experience vs. Developer Experience. If you see developers as customers, you might want to measure a Net Promoter Score (NPS) of the platform, tools & processes. You want to find out if your developers find them easy to use and helpful for them. This will also help you to understand how happy your developers are with the tools and processes your company provides. The easiest way to collect this data is a survey. The “hard” approach is to measure real adoption. If it is a tool you can collect metrics for usage, duration, mostvisited areas. If it is a process, you can measure how many teams are using it and what the benefit is for them (e.g. lower Time-to-Market, lower Change Failure Rate, less defects).

Another “out of the box” approach could be to ask teams of developers if they would refer the code to a (developer) friend. This goes well beyond the enabling part but it will give youinteresting insightsabout how teams think about their own code. And it also gives you some indication how understandable it is written which is an importantaspect of a Developer Experience.

In a nutshell, we should not underestimate the impact that a great Developer Experience can make for your company. And you be willing to invest in it – just like your company is willing to invest into the Customer Experience of your products.