Taking on and paying down technical debt

A common topic in product companies is the prioritisation of so-called customer-facing initiatives versus so-called technical initiatives (e.g., automated testing, reusable technical patterns, SDKs, automation, API-first services). The debate usually goes like this:

  1. We should focus on delivering customer value over anything. With our limited resources, any investment in non-critical technical work will only delay the features customers need.
  2. We need to invest in technical excellence now. If we don’t, we’ll have reliability issues and be inundated with technical debt.

The common-sense answer for all companies is to strike a balance between these two approaches. A company should not spend 100% of its resources on gold-plated technical foundations on which no customer value is ever built. At the same time, neglecting technical foundations self-destructive in the long term.

As products become more complex, maintenance burden rises. Paying down technical debt helps to manage this effect.
As products become more complex, maintenance burden rises. Paying down technical debt helps to manage this effect.

One way to look at this is by the stage of the company:

  1. Early-stage product companies are operating in a context of low confidence in their solutions because they are still looking for product-market fit. They probably don’t have a firm understanding of what they should build because they are still exploring what problems the market wants them to solve. In this context, it often makes sense to prioritise short-term product development velocity over long-term momentum because there is not yet any certainty on what features will end up useful or even whether the business will exist in the long term. Thus, a less technically excellent approach may make sense during this phase.
  2. Companies that have found product-market fit, and therefore have a pretty strong thesis for how they will scale, should be focused on scalability and optimisation. Strong technical foundations are critical to scalability and should therefore be a major focus.

The transition between the two stages above can be very difficult for product companies. In some circumstances, companies will find product-market fit before a significant amount of technical debt has built up, so starting to focus on technical foundations feels like nothing but a significant slowing of product development velocity. In most circumstances, technical debt has likely become a problem by the time product-market fit has been achieved, and the transition is even more difficult because the prescribed solution to velocity that has been slowing down (due to mounting technical debt) is a further (temporary) slowdown to pay back this debt and lay better technical foundations. This dilemma traps many companies into a very unhealthy cycle, where the bar for technical debt to be addressed becomes very high (i.e., essentially just critical bugs and security issues), so technical work is a burden to begrudgingly be addressed, rather than a valuable investment in critical foundations. This approach gradually slows development momentum to a crawl which can kill product companies if the need to build quickly should ever arise (e.g., disruption from competitors).

Resistance to technical investment is understandable — the solution to delivery inertia caused by technical debt feels like a further reduction in speed of delivery because it is. The two major changes usually required are:

The value, though, is that eventually, this alleviates the already existing inertia that is compounded by a lack of investment in technical debt, with the net outcome being an increase in speed of delivery. This shouldn’t just be thought of as debt, which implies that technical work is a burden to be begrudgingly addressed. Just as you can be disadvantaged by technical debt, you can also be advantaged by technical wealth. Put another way, by investing more in great technical foundations, you can see benefits beyond simply paying down debt to keep things moving at an acceptable pace (e.g., it is difficult to build in an API-first approach when you don’t have good foundations and patterns for how new APIs should be built. Pausing now to build some great foundations for future API services might delay the delivery of your first API, but it will speed up the delivery of subsequent APIs and simplify maintenance in the long term).

When you pause to build foundations, the first feature takes longer, but you will eventually catch up.
When you pause to build foundations, the first feature takes longer, but you will eventually catch up.

In summary, product leaders should think more about the positive outcomes of technical investment, rather than simply view technical work as a burden to be addressed to avoid negative outcomes. Product strategists need to understand the value of this work and ensure it gets prioritised. Many technical leaders need a better appreciation for the value of sprinting towards product-market fit in the early days of the company, and businesses need to transition away from this approach before technical debt becomes insurmountable (with ample appreciation for how difficult this transition is).

22 December, 2021

Subscribe for updates

Subscribe for weekly advice covering product strategy, development operations, building teams and more.

Privacy and terms

I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.

The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.