(A previous version of this article originally appeared in Forbes.com on Oct 9, 2024.)
Tech Debt. Everyone has heard of the term, but what does it actually mean? Is it the result of bad code? Or is it a strategic decision that can make or break a company?
There’s often a lot of confusion around tech debt in organizations. In one of my previous roles at a major tech company, there was a top-down initiative from Engineering leadership to migrate from our Monolithic Ruby-on-Rails app to service-oriented architecture. Despite the mandate, it was clear product management leadership was not bought in on this initiative, which caused constant conflicts across engineering and product at various levels on prioritizing their roadmap.
This misalignment is common across tech companies. I’ve encountered everything from a sales leader asking “what percentage of our code is ‘good’?” to an engineer declaring “we cannot build this feature (that may help close a deal) because it will increase tech debt.”
A common misconception is that tech debt is a consequence of sloppy coding or bad decisions. This can’t be further from the truth: tech debt can be a deliberate and strategic choice. Think of it like a mortgage: while some mortgages may be poor financial choices, a mortgage itself is often the right decision for many.
So What is tech debt? First, let’s first define debt in general terms. According to Investopedia:
Debt is something, usually money, owed by one party to another. Debt is used by many individuals and companies to make large purchases that they could not afford under other circumstances. Unless a debt is forgiven by the lender, it must be paid back, typically with added interest.
Using a mortgage as an example: someone might borrow money to buy a home, and opt to take on debt because they lack liquid assets or prefer to invest those assets elsewhere (e.g., in the S&P 500). The decision to incur debt is deliberate, and for many, a smart financial move, homeownership when buying outright isn’t feasible for most. In fact, our tax system even incentivises it!
The same principle applies to tech debt. As a business, you might decide to capture some immediate value — such as pleasing a certain client — by consciously incurring tech debt, such as taking on an infrastructure shortcut. You then plan to repay that debt through future engineering efforts, such as executing a technical migration.
Like financial debt, tech debt has the same two key components: principal and repayment terms.
Let’s walk through an example. Earlier this year,my company identified tremendous business value in going-live with a particular customer as soon as possible. To meet the deadline, we patched and repurposed a few existing services to support the go-live, knowing that it would not be the right long-term solution due to the service’s inability to scale or extend for future use cases.
As a result, we would have to migrate from that existing service into a new one that is more flexible and scalable. To make matters more complicated, the more customers we added using the old service, the more effort it takes to then migrate all of the customers from the old service to the new service.
In this case, the principal — the initial cost of incurring tech debt — was the engineering effort it takes to migrate from the old service to the new one. The repayment depends on timing: if we migrated immediately after the first customer launch, then the repayment would be equal to the principal.
However, there could be business reasons for why we wanted to go live with a few more customers before prioritizing the migration, in which case, the repayment would be substantially larger. This is because as we add more customers into the old system, there would be a recurring cost of maintaining it and dealing with the loss in velocity, as well as increased cost later to migrate more deployments from the old service to the new service.
Ultimately, we determined that the best balance between business value of getting more customers live and engineering effort of the migration was to start the migration the following year.
To extend this analogy, imagine a group of people agreeing to purchase a house, but only a few of them are responsible for paying the mortgage. How would those few feel? Charlie Munger famously said, “Show me the incentives, and I’ll show you the outcome.”
This asymmetry is often at the heart of conflicts around tech debt. Business leaders might push for immediate value (e.g., closing a deal by cutting a few tech corners), while engineers are left with the burden of paying off that tech debt through future work. It’s no wonder friction between “business needs” and “tech debt” happens all the time.
In a future article, I will explore strategies to reduce this friction, aligning stakeholders on their incentives, and ultimately helping the company make more informed decisions when navigating tech debt.
For more musings on tech culture, organization building, and management, follow me on Twitter @kenk616.
