2 Schools of Thought on ROI

Communicating the total impact of your engineering team’s efforts is one of the most important responsibilities of engineering leaders. At the same time, it can be one of the most difficult and nuanced conversations to have with executive leaders from different departments. They’re conditioned and used to some version of an ROI metric, i.e. how much return they are seeing from our investments in sales, marketing, etc.   

But can the concept of ROI be applied or adapted for engineering teams? And if so, why aren’t more leaders doing this today? 

In this blog post, we examine this question more directly, and the two schools of thought regarding measuring ROI in engineering. The short answer to the earlier posed questions is that it’s difficult but critical to speak beyond just the total effort going into specific engineering areas. We can all improve in communicating the expected (or recognized) returns from those time investments. Let’s dive into how leaders think about this topic.

How Leaders Approach Engineering ROI

There are two schools of thought regarding how to measure the ROI of engineering:

1. All engineering work can be summarized in terms of revenue and costs.  
2. Attributing engineering work to revenue is impossible. You simply cannot calculate the impact of engineering work in terms of ROI.

The first is a very direct aspiration to map engineering work back to investment value in the traditional sense. If achievable, it’s the most easily understood way to communicate value. The reason more teams do not do so can be boiled down into one of a few points.  

1. The time from when the team first starts work to when the company sees revenue can be a long cycle. 
2. Many teams can end up working on a given feature through its lifecycle. During this time their level of effort might vary. How much revenue do you attribute to your team vs. the others? 
3. Sometimes net new revenue cannot be attributed back to a single feature or improvement in the customer experience, especially when you’re continuously making updates and delivering value to the customer. 

In short, companies with short development and sales cycles, and highly mature attribution feedback loops, will see success from adopting the first school of thought as their approach. But what about those not in those conditions? Is communicating engineering ROI impossible for them? 

The best approach for most lies somewhere between these two schools of thought. Where revenue can be attributable to engineering work, do so. When this isn’t possible, a proxy for revenue is required in its place. But it’s vital to never solely speak about engineering work in terms of cost. When you do so, you’re indirectly over time signaling to other leaders that engineering should be thought of as a cost, not a strategic long-term investment and competitive differentiator. In reality, engineering is the innovation engine that enables the entire revenue machine to work in the first place. The ability to assess its health and impact is a business imperative. 

The Value of Assessing Costs of Engineering Work

In general, leaders feel more comfortable speaking about the costs of engineering, as they are tangible and measurable. With Engineering Management Platforms, you can break out the costs of certain work over others and discuss the trade-offs of making prioritization decisions with other department leaders. For example, if you re-architect your database, it might save your team X hours a month in additional work running manual queries. This will give your group X hours back each week towards other tasks/priorities (such as code reviews, new feature development, etc). Even without this being directly tied to revenue, it is directly tied to margin, more specifically the direct cost of those developers’ time. 

Attribution and the “Revenue Proxy Issue”

Speaking to the costs saved from certain engineering work is valuable and extremely important, but it will not account for inherent value of all engineering work. For example, many engineering teams work on new marketable features, which are, by definition, intended to drive net new business. And in the cases where this is challenging, a proxy for revenue is necessary. This conversation is a bit more nuanced and in our next post we’d like to explore how to find and decide on revenue proxies in the instances where they are required.