Tech debt refers to the cost of redeveloping existing products and code that wouldn’t otherwise be able to scale or evolve over time to meet shifting consumer needs. And while the concept has been around for years, for most of that time, tech debt was primarily the concern of product and engineering teams. These days, by contrast, more and more executives are taking an interest given tech debt’s impact on enterprise value. They’re also increasingly holding their teams accountable to manage it appropriately.Tech debt refers to issues in legacy code that slow the development process, impact developers’ efficiency and productivity, and negatively impact the quality of the final output. It often occurs when software developers and engineers take shortcuts, resulting in design flaws and code that’s harder to maintain than it needs to be.To be clear, every company accumulates a certain amount of tech debt over time. Sometimes they do so intentionally because they feel pressure to get to market faster. And sometimes it happens unintentionally as products and systems evolve, best practices change, or upgrades to new toolsets and functionality become more difficult to implement. Regardless of the cause, unless it’s properly managed, the result is typically poor team performance and the release of substandard features, which can ultimately lead to customer churn and delays in going to market.
Lauren Kelley, CEO of OPEXEngine, a leading independent third-party provider of SaaS benchmarks, provides a great illustration of tech debt using the analogy of how financial models are constructed. Financial models can take a variety of forms and be as simple or complex as the creator wants based on the use case, the audience they’re for, and the time required to complete them. If a model is required quickly, CFOs may hard code numbers to provide an answer as opposed to creating a dynamic model with formulas and links to other spreadsheets and data, which is a longer and more involved process.Yet if the model needs to be adjusted at any point in the future, the lack of formulas could make that process difficult and lead to errors. This is an example of tech debt in the context of a financial model. Because the benefits of carefully constructing the model weren’t worth the investment of time initially, the CFO has made a conscious choice to take a shortcut now and, in so doing, to incur a form of debt or obligation to invest time to fix the problem at some point in the future.
Why tech debt matters
When people think of tech debt, they immediately assume it has a negative connotation. And yet, similar to financial debt, there’s an optimal amount of tech debt that companies should incur to grow and scale their business. The key is to avoid accumulating too much or too little of it and to understand where it exists within your products and systems.SaaS companies are under pressure from their executives, investors, and customers to release new products and features faster while improving value to all stakeholders. “One of the main reasons why companies often intentionally choose to incur tech debt is because they want to be first to market so that they can build brand recognition and establish a loyal customer base,” says Kelley. “That desire leaves developers having to weigh the value of an earlier release against the cost of fixing or rewriting sections of code later on.”Seen from that perspective, tech debt is a calculated business decision companies need to make as they look to strike the right balance between speed to market and perfection. Finding that balance will depend on the stage of business, resource constraints, the competitive landscape, and existing tech debt levels. Executives have to evaluate if their business is erring too much in one direction or the other.
“Companies with too much tech debt risk bringing products to market with underlying problems that will take ever-increasing amounts of time and resources to solve,” says Kelley. “Meanwhile, those companies set on perfecting the code can take too long to release products and features and wind up with tech bloat.” When that happens, they risk losing market share to competitors who got their product out first, making it more difficult to acquire customers.
Customer churn is a very common indicator of high levels of tech debt as either new features take a long time to be released or the customer experience is poor due to bugs in the code or immature user workflows. It’s important to track why customers churn to differentiate between product-specific issues and issues that pertain to customer success and operations, such as poor implementation.
Measuring tech debt
Given the impact of tech debt on business performance and end-user satisfaction, being able to measure it is critical. However, metrics measuring tech debt, specifically as they relate to investment in research and development (R&D), are still not on most people’s radars. The SaaS community has historically been focused on sales and marketing metrics and is only now beginning to show similar levels of interest in R&D-related metrics. Tech debt metrics are still in their infancy and we expect they’ll become more robust over time.
Tech debt is measured by the investment required to remediate bugs in the code as a percentage of total R&D spend. Spend on tech debt as a percentage of total R&D spend is associated with other R&D management metrics such as R&D employee retention rates and percentage completion per sprint. Below we look at each of these metrics and identify the benchmarks SaaS businesses should be striving for.
Tech debt as a percentage of total R&D spend
Tech debt is measured as the percent of R&D spend associated with fixing bugs in code. In other words, out of the total R&D budget, how much of that spend is ascribed to development resources that go back to fix problems, refactor poorly implemented features, or re-implement something to support a new requirement?
It’s important to remember that not all tech debt is bad and that the optimal amount may depend on a variety of factors such as the life stage of the business and the business model. The reality is that you are going to have less tech debt early on in a company’s life than later. Startups begin with no tech debt, but as they grow the chances of incurring it increases unintentionally as they lose focus on product development.Early-stage companies have different benchmarks than their later-stage peers because they are starting with a simpler codebase. In addition, there are fewer developers working on the existing code base than at later-stage companies. Early-stage businesses also tend to be laser-focused on laying the foundation for a flexible code base and building products, whereas larger companies may have legacy code that was once high quality but has degraded over time, with workarounds on top of workarounds to fix the shortcuts initially taken. Larger enterprise SaaS businesses tend to be focused on sales execution and profitability rather than investing in R&D.
Tech debt as a percentage of total R&D spend
Among early-stage companies with revenues between $10 million and $20 million, where the companies are still early in testing product-market fit and scaling their business, tech debt constitutes approximately 11 percent of total R&D spend among first quartile companies, while for 3rd quartile companies it’s 15 percent. For later-stage companies that have up to $100 million in revenue, 18 percent is the benchmark for first quartile businesses, while it’s 30 percent or more for business in the third quartile.
While these benchmarks are provided as a guideline, Kelley notes that management teams should take resource constraints and market considerations into account as well. “There may be strategic reasons for having higher or lower percentages of tech debt,” she says. “For example, there may be valid market reasons why a company chooses to cut development corners in the short term to bring the product to market faster, or they may invest in perfecting their codebase to mitigate churn risk, resulting in lower levels of technical debt.
”Going back to the financial model example, strong CFOs understand the effort in building a model that can be adjusted dynamically, but that’s also simple to understand and easy to provide in a timely manner without incurring a significant obligation to fix the code in the future. Tech debt spending against benchmarks is an important indicator for the business to monitor to measure how the development organization is balancing development quality with development speed.
Other metrics associated with tech debt
In addition to the benchmarks identified above, there are some other metrics that companies can use to better understand the issues related to technical debt. These include:
- Percentage completion per sprint: 50 percent is the median benchmark and a lower number could indicate definition issues or, more concerningly, execution issues.
- R&D employee retention: There are correlations between high growth, efficiency, and employee retention. That’s because employees want to work on great products and will leave if they’re constantly having to fix bugs and resolve customer support tickets. Measuring employee retention within product and engineering teams can help identify high levels of tech debt or poor management.
- System uptime: If your systems crash when there’s high traffic volume, it may be a signal that there’s technical debt.
Tech debt may exist when there’s friction between software developers and the release of a product or features as certain areas of code take longer to fix or engineers may be reluctant to tackle the problem. Measuring tech debt is important not only so that you become more efficient operationally, but to proactively mitigate customer churn and employee turnover.
Why investors should care
Tech debt isn’t just an abstract managerial challenge. It also has real-world implications for valuation, and therefore for investors.
As we’ve discussed, companies are trying to resolve the tension between getting the software to market and making sure it isn’t full of bugs. Perfection might involve going back to foundations and rewriting code from scratch to get an ideal solution. Obviously, there are direct costs associated with doing that since, even if you have the right staff to do so (which isn’t always a given), it takes a long time. That’s the time when you’re paying staff and not selling your product, so there’s a direct impact on your revenue line and your margins, both of which can affect valuation.But those are relatively trivial concerns compared to the cost of being late to market and ceding the first-mover advantage to a competitor. While you’re busy perfecting every line of code in your suite, someone else may have written something that’s good enough to sell and gone ahead and sold it. Now your customer base has a solution to their problem, and you not only have to sell them your product, you also have to get rid of an incumbent. That’s much harder to do than selling in the first place, and if it doesn’t happen, your sales won’t just be delayed, they’ll be nonexistent.
Of course, you can’t go too far in the other direction, either. If you constantly put out products that solve the problems right in front of them, with no consideration paid to architecting for future use cases, it’s going to get harder and harder to adapt to them when they arise. So while accumulating some tech debt can enable you to generate substantial near-term revenue growth eventually, that debt can stop you dead in your tracks and force the return to foundational principles that you were trying to avoid in the first place.
Tech debt has a very real impact on valuation and should therefore be a central concern for investors. But just as it isn’t a linear consideration for managers, for whom whether more or less is better has to be decided in the context of a whole range of business judgments, it isn’t a straightforward analysis for investors either. So, how should companies address it?
From measurement to action
Tech debt can be an indicator of how competent management is and the overall culture at the company in terms of whether they encourage a flexible working environment or promote speed versus quality of the product. Tech debt can ultimately be viewed as an intangible liability with a hidden cost associated with paying down this debt. Tech debt levels that are too high can cripple a business. But tech debt can also be a useful tool to get to market and generate a return on investment sooner rather than later. Executives and their boards need to monitor, benchmark and report on these metrics to be proactive and make the right decisions for the business in line with their plans.
