ROI as the Ultimate Measure of Engineering Team Success
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. 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 the 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 a 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 in 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 straightforward, 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’ 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.
When Proxies Are Less Direct
For the rest of the world, especially in B2B businesses, SaaS platforms, and big enterprises, engineering work can take months to ship and even longer to implement. In that case how do you measure ROI? When you talk about building something bigger and more strategic, measuring just one or two metrics that can directly lead to revenue generation will be hard to correlate. Instead we need to develop proxies for value (realizing, of course, that return in this sense is not strict). These could be measures you’d likely think of:
- Deals where the feature is identified as a necessary feature
- Frequency of usage of a particular feature or features
- Number of users
- Adoption of a product or feature
- NPS, or other customer happiness gauges
Or it might be something a little less obvious:
- Customers NOT churning
- Usage by a broader user base
- Adoption by Sales Engineering for use in demos
While these metrics may not be tied directly to revenue creation, they can be assigned value to the business or at least correlated to a business outcome. That value - the return earned by investing resources into a product, feature, upgrade, etc. - simply needs to be defined and agreed upon across organizations.
Measuring ROI can be one of the best ways to directly align your engineering organization with the needs of the business. You may even find that the simple act of figuring out the right proxy proves itself to be valuable and drive alignment within the organization. You’ll need to define what return truly means to your organization, agree about the proxy or proxies that make the most sense to measure that return with the rest of management, and then measure and optimize for that.
Engineering Management Platforms can streamline this process by automating that measurement, highlighting where investments are being made, and underscoring the efficacy of course corrections along the way. However, you choose to do it, measuring and optimizing for ROI on the engineering team may be one of the most important steps you can take toward building a highly successful engineering team.