What Is Strategic Technical Debt?

By Gareth Price · Last updated

Debt as a financing instrument, not a symptom of failure

In short: Strategic technical debt is a deliberate shortcut taken to ship sooner and managed like a loan. Gareth Price’s Applied Alchemy treats technical debt as a financing instrument: used well, it buys speed, tests a hypothesis or reaches a market window. The startup CTO’s job is not to avoid debt but to know when to borrow, what the interest costs and when to repay.

Borrowing on Purpose

The metaphor comes from Ward Cunningham. In 1992, explaining to his business partners why working code needed rework, he wrote: "A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid."[1]

Chapter 5 sorts a startup’s debt into three kinds:

  • Debt you chose. The mortgage. You shipped a monolith knowing you would need services, or hardcoded configuration knowing you would need a configuration service. This is strategic debt.

  • Debt you inherited. Someone else’s mortgage, shaped by decisions you did not make.

  • Debt you did not know you had. The unpatched dependency, the assumption that breaks at ten times the load.

Strategic debt maps to the prudent, deliberate corner of Martin Fowler’s technical debt quadrant: a conscious trade-off with a plan to address it.[2] Its risk stays manageable as long as you track the obligation and schedule repayment before the interest compounds.

Why It Matters: The Interest Is Real

Stripe’s 2018 survey found engineers spend 33% of their time, 13.5 hours a week, on technical debt and maintenance.[3] For a ten-engineer startup, that is 3.3 people working on the consequences of past decisions.

The interest is not charged by age. Fowler notes that you only pay "when I have to work with that part of the software."[4] A five-year-old module nobody touches costs nothing. A six-month-old service on the critical path costs you every sprint. That is what makes debt a prioritisation tool rather than a moral failing.

Example: From Complaint to Business Case

The book contrasts two ways of saying the same thing to a board. "We have a lot of technical debt" is a complaint. "We are spending 33% of our engineering budget on debt service, and I want to reduce that to 20% over the next two quarters by investing in these three specific migrations" is a business case.

The second version names the principal, the interest and the repayment plan. It is the language of a financing decision, which is exactly what a strategic debt is. It also passes a test the first version fails: a non-technical executive can weigh it against other uses of the same money.

How to Start This Week

  1. Write down every shortcut you took on purpose in the last quarter, with what it bought you and the condition that will make you repay it.

  2. Run the book’s three-question audit. Where is the team spending unplanned time? What would break if we grew ten times? What can nobody on the team explain?

  3. Measure maintenance load, Chelsea Troy’s ratio of tickets that fix or work around existing code to tickets that add features. Above 40% means debt is hurting your ability to compete; above 50% is an emergency.[5]

  4. Reserve a fixed share of each sprint, 15 to 20 percent, for repayment, starting with debt in the code the team touches most.

Strategic Debt vs "Messy Code"

In everyday use, technical debt means sloppy code. Cunningham rejected that reading. In 2009 he said bloggers had confused the metaphor with "the idea that you could write code poorly with the intention of doing a good job later," adding: "I’m never in favor of writing code poorly."[6] His metaphor was about the gap between what you now know and what your code reflects. Strategic debt keeps that spirit. It is a decision, written down, with a price attached. Reckless debt is the credit card: easy to run up, expensive and compounding. The difference is not code quality. It is whether anyone chose it.


Frequently Asked Questions

  1. What is strategic technical debt?

    Strategic technical debt is a deliberate shortcut taken to ship sooner, recorded and repaid like a loan. Applied Alchemy treats technical debt as a financing instrument rather than a symptom of failure: borrowing can buy speed, test a hypothesis or reach a market window, as long as you know what you borrowed, what interest it charges and when you will repay it.

  2. Is technical debt always bad?

    No. Deliberate, well-understood debt taken on to ship faster or validate a hypothesis can be the right decision, much as a mortgage can be. The problem is unmanaged debt: shortcuts taken without awareness, never written down and never scheduled for repayment.

  3. Who came up with the term technical debt?

    Ward Cunningham, in a 1992 experience report on the WyCash portfolio management system. He used it to explain to his business partners why working code needed rework once the team understood the domain better. In 2009 he said many people had confused the metaphor with writing code poorly on purpose, which he was never in favour of.

  4. How much does technical debt cost a startup?

    Roughly a third of engineering time, according to several independent surveys the book cites; Stripe’s 2018 developer survey put it at 33%, or 13.5 hours a week. For a ten-person team that is about 3.3 engineers working on the consequences of past decisions. The interest depends on how often you touch the code, not on how old it is.

  5. When should a startup pay down technical debt?

    When the interest costs more than the repayment: when the time lost working around the debt on every change exceeds the time it would take to fix it. Prioritise debt in code the team touches often. Treat more than 40% of engineering capacity going to maintenance as a warning, and more than 50% as an emergency.

References

1. Cunningham, W. (1992). The WyCash portfolio management system. OOPSLA ’92: Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications, pp. 29–30. ACM. https://c2.com/doc/oopsla92.html — DOI: 10.1145/157709.157715. 803 citations in ACM Digital Library.
2. Fowler, M. (2009, October 14; reposted November 19, 2014). Technical debt quadrant. martinfowler.com/bliki. https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
3. Stripe. (2018, September). The developer coefficient. https://stripe.com/files/reports/the-developer-coefficient.pdf — Methodology: Harris Poll partnership, thousands of C-level executives and developers across 30+ industries.
4. Fowler, M. (2003, October 1; substantially rewritten May 21, 2019). Technical debt. martinfowler.com/bliki. https://martinfowler.com/bliki/TechnicalDebt.html
5. Troy, C. (2021, January 14–21). Quantifying technical debt / Avoiding technical debt / Reducing technical debt \[Three-part series]. chelseatroy.com. https://chelseatroy.com/2021/01/14/quantifying-technical-debt/ — Troy is a staff software engineer at Mozilla and teaches at the University of Chicago.
6. Cunningham, W. (2009, February 14). Debt metaphor \[Video]. YouTube. https://www.youtube.com/watch?v=pqeJFYwnkjE — Transcript by June Kim and Lawrence Wang, CC BY 3.0: https://cmdev.com/papers/debt-metaphor/