When considering an investment in a software company, what are the most important factors to weigh? Investors, VC and PE alike, tend to prioritize analysis of multiples and revenue projections that determine whether the company can deliver a satisfactory ROI. Often these calculations rely on the flawed assumption that the company can meet those projections through successful feature development to introduce new products, move upmarket, or upsell existing customers, all done without any considerable hiccups. Less credence is given through the course of the deal to evaluating the quality of the R&D team and its ability to dependably deliver these features or products, despite the impacts on future sales and strategic company objectives.
Either due to a lack of understanding in tech or a blind trust in the CTO, the R&D department continues to function as a “black box”. Issues with productivity can bubble below the surface and are inherently hard to quantify. Even the executive team is often unaware of how underperforming or misdirected the R&D team truly is. These systemic problems can surface months or even years down the road, and it may take just as long to remedy the harmful impacts they create.
In this article, we outline common issues explaining why investors miss this during diligence and post-close phases of deals.
Low Correlation Between Financials and Productivity
On the surface, strong revenue growth and healthy margins can belie underlying issues with the R&D organization, and financial success is indeed possible even without a high-functioning development team. Moreover, it is not enough to look at a heavy R&D spend line item and assume that a large investment will result in productive returns.
A highly priced R&D team may signal that the company has invested for growth, but BP has looked at dozens of companies where low economic output results in a delivery cadence on par or below benchmarks of average spend. Usually, this indicates that:
High salaries may be allocated to employees that do not possess the skillset necessary to do their job
There may be significant delays in the product management and development process as a result of significant overhead, poor communication between functions, bottlenecks, or a tendency to focus on building for one customer vs. many customers
These scenarios are especially problematic, since high R&D spend usually means that the company has planned investment for growth in new product innovation; if the team is dysfunctional, the company may struggle to go-to-market with competitors at a critical impasse for the organization.
Long Feedback Loops
A primary obstacle in assessing productivity issues from an external perspective is the months- or years-long gap between when issues in R&D occur and when that impact is felt outside of the department. Similar to addressing climate change before material impacts are felt, identifying an unhealthy R&D organization is difficult because symptoms materialize slowly over time, far beyond when the ink on the deal has dried.
If systemic defective code is being created by Development, it lies dormant until found by QA, or worse, by a customer. If Development’s rate of production is low, the problem does not become evident until deadlines and product release dates are missed. For those without visibility into the office of the CTO, signs of trouble appear only when roadmap deadlines begin to slip, or when support tickets stream in with complaints of buggy systems.
These issues can have profound impacts on the strategic objectives of the company, and unfortunately may take just as long to remediate as they did to manifest. What’s more, bugs found by customers are more expensive to fix than those caught early in development (research has been done to attempt to quantify this discrepancy; experts have estimated defects found in Production can range from three to five times as expensive to remedy than ones found earlier in Development). Eventually, these issues impact sales and revenue numbers; if issues began to fester at the time of the initial deal, problems may only become visible three to five years down the line, when investors are thinking of exit opportunities.
Dysfunction is Difficult to Identify
Ancillary to and compounding the two aforementioned points is the fact that the output of the R&D organization, code, is not easily measured. Traditionally, when widgets were output on the assembly line, it was easy to quantify the factory’s output, and fluctuations in productivity were transparent. With code, the widget is always being designed for the first time. No matter how standard a project or application may seem, there will inevitably be some wrinkle thrown in, some novel integration or customization, which will make designing the code a non-trivial problem.
Code is not simply measured by the number of lines written (there is zero, perhaps even negative, correlation between the quantity and quality of code being produced), but rather in the functionality that it accomplishes. This does not take into account the latent defect, technical debt, or complexity issues that are potentially created and which can complicate the issue and inadvertently extend future development time. Developers try to capture these in “stories” and quantify through metrics such as “points”, but often only the people sitting closest to the system fully grasp the progress and work needed on the project.
Non-technical investors are inherently disadvantaged when examining the team, as code development has no other visible output (unless you are fluent in coding) other than the end-state functionality once development is complete. Trust in the production capabilities of the R&D organization falls to the perspective of the CTO or VP of Development rather than direct involvement.
Despite the self-contained, isolated nature of Development, the paradoxical truth is that its job has a higher impact on the rest of the organization than any other function in the company. The organization may see its differentiation in the market slip as competitors catch up in feature parity.
Buggy codebases cause customers to lose faith in the product and turn to alternative solutions, or slow down feature development, enabling competitors to catch up.
The key is to put heavy emphasis into identifying these issues early in the investment cycle. Previous articles of ours identify non-technical and technical best practices that can indicate whether an organization is on the right path. More than anything else, productivity is driven by strong R&D leadership which has a focus on top-down quality and deliverables, productivity metrics, and strong adherence to industry best practices, now increasingly following the Agile methodology.
[This article was contributed by Matt Hannon, Director and Alex Saich, Associate]