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.

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:

• A pause in feature development to focus on paying back debt and building better foundations for the future (e.g., writing tests for legacy code), thus delaying features on the roadmap for some time.
• The padding of future work with additional technical effort (e.g., writing tests), thus slowing down the delivery of features in comparison to what the business is accustomed to.

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).

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).

Technical debt is another reason to keep the scope of your product very narrow until you achieve product-market fit. The less broad and complex your product is, the less technical debt you’ll accumulate. Catching up on your under investment in technical foundations will be much easier. Don’t expand until you can do it right.