Etsy’s former CTO: how to advocate for DevEx initiatives

One of the biggest challenges DevEx leaders face is advocating for improvements in ways that other business leaders can understand. Problems like tech debt or a poor on-call experience don’t always neatly translate into ROI cases because they impact developers in more ways than just wasted time. 

We reached out to Mike Fisher, who was previously CTO at Etsy, on how he  successfully advocated for the company to invest 20% of their engineering capacity into a multi-year DevEx initiative. Here, Mike shares his advice on how to make the case for developer experience improvements. 

With that, it’s over to Mike.

While I was CTO at Etsy, I led a multi-year DeEx initiative that had around 20% of our engineering capacity allocated towards it. 

We were already familiar with that level of investment because we had recently completed our migration to the cloud, a project in which we had invested about 25% of our capacity. That made it a little easier for us with the DevEx initiative, but still, this was not insignificant. These programs come with an investment, but we’ve proven the importance of them time and again at different companies. 

There are a lot of tech leaders who would find it difficult to convey that the company needs to invest nearly a quarter of their engineering capacity in developer experience improvements. But these are the types of conversations you need to be prepared to have. 

Here’s what worked for me when advocating for these investments: 

Translate estimated results into financial impact

Most of the time you’ll be the most technical person on the executive team. As soon as you start talking about something technical, their eyes are going to roll back in their head. It doesn’t make sense. 

You have to translate what you’re saying into a language they can understand, which is typically finance. Money. I’m not a huge fan of monetarily-driven metrics, but if you use them to translate the impact of an initiative on the business, they help. 

We were able to do that with deploys, for example. If you can take a deploy from 15 minutes down to 7 minutes, we can see how substantial that is by taking into account the average salary for engineers, how frequently they deploy, and the time saved that could be every week. This calculation doesn’t account for the cost of disrupting flow. It also is harder to calculate for things like reducing pages that disrupt developers’ evenings so they’re less productive the next day. But that’s why I call these calculations “back of the envelope": they don’t have to be precise to communicate the opportunity to the executive team. 

You can also look at longer-term problems like attrition. If someone leaves my company, my estimate is you lose at least 6 months of productivity, or 12 if they’re more senior. So you can start telling your leadership team: “the industry average is 10% attrition per year. If we can cut that in half to 5%, we save X months of productivity.” These numbers really start to matter as you have more engineers. 

The important point is to translate the impact of these problems into numbers that everyone can understand. And know that it doesn’t have to be precise; it can be rough math. 

Showcase results quickly

We made an upfront commitment to share results on a quarterly basis. These check-ins would be used to show progress and signals of whether our investment was giving the returns we expected. We actually shared these back with the engineering organization and eventually made them part of our engineering all-hands. 

By committing to these check-ins, we helped alleviate the concern from other executives that we’d go off, spend a lot of money on these efforts, and they wouldn’t really do anything for the company. We also alleviated the concern that we’d work on the initiative for 18 months and come back with a report once the project was completed. Instead, we decided we’d take them along for the journey and make sure everyone was aware of what was going on. We shared increments results through status emails and meetings, even when the progress was simply lessons learned. 

(As an aside, there is a story where we rolled out GraphQL and had some setbacks and ultimately pivoted away from it. Showing executives that you’re willing to change plans when things aren’t meeting your needs is important.) 

Get ahead of planning cycles

Many organizations believe there should be a pairing of Product and Engineering from the C-suite all the way down to the line manager. Etsy worked that way too, and it was an important way to build relationships. As CTO, I spoke to my Product partner every day. We were in meetings together, we spoke on Slack or in 1:1s, we were in constant communication. That partnership between product and engineering is an important channel to start socializing plans for how engineering capacity should be allocated. 

The timing here also matters. If you’ve already put together an annual plan for engineering capacity, you’re going to have a difficult time getting an investment like this pushed in. If you’re thoughtful, you’ll start having these conversations and socializing your plan ahead of the organization’s annual or quarterly planning cycle.  

In these conversations, keep selling the benefits of developer experience improvements. If we add another engineer, they’re not going to be as productive but they are going to cost the same. So it’s not a good investment for the business to hire more engineers unless we do this work. 

One additional piece of advice: when socializing this idea, executives will want to see examples from other companies who have led similar initiatives. Those examples can come from other companies who have done this, examples from your own experience, or examples from people you’ve talked to. Show what the investment was and the ways that it paid off.

For more from Mike, listen to his interview on the Engineering Enablement podcast and subscribe to his newsletter.