Originally posted on August 10, 2020. Updated content on January 10, 2022.
As engineering leaders and technical executives, we often find ourselves talking about the costs of our organization, but in order to make sound business decisions, we also need, and often fail to outline the benefits of those costs. Instead, we should weigh the costs and benefits of our decisions by measuring the ROI, or return on investment (as outlined in a recent blog post). In order to ensure the engineering team is aligned with the needs of the business, we might consider using the same standards as the rest of the organization to make engineering decisions.
ROI can give us a clearer way to understand how the work of the engineering team directly impacts the business. That in turn allows engineering and product leaders to make more informed decisions about which products, features, and teams to fund more aggressively and which ones to back off from; we can understand what features in a product are worth spending more resources building; and they can analyze on a post-facto basis whether they invested in the right features, translating to better decision-making about resource allocation and investments in the future.
For some organizations, the responsibility of optimizing benefit over cost (and determining how benefit is defined) falls to the product organization, the executive team or sometimes even the CEO. In many others, that responsibility is not left with anyone. I assert it should be to avoid a “tragedy of the commons” situation where everyone cares, but no one takes it upon themselves to solve! Regardless of where your company falls, you will benefit from measuring the success of your engineering teams by thinking about the ROI of your team(s). It will help you align the work being done and the needs of the team with not only the product team, but also with the entire business, building common language and trust with Sales and Marketing leadership, and ultimately ensuring the alignment and success of the business. Measuring ROI for Engineering is not straightforward nor an exact science; it needs some careful consideration before you dive in, but that doesn’t mean we shouldn’t try.
Measuring Engineering ROI the Simple Way Isn’t So Simple
The easiest way to measure ROI of the engineering team’s work is to use the strict definition – that is, tie the work done to “return” or revenue outcomes. In this case, when choosing which products or features to invest engineering resources toward, the answer is simple: invest in the products that generate revenue, or at least consciously choose to invest in non-profitable things. While this might be the most straight forward, unfortunately very few companies have the luxury of operating this way. Why? It’s not always clear what specific work went into a closed deal or the onboarding of any number of new customers. For example, for a deal that closes for your SaaS platform, which features, work and people get attributed to that? What if a deal closes a year after a feature was built? So the reality is that we have to find proxies for revenue.
Using ROI Proxies
In a lot of ways, B2C businesses can often be closer to this measure of ROI. Some of the most recognizable brands in the world have claimed to optimize their engineering efforts around one function that they use as a proxy for revenue. This function is ubiquitous and true to all features. Simply measure that revenue proxy and optimize around that metric (Think: song plays that generate revenue in a music streaming service or advertising impressions in a social network), and voila! You’ve optimized for ROI.
The problem here is that most businesses evolve, and their priorities shift over time. Measuring just one metric can only optimize for a single point in time. In the example of a music streaming service, imagine now that this service finds their customers are willing to hear more ads and thus generate more revenue from podcasts. The business’s priorities must shift with the changing preferences of its customers. In these scenarios, companies end up measuring and optimizing for multiple revenue proxies over time.