Technical Debt Is a Business Decision

I was in a board meeting last year when a board member asked me a question I had been dreading: "Why is feature delivery slowing down when we have more engineers than ever?"

The honest answer was technical debt. But I had made a critical mistake — I had been talking about technical debt as an engineering problem using engineering language. Words like "refactoring," "legacy code," and "architecture migration" meant nothing to a room full of business leaders. They heard "the engineers want to rewrite things for fun instead of building features."

That board meeting was a turning point. I realized that the entire way our industry talks about technical debt is wrong. We frame it as a failure — something that happened because engineers were sloppy or leadership did not care about quality. That framing is not just inaccurate; it actively prevents the strategic management of technical debt because it makes everyone defensive.

Technical debt is not a moral failing. It is a business decision. And like all business decisions, it should be made deliberately, quantified rigorously, and communicated clearly.

Reframing the Metaphor

Ward Cunningham, who coined the term "technical debt," was explicit that the metaphor was about financial leverage, not about sloppy code. Just as a business takes on financial debt to move faster — opening a credit line, issuing bonds, taking a loan — an engineering team takes on technical debt to deliver value sooner.

Financial debt is not inherently bad. It is a tool. A startup that takes on debt to capture a market window is making a rational decision. A company that takes on debt without understanding the interest payments is making a reckless one.

Technical debt works the same way. The problem is not that it exists. The problem is that most organizations accumulate it unconsciously, never measure the interest, and then act surprised when it cripples their velocity.

How We Quantify Technical Debt

You cannot manage what you cannot measure. But measuring technical debt is notoriously difficult because it manifests as friction rather than failure. Features take longer. Bugs are harder to trace. Onboarding is slower. These effects are real but diffuse.

We developed a measurement approach that, while imperfect, gives us a usable signal.

The Friction Tax

Every quarter, we survey our engineering teams with a simple question: "For each major area of the codebase, what percentage of your time is spent working around limitations of the existing implementation rather than building new functionality?"

The responses are anonymous and calibrated across teams. The aggregate number — what we call the "friction tax" — tells us what percentage of our engineering capacity is being consumed by existing technical debt.

When I joined, our friction tax was around 35%. That means for every three engineers we hired, one of them was effectively being absorbed by technical debt. That is a number a board member can understand, because it translates directly to cost.

Cost of Delay

For specific technical debt items, we estimate the cost of delay — what it costs us each month to not address this debt. This is expressed in engineering hours, incident frequency, or missed feature opportunities.

For example, we had an aging notification system that required manual intervention for every new notification type. Each new feature that needed notifications took an extra two weeks of engineering time. With our product roadmap calling for six new notification-dependent features in the next year, the cost of delay was roughly twelve engineer-weeks per year, or approximately the fully-loaded cost of a senior engineer.

When I presented that analysis to the leadership team, the decision to invest in rebuilding the notification system was obvious. It was not a technical argument — it was a return-on-investment calculation.

Incident Attribution

We tag every production incident with a root cause category, and one of those categories is "technical debt." Over a rolling twelve-month period, we track what percentage of incidents are attributable to known technical debt, what the mean time to recovery was for those incidents, and what the customer impact was.

This data is powerful in stakeholder conversations because it connects abstract "tech debt" to concrete business outcomes: downtime, customer complaints, and lost revenue.

The Technical Debt Portfolio

Once we could measure technical debt, we needed a framework for managing it. We borrowed a concept from finance: the portfolio approach.

We categorize all known technical debt into four quadrants.

Strategic Debt

This is debt we took on deliberately to capture a business opportunity. We chose the faster implementation knowing we would need to revisit it. Strategic debt is healthy when the business opportunity justified the trade-off and the debt is documented with a clear repayment plan.

Example: When we launched in a new market, we hardcoded several country-specific rules rather than building a flexible rules engine. This let us launch four months earlier. The debt was documented, the repayment was scheduled for the following quarter, and the business value of the early launch was quantifiable.

Incremental Debt

This is debt that accumulates gradually through hundreds of small decisions. No single commit introduced it, but over time the codebase drifted from its intended design. This is the most common type and the hardest to address because there is no single owner and no single fix.

We manage incremental debt through dedicated "improvement budgets." Each team allocates 15% of their sprint capacity to addressing incremental debt in the areas they work in most. This is not negotiable — it is built into our planning process. Skipping it to deliver features faster is borrowing from the future, and we treat it that way.

Inherited Debt

This is debt that exists in systems we acquired or dependencies we adopted. We did not create it, but we pay interest on it. Third-party libraries with poor APIs, acquired codebases with different conventions, or vendor systems with architectural limitations all fall into this category.

Inherited debt requires a different management strategy because the root cause is often outside our control. We manage it through abstraction layers that isolate the debt and limit its blast radius.

Toxic Debt

This is debt that is actively dangerous — security vulnerabilities, data integrity risks, or compliance gaps. Toxic debt gets immediate attention regardless of other priorities, because the interest rate is not measured in engineering hours but in existential risk.

We maintain a "toxic debt" dashboard that is reviewed weekly by the engineering leadership team. If something is on that dashboard for more than one sprint, it becomes the top priority.

Communicating to Stakeholders

The most important skill for a technical leader is translating technical debt into business language. Here is the framework I use in every stakeholder conversation.

Never say "we need to refactor." Stakeholders hear "engineers want to reorganize code for aesthetic reasons." Instead, say "we need to reduce the friction tax from 35% to 20%, which will effectively add the equivalent of X engineers to our capacity."

Always connect to business outcomes. "This technical debt causes approximately two production incidents per month, each costing us four hours of engineering time and impacting roughly Y customers." That is a sentence a CEO can act on.

Present options, not mandates. I never go to the leadership team and say "we must spend three months on technical debt." I present options: "Option A is to continue as-is, with an estimated friction tax increase from 35% to 40% over the next year. Option B is to invest one engineer-quarter now to reduce the friction tax to 25%. Option C is a larger investment of two engineer-quarters to reduce it to 15%. Here are the projected velocity implications of each." Let the business make the business decision.

Use the language of investment, not cleanup. "Technical debt reduction" sounds like janitorial work. "Infrastructure investment" sounds like strategic allocation. Frame your proposals as investments with expected returns, because that is exactly what they are.

The 15% Rule

After experimenting with various approaches, we settled on a simple policy: 15% of engineering capacity is always allocated to technical debt reduction. This is not a suggestion. It is a budget line item, just like infrastructure costs or security investments.

Fifteen percent is enough to keep the friction tax from growing while making gradual progress on the backlog. It is not enough to address major debt items, which require dedicated project funding. But it prevents the common failure mode where technical debt is deferred indefinitely because there is always a more urgent feature.

Some quarters, when we have a major debt item to address, we temporarily increase the allocation to 25% or even 40%. But we never go below 15%. The moment you start borrowing from the technical debt budget to hit a feature deadline, you have started a cycle that is very hard to break.

Strategic Debt as a Competitive Weapon

I want to end with a perspective that might seem surprising: technical debt, when managed well, is a competitive advantage.

The ability to deliberately take on technical debt and then reliably pay it down means you can move faster than competitors who either refuse to take on any debt (and ship too slowly) or take on debt recklessly (and eventually collapse under it).

Last year, a competitor announced a feature that we had not yet built. Our product team estimated it would take three months to build "the right way." I made a deliberate decision: build it in six weeks using a simplified architecture that would not scale beyond our current load. We documented the debt, scheduled the repayment, and shipped the feature before the competitor finished their launch marketing.

Three months later, we rebuilt the system properly. The total cost was higher than doing it right the first time, but the business value of being first to market more than justified it. That is strategic technical debt in action.

The key is the word "strategic." We knew what debt we were taking on, we knew the interest rate, and we had a repayment plan. That is the difference between leverage and recklessness.

The Bottom Line

Technical debt is not something that happens to you. It is something you choose. Every shortcut, every "we will fix it later," every "good enough for now" is a borrowing decision. The question is not whether to take on debt — every successful company does. The question is whether you are borrowing strategically or accidentally.

Measure your friction tax. Quantify the cost of delay. Present your stakeholders with investment options, not engineering complaints. Maintain a minimum allocation for debt reduction. And when you deliberately take on debt to capture an opportunity, document it and schedule the repayment.

Technical debt, managed as a business decision, is a tool. Technical debt, ignored as an engineering problem, is a slow-motion catastrophe. The difference is not technical. It is leadership.