Why a developer experience team can help your company

Great developer experience is directly linked to great developer productivity and an important factor for company success. Therefore, as explained in my last articles, companies should care and attempt to improve developer experience.

The question then, of course, is how this can be done. A dedicated team focussing solely on developer experience can be a good investment. At first, companies may hesitate to have a team that does not work on features for customers but completely focusses on developers and their needs.

However, even in companies with only twenty-ish developers, such an investment can already pay off. Here is, how a developer experience team can help you:

Focus

… fosters excellence

Topics like CI pipelines or build tooling often are more or less orthogonal to the product oriented topics teams are working on. This means, unless something is not absolutely annoying or blocking the product development, it will not be addressed.

Furthermore, product development teams typically focus on their context and their part of the product. Thus, it can happen, that five different teams have a mediocre experience with a tool, but none of them considers it important enough to delay features to work on the tooling-issue as they might lack the broader view on that issue.

A developer experience team can have a more holistic view as it targets developers as customers and focusses on their experience instead of product development. Therefore, such a team can focus on issues that appear small in the context of a single team but might have a bigger impact if viewed company-wide.

Moreover, developer experience teams do not need to balance product feature development with toolchain-improvements, as the toolchain is their product. Thus, the team has the capacity to build expert knowledge in those areas and come up with better solutions than a team could that is just spending some hours here and there.

… allows for clear priorities

A developer experience team usually focusses on a very specific group of customers, the developers. Therefore, it is much easier to identify their pain points and derive a roadmap and priorities from this knowledge.

This would be much more difficult if a team wants to cater for two very different user groups with no overlap, such as internal developers and external customers.

… not only for the developer experience team

While the focus on developer experience allows a team to limit their scope and have a clear goal, this is not only beneficial for this team alone.

Other teams will profit, too, as they now have an internal support team at hand that can help them to understand and solve their problems related to developer experience topics. When, let’s say, a CI pipeline fails for mysterious reasons, teams with little to no knowledge about this matter might spend hours or even days to understand the problem. With a team dedicated to developer experience, it is much more likely that the other teams will pull in this team. The developer experience team might be able to solve or at least identify the issue within minutes, as it lays within their area of expertise.

This can be a huge relief for product teams.

Ownership

Topics that affect many teams often fall through the cracks between teams. Either, they are then tackled by cross-team communities or task forces, when things get serious, but there is rarely some team that feels really responsible for things like CI pipelines for shared artefacts.

If everybody is responsible, nobody is.

While in theory everybody should care for the entire system, including the product, the people, and processes, this rarely works well at scale. At some point, systems get too big and complex for every person or team to oversee. Thus, it can become difficult to make changes in an area of the system, where expertise is lacking.

With a clear owner for that area identified, it becomes much easier for others to propose changes in this area, as they can ask some team that has more context and expertise in this area. Or, if this is not possible, that team can take over the task of doing improvements in this area. This is true for different areas of the product and also for developer experience. However, ownership should never be an excuse for not doing improvements that one knows how to do.

Commitment

Developer experience is like product development. It is never finished. Unguided improvement efforts here and there are better than nothing. But what really will move the needle is an incremental approach of driving the developer experience to where it should be. This requires a broad overview, a sketch of a roadmap and a long-term vision — and of course time, to work in that direction.1

A dedicated developer experience has the time to build this holistic view, roadmap, and vision and implement the incremental changes. This will often mean to identify the bottleneck with the biggest negative impact on overall developer experience and coming up with ways to remove it. The team can then repeat this approach with the next bottleneck.

While this could, in theory, be done, also without a dedicated team, focus, and commitment will help to put significant effort in those improvements and is therefore likely to yield significant results.

Summary

Having (a) dedicated team(s) for developer experience is not only a sign that your company cares about developer experience, it also makes it more likely that the developer experience in your company will improve over time.

As with every problem, putting a motivated and skilled team with time and resources on a problem, is likely to solve it.

Having a developer experience team that has the focus and ownership of developer experience topics and is committed to improve the overall experience is likely to accelerate improvements in the realm of developer experience and productivity.

What is your company doing to ensure a great developer experience? Share your thoughts here in the comments or via LinkedIn or Twitter.

1. It is important to mention, that roadmap and vision are not set in stone and blindly followed. They give a guidance, but incremental delivery and learning from feedback is as essential for developer experience teams than for every other development team.