Your developers are worth obsessing over

Many software companies like to talk about customer obsession, where the customer’s needs and desires are the center of attention. 

But what about developer obsession? 

How do companies make it easier for developers to deliver value to their customers? How can developers ultimately fulfill those needs and desires?

A recent trend to solve this issue is type of team focusing on developer experience

The name of this team can vary between, well, “developer experience”, or something like “developer acceleration” or “engineering enablement.” It’s a new concept, so the naming isn’t quite standardized yet. 

Naming aside, the common goal of this team is to address the bottlenecks and pain points that hinder development productivity in the company. The goal is to reduce friction with suboptimal tools or processes.

This work can look different from company to company. What works in one place may not work in another. 

This article will take a deeper dive into some common approaches and patterns to consider when starting your own developer experience team.

Forming a developer experience team

It’s tempting to just put together a developer experience team from your pool of existing developers. After all, they should know their problems best.

Depending on your organization, it might be an easy sell to gather developers from various teams for the lofty goals of developer experience. But some organizations might not be so willing to part with high-performing developers that are delivering direct value to customers.

Instead, it’s better to have a blend of both tenured developers and fresh experienced hires on this team. 

The tenured developers will have a great understanding of the day-to-day pain points of development. The new developers will come in with a fresh perspective. They can distill best practices from their previous experiences.

It’s also beneficial to have developers of different types and backgrounds. Not everyone needs to be an expert in your existing tech stack. 

For example, it’s completely reasonable to have some developers who are proficient in the stack paired with some site reliability engineers (SRE) or DevOps engineers. Together they can cover a large breadth of the work that comes with a developer experience team. 

Similar to having a mix of tenured and new developers, a blend of expertise offers the benefit of having many different perspectives for solving any challenge that might come up.

Knowing your developer customer

A developer experience team must know their customer: Namely, developers. Really, this is no different than any other feature team.

Before starting out any work, the team needs to communicate with the developers to understand where the problems are. 

Effective ways of gathering feedback could include using surveys or polls for the quantitative side. They’re great for initial discovery. You can use surveys to help identify some of the common bottleneck themes in your company.

Designing an effective survey is outside the scope of this article. Relying on a small number of clear and concise questions is the goal. We want to eliminate any sort of anchoring or bias in our questions to get earnest feedback from the developers.

From there, it can be prudent to follow up with developers who are passionate about some of the bottlenecks at the company. This usually looks like senior engineers or tech leads. It’s important to take time to chat with junior engineers as well. 

Seniors may be skilled enough to work around some of the challenges, and can overlook some of them. 

Juniors might struggle with these hidden problems. This can be a great source for targeting improvements, which can enable these developers to become more productive.

Finally, it could be worth spending some time embedding some developer experience engineers embed in a feature team. This would give them first-hand experience with delivering features. On the way, they’ll probably encounter some of the same bottlenecks we talked about before.

Discovering themes and bottlenecks

With that preliminary discovery, the team can probably start picking on some common themes that need some improvement. 

Across companies, there will likely be some common themes, such as developer environments, CI/CD systems, and observability. 

However, every developer experience team will likely have a different focus based upon their developer discovery work. Those themes should turn into areas of ownership for the developer experience team. 

It probably doesn’t make sense to take on ownership right away. It could be overwhelming for a new team to take on all that responsibility. Ownership is something the team can grow into as their team grows in maturity and headcount.

For example, let’s say CI/CD systems are a bottleneck for your developers, and they’re finding it challenging to release multiple times a day. Here it would be worthwhile for the developer experience team to establish some level of ownership and discover what needs to improve. 

Perhaps there are issues with existing functionality, such as build time. Or it could be missing features that are required to be more flexible, such as feature flags, canaries, or blue-green deployments.

These themes may sound similar to platform engineering, and indeed, there are a lot of parallels. 

While both teams are focused on the developer as their customer–and treating their work as a product–a developer experience team typically works more closely on the developer side of the spectrum. This is instead of abstracting away developer interactions with infrastructure.

Establishing a developer experience mission, with metrics

A key question that any developer experience team has to answer is: How are you improving the developer experience or productivity at the company?

First, it’s important to define what improving the developer experience looks like. This will get your team to start thinking about its mission and your metrics. 

For example, DORA metrics would be a great choice for a developer experience team, but there is a newer framework called SPACE to consider as well. This acronym measures the following:

• Satisfaction and well-being
• Performance
• Activity
• Communication 
• Efficiency

Using some combination of these two frameworks will allow your team to quantitatively gauge its productivity through DORA metrics. They can also consider the more qualitative measures present in SPACE.

The most challenging part of measuring these metrics will be tying back your work to how it improves these metrics. 

It’s likely that some of the work will be a lagging indicator. You might not see results right away. Be patient: Adoption of your new, improved tooling and processes will take time. 

Developer experience is an iterative process

Developer experience teams are forging a fairly new path. 

This practice has been established at quite a few larger companies. It’s now starting to make its way into growing startups that are looking to scale up their engineering department. 

There are not a lot of industry standards around how developer experience teams operate and perform. It’s a lot like when DevOps was first becoming a thing.

Developer experience teams really benefit from feedback loops. Software is built upon iteration, and developer experience is no exception. It will take investigation, experimentation, and being flexible to figure out what works.

Developer experience teams will have the main benefit of working so closely with their customers. This is the kind of quick feedback that feature teams would love to have.