How Technical Debt Is Born
Technical debt is created through the following process, as I understand it:
- Code is written that enables the fastest possible validation of what the business needs
- That validation succeeds, and the code becomes valuable
- The business state changes, creating a gap between what the code can do and what the business now needs. This gap is technical debt.
So technical debt is also the delta Δ between the business and the codebase.
Like financial debt, this delta carries risk when it grows too large:
- Interest accrues in the form of cognitive load
- The greater the cognitive load, the more development speed and operational effort decline — exponentially
- When interest reaches a certain threshold, the system goes bankrupt, and the codebase can no longer support the business moving forward
In short, it becomes a fatal risk to the business.
Managing the Debt
Business management therefore requires: correctly detecting the delta called technical debt, repaying enough of it to keep it in control, and keeping Δ under control. And in my observation, this is the sense that business-side people most often lack.
There are only two ways to reduce Δ:
- Slow down business development that requires changes to the codebase
- Increase the speed of debt repayment
Good salespeople, BizDev professionals, and product managers can grow the business while managing both levers.
In a new business context, "being able to minimize Δ while discovering value" ≈ "being able to create an MVP and achieve PMF" — so the two are effectively synonymous.
Conversely, someone who exclusively uses "programming changes and development" as their tool for business growth, or who negotiates only on final deadlines without engaging with how the debt repayment works or how difficult it is — that person is arguably not a mature business professional in a software-centered business.
I don't have a clear organizational answer for breaking out of this. It's still an open question for me.
All of the above is my personal view.
