How to pitch for DevX at your company

At best, Developer Experience (DevX) teams have second order effects to the bottom line. But more commonly, those working on DevX are seen playing whack-a-mole with issues.

They see a problem, they fix a problem, they tell other devs about that fix. And the cycle continues.

At the end of the day, all devs want to have good DevX. Let's face it, there's a cost to poor DevX.

How do we convince our company to form a DevX team?

This is something I've been thinking hard about these last couple of months. And I recently successfully pitched to form a new DevX team here's how I did it.

What is the problem?

Focus on the second order effects of a DevX team. If a dev spends x amount of time fighting with local development. And this team reduces that time, how many more features can we push? How much money are we saving?

If you're starting a new DevX team you might not have these metrics. I know I didn't. Instead, I broke the problem down into these three areas:

• Knowledge silos

• Blurred Responsibilities

• Communication overhead

I called attention to our currently visible pain points, that leadership was most likely already aware of. And had examples at the ready if there weren't aware.

Tell the story of the end goal

Continually push the narrative of what the future looks like with this team. Some examples:

Instead of a dev bouncing around between people and Slack channels trying to find out who can help them. If we had a DevX team, they can go to this one team.

If we had a DevX team we could push for end-to-end dev metrics that would help answer some of the second order effect questions.

A story telling template I found myself using:

With a DevX team we could do X, which is not something we can achieve with our current structure. And that leads to Y.

Define the logistics

We know the problem, we know what the end goal looks like. But what about everything in the middle?

You need to define what this team looks like, how it might operate, who the developers could be, and what projects you would initially focus on.

During my pitching session there was a lot of questions around roadmap of this team. Have a few large projects at the ready.

Treat DevX like a product facing team.

This is an idea I've slowly come around to. The devs are our users. And we should treat every release like we would a product release. That means product strategy, success metrics, OKRs, etc.

Make the decision easy

An easy decision is one that is cheap, and reversible.

I pitched DevX as an experiment. I'd run this team as a product team for half a year to a year. Take devs from other teams that are already working on DevX so to not adversely affect roadmaps.

I listed the success criteria, the alternatives, and if the experiment failed. Devs would rejoin their respective teams.

Proposal Doc template

All of the above points I put into a proposal doc. Here was the template I used, I hope it helps!

• What problem are we trying to solve?

  • Keep it succinct. Metrics help. Have examples ready.

• Proposal

  • Highlight that this team is an experiment.

• Success Criteria

  • What does success of this team / experiment look like?

• Logistics

  • How will this team operate?

• FAQ

  • Answer common questions or concerns you've heard when talking to other people. This section is where I listed the alternatives, or what happens if the experiment fails.

A DevX team can have a huge impact at your company. And if you're not sure how to pitch for a DevX team start with the problem (why), then the proposal (how), and then the logistics (what).