One of the biggest challenges DevEx leaders face is advocating for improvements in ways that other business leaders can understand.
I recently discussed this on my podcast with Mike Fisher, Etsy’s former CTO, who shared: "You've got to be able to translate technical issues to a language that non-technical people understand. And in business, the common language is money. When you can translate technical issues into dollar values, it helps."
Mike’s suggestion of translating DevEx into dollars is a common approach I see. Conveying engineering bottlenecks in financial terms can help make esoteric technical problems much more relevant and easier to understand. This, in turn, can help with convincing business leaders to invest in DevEx improvements.
The formula behind this approach is roughly:
This formula can be applied to many types of situations. For example, if your organization of 25 engineers runs 50 builds per day which take about an hour to complete on average, you can multipy 50 by the hourly FTE cost of your organization (e.g. fully-loaded headcount costs of $5,000,000 per year divided by 2,340 work hours per year), which gives you the cost of slow builds: $106,837 per year.
While this formula is useful, there are several limitations of this approach:
1) Delays don't always equate to time wasted. Take code review turnaround time, for example. It would be easy to apply the formula just discussed to calculate the cost of delays in code review, except that this would likely lead to an inflated dollar figure. Why? Developers typically don't sit idly by while waiting for a code reviews—instead, they go do other productive work.
2) Delays cause second order effects. For example, in a recent article, Google researchers noted that slow build times cause developers to context switch more often, which has negative consequences on productivity. Another example: engineering friction can lead to delayed time to market, which impacts business revenue. Without accounting for these types of second order effects, we risk underestimating true costs.
3) Not all DevEx problems can be measured in terms of time. Friction in areas like builds and code reviews are relatively easy to measure and therefore get a lot of attention. However, other important aspects of developer experience — such as collaboration or rework — are more difficult to observe. As a result, companies often skip investments in these difficult-to-measure areas in favor of less impactful areas that are easier to measure.
I haven't yet come across a real-world example an approach that overcomes these limitations. However, I believe that such solutions do exist. One approach that I am optimistic about: if you can correlate two things to each other, and then correlate one of them to money, then you can express them both in terms of money.
For example, leaders at eBay pay close attention to SiteSpeed because its financial impact is well understood. But this is only the case because someone years ago intuitively thought that SiteSpeed was important, then conducted A/B tests which were able to correlate SideSpeed to dollars.
I believe that a similar approach based on correlations, rather than back of the napkin, could be applied to developer experience. Although this approach requires substantial investment into research and analysis, the results could fundamentally change the way organizations think about investments in developer productivity.