Stephan Schmidt

Accidental vs. Strategic Technical Debt

Is discussing technical debt outside of development a good thing?

Is technical debt a good thing or a bad thing? Should technical debt be discussed outside of technology or not?

It depends. As always.

In general, the worst thing is if technical debt is discussed outside technology. It means you failed as an engineering leader to manage technology #YouHadOneJob

Many developers and engineers think inventing the term technical debt was genius and let’s you talk to business about bad (unaligned) code (though in all honesty it should be called product debt most of the time, it wasn’t driven by technology). But it’s not. If you tell business you need to work on technical debt for some months or weeks, or features need to be pushed back for working on technical debt, you just look like you don’t know what you were doing. Even when, or especially when, business agreed to take on technical debt for faster delivery (they forget that they agreed, and they think you are the nerd, so you should have said no if these are now the consequences). Sometimes CEOs are held hostage and life some kind of Stockholm syndrome, and are eager to discuss technical debt though.

As an engineering leader, especially as a CTO, you need to make the tradeoff between the stability of technology and delivering business value. Highly stable systems with no business value don’t pay the salaries. A bad system that does not work or is unmaintainable but has (current) business value, is unsustainable. No one else is better suited than you, the CTO, to make that decision. Putting in an emergency brake because of technical debt means you failed that task.

This is what I call Accidental Technical Debt.

The exception for technical debt, that you should talk about outside of technology is Deliberate or Strategic Technical Debt. Strategic technical debt helps you execute your strategy, and is not accidental, but deliberate—even needed to execute on your strategy. There is no way around taking on that technical debt.

One example when to take on such a technical debt is around MVP (First Launch) and before PMF (Product-Market-Fit). Here it is a good thing (for the startup or for each new company product that runs through Prototype/MVP/PMF/Traction). You take on technical debt, so you can be faster in this crucial phase, not faster to deliver features to customers, but faster to iterate on ideas until you get PMF. The code might be a disaster, but the best code without PMF is worth—nothing. And you need to hit PMF fast, or the product will fail in the market (depending on your runway or patience with the product—large enterprises don’t have enough patience from my experience with them).

Yes, this should be discussed outside the technology department: how to get rid of technical debt - perhaps with a rewrite (the only time you should consider a rewrite) and migration to a new technology, to prepare you for scaling. But as a part of the strategy and process, not because it randomly happens and people outside tech are surprised - which from my experience is the way most often technical debt arises outside tech, surprising—because it’s forgotten and accidental.

To summarize:

Technical debt discussed outside technology as part of a strategy == good thing

Technical debt created and discussed otherwise:

Accidental technical debt == bad thing
Technical debt to push this one feature == bad thing
Technical debt as a surprise to the CEO == bad thing
Technical debt as a result of pressure == bad thing
Technical debt as the result of weak engineering management == bad thing
Technical debt as the result of un-alignment between business and tech == bad thing
Technical debt because of low skills and incompetency == bad thing

So there you have it. Technical debt is mostly bad to take on, is mostly bad to discuss, except discussing technical debt being part of your strategy.