Defining the scope for a developer experience team

Ask nearly any developer experience team leader what their charter is, and you’ll hear something like, ‘we make software engineering easier at our company.’ Here are some real-life examples of DevEx team charters at familiar companies:

• Slack: Making the development experience seamless for all engineers
• Stripe: Make software engineering easier at Stripe
• Google: Making it fast and easy for developers to deliver great products
• Shopify: Make Shopify developers more productive
• Snyk: Make Snyk a pleasure to develop within
• Doma: Make it fast and easy to build great products
• Twitter: Create a seamless and holistic experience for engineers at Twitter
• Financial Times: Make things as easy as possible for product developers, whether that be by providing tools, clarity, support, or standardization

While these statements are helpful and inspiring, they’re also quite broad. “Making developers more productive”, for example, can be interpreted in different ways. It helps to narrow a team’s charter by establishing the team’s “opportunities for impact”, or problems that a specific team is dedicated to focusing on. Here’s how:

Start by looking at what the team has already been working on. The team might have already worked on a broad range of projects, and it helps start by coming together as a team to look at those and surface common themes. What was solved and what was the reasoning for solving those problems? This exercise will likely surface at least a few categories of problems the team focuses on that can then be refined. It’s important to do this exercise as a team, even if you have some ideas on how the charter will end up.

Narrow the categories. There are three common buckets we’ve seen teams land on, that they can then set as their areas of opportunity: reducing cognitive load, accelerating feedback loops, and supporting flow. (In some cases, “scaling up engineering” is also an area of opportunity.) All projects the team takes moving forward should fall into one of the three buckets.

Set guiding principles. Guiding principles (sometimes called values) are a way of articulating a way the team should work. They should help people make decisions and be easy to remember. For example, Shopify’s Infrastructure team’s guiding principles include “we hold ourselves accountable for measuring success,” and “we have two-way communication with our customers.” Both of these set an expectation for the members of that team.

How Developer Experience teams emerge and mature

Here’s how DevEx teams tend to emerge: first, a volunteer sees and signs up for solving a problem, then, a committee is formed, and finally, a dedicated team is formed. Below you’ll find that process described in more detail, but an important note first: many developer experience issues exist at the local team level and must be solved by those individual teams. Setting up a successful developer experience program, where individual teams drive their own improvements, requires executive sponsorship and may run in parallel to the work centralized DevEx teams do.

Here’s the typical path for going from zero to one as a DevEx team:

Stage 1. A volunteer takes on a problem. For example, Snyk’s platform group discovered that builds were failing often. Crystal Hirschorn, Head of Platform, said, ‘We broke down the different types of failure states and saw that builds were failing about 70% of the time. We could see that was significant, and a high cost to us… We took that data to the SVP of Engineering to make a case for investing in that problem.’

Typically an existing team within the platform or infrastructure organization will tackle the initial project before a dedicated team is formed.

Stage 2. A committee is formed. Some organizations may form a group that sits alongside an engineering team, a product vertical, or persona, to solve a problem. The problem may be experienced across the organization, but this group works to solve the problem for one team first.

Once a solution has been incubated at the local team level and the value for solving that problem is clear, it may then be scaled more broadly across the organization. (For context, this is how Netflix would test these types of investments.)

At this point, the group may ‘graduate’ to become a centralized team within the platform organization.

Stage 3. A centralized DevEx team is formed. A centralized team may be formed because the initial project deserves more work or needs to be supported, or because other needs arise.

The DevEx team may expand their work into two lanes: their strategic bets (projects that solve issues that are experienced across the organization), and support requests from developers.

Their strategic bets are the primary projects the team decides to focus on that they expect will result in productivity gains for the organization. Support requests may include 1) reported bugs and feedback on the tools the DevEx team has built, or 2) general feedback from developers about their workflow (for example, problems they’re experiencing).

At this stage, the DevEx team risks becoming an ‘everything department’ because many problems that are surfaced are not owned by any other team. As a result, the team may slip into treating their backlog like a roadmap, instead of proactively prioritizing work that will have the biggest impact on the organization.

Stage 4. The DevEx team sets a charter and roadmap, and proactively identifies top needs across the organization. Eventually, the DevEx team will create a formal process for both identifying and prioritizing strategic work as well as for managing support in a way that does not interfere with the team’s strategic bets.

As for the latter, some teams do support rotations, others have a separate support team. Twitter, for example, has what they call a Tier 1 support team. Jasmine James, Twitter’s Senior Engineering Manager of Developer Experience, described how the Tier 1 support team works: ‘In our engineering effectiveness group, teams that actually owned services were being weighed down by constantly engaging with customers to solve problems. We needed a centralized way to free up bandwidth for the strategic work, so we created a global Tier 1 support team, which is a place where developers can go and ask for help and either get pointed to existing documentation or get help triaging a ticket in the right team’s queue.’

Beyond establishing a formal support process, some DevEx teams also hire product managers (PMs) to help their team be more proactive. A dedicated PM can help the team do a better job of listening to customers, defining personas, prioritizing work, and getting adoption.

The next chapter will describe the first step in deciding what to focus on: gathering data on what problems exist.