All Decisions
April 2023 accepted

Treat Technical Debt as Business Risk

technical-debtrisk-managementengineering-strategycto
Context

One lesson from ILOVEGREENER was that technical debt is not just a code cleanliness issue. Some debt slows delivery, some creates operational risk, some blocks hiring and onboarding, and some damages the ability to respond to business opportunities.

Options Considered

Track Debt as Engineering Cleanup

Maintain a backlog of refactoring and cleanup tasks owned mostly by engineering

Pros
  • Simple
  • Engineer-friendly
  • Easy to capture
Cons
  • Hard for leadership to prioritise
  • Can look disconnected from business value
  • Often gets deferred

Schedule Dedicated Refactor Periods

Reserve time specifically for refactoring and debt reduction

Pros
  • Visible investment
  • Focused improvement
  • Good for morale
Cons
  • Can interrupt roadmap
  • May lack prioritisation
  • Not all debt is equally valuable to fix

Classify Debt by Business Risk

Prioritise debt based on impact to delivery speed, reliability, security, onboarding, and customer value

Pros
  • Better prioritisation
  • Easier executive communication
  • Connects engineering to business outcomes
Cons
  • Requires assessment discipline
  • Not every cleanup gets prioritised
  • Needs regular review
Decision

Chose to classify technical debt by business risk. In my current CTO role, I frame technical debt in terms of what it prevents, delays, or exposes the business to, rather than treating all refactoring as equal.

Consequences
Dec 2020

Some technical debt was invisible until it slowed down later changes and made the product harder to adapt

negative
Apr 2021

Because the debt was not framed as business risk early enough, it was harder to prioritise against visible feature work

negative
Jul 2023

Technical debt conversations later became easier to connect to delivery, reliability, and security

positive
Jun 2024

Engineering investment became easier to justify to non-technical stakeholders

positive