The Loan Nobody Remembers Taking Out

There is a sentence that gets said in every growing company, and it always sounds responsible.

"Let us just ship it now and fix it properly later."

It sounds like pragmatism. Like a team making a smart call under pressure, choosing momentum over perfection. And sometimes it is exactly that. But here is what almost nobody in the room understands in the moment. That sentence is not a decision to move fast. It is a loan application. And the loan gets approved instantly, every single time, at an interest rate nobody bothered to read.

The technical name for it is technical debt, which is a shame, because the word technical makes owners assume it is an engineering concern they can safely ignore. It is not. It is one of the most financial things in your entire business. It just never shows up on a statement.

Here is how the interest gets paid. Every shortcut, every later, every quick fix that quietly became permanent, makes the next change a little harder. So your team spends more and more of its time not building new things, but working around the old shortcuts. The research on this is remarkably consistent. Developers spend around a third of their working week, roughly 13 of 40 hours, just servicing technical debt rather than building anything new (https://technicaldebtcost.com/productivity). McKinsey puts the total weight of it at 20 to 40 percent of the entire value of a company's technology estate, with a meaningful slice of every new project budget quietly diverted to servicing old debt before a single new thing gets built (https://fullscale.io/blog/technical-debt-quantification-financial-analysis/).

Read that as an owner, not as an engineer. You think you have a team of six. If a third of their week goes to interest, you effectively have a team of four, and you are paying for six.

And here is the part that makes debt so dangerous. It compounds. It gets more expensive over time, never less. A shortcut that would take one week to fix today can take three months to fix in two years, because in the meantime you built ten more things on top of it, and now all of them have to be unwound just to reach the original problem (https://www.classicinformatics.com/blog/technical-debt-the-real-cost-and-how-to-reduce-it).

I saw this described perfectly in a case that stuck with me. A logistics company had an order system built back when they ran eight trucks. Years later, running sixty, they went to add a routine new feature. It was estimated at six weeks. It took fourteen, because the foundation had been built for a company a fraction of their size, and every step forward meant fighting decisions made years earlier by people solving a much smaller problem (https://bitvea.com/en/blog/true-cost-of-technical-debt). Nobody did anything wrong. The shortcuts made complete sense in the year they were taken. They just never stopped charging interest.

Here is the reframe that matters most. The debt did not accumulate in the code. It accumulated in the decisions. The deadline you approved. The roadmap that left no room to go back and clean up. The dozen reasonable we will deal with it laters, each one sensible on its own, that added up to a balance nobody is tracking and everybody is paying.

And occasionally, the whole bill comes due at once. Southwest Airlines lost more than a billion dollars in 2022 when an aging scheduling system, deferred and patched for years, finally buckled under a winter storm and stranded the airline for days (https://bitvea.com/en/blog/true-cost-of-technical-debt). That is what deferred maintenance looks like when it stops being a slow leak and becomes a flood. It almost never announces the date in advance.

When we sit down with a company at Cause of a Kind, one of the first things we try to find is not what they want to build. It is how much of their team's week is already gone before anyone builds anything. How many hours of every day are spent paying interest on decisions made years ago. That number is usually a shock, and it is usually the most honest financial figure in the whole business.

So here is the wisdom, and it reaches far past software.

Speed you cannot sustain is not speed. It is borrowing. There is nothing wrong with taking on debt deliberately, in code or in life, as long as you know that you did it and you have a plan to pay it down. The real danger is the debt you took without noticing, the balance that grows in the dark while you keep making minimum payments in the form of your best people's time. Everyone carries some. The winners are simply the ones who know their number.

If your team keeps saying that a small change will take far longer than it should, and you cannot understand why something so simple has become so hard, you already have your answer.

That is not slowness.

That is interest, and it has been compounding for years.