| | 9 APRIL 2022transitioned into DevOps teams over the last years. They took over more and more responsibilities and integrated new knowledge into their team. This causes a lot of context switching 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 principlesOne 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.3. Adoption is not forcedNo 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 you interesting insights about how teams think about their own code. And it also gives you some indication how understandable it is written which is an important aspect 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. A key driver to improve Developer Experience is to reduce the cognitive load of the developer teamsChristian Rudolph
< Page 8 | Page 10 >