McKinsey: Companies Pay 10-20% More Per Project Due to Tech Debt

[finance_carlos]

I spend my days building financial models and forecasting engineering costs. One of the hardest things to model is technical debt.

Then I found the McKinsey research, and suddenly I had numbers to work with.

The McKinsey Numbers

From a survey of 50 CIOs at financial services and tech companies (all with $1B+ revenues):

• 10-20% of the technology budget dedicated to new products is actually diverted to resolving tech debt issues
• Tech debt amounts to 20-40% of the entire technology estate value before depreciation
• 30% of CIOs believe more than 20% of their “new product” budget is actually going to tech debt

Let me translate that into finance terms:

If you’re budgeting $10M for new product development, $1-2M is actually going toward fixing old problems, not building new value. And that’s the optimistic scenario.

Why Finance People Should Care

I’ve seen engineering teams ask for “refactoring time” and get rejected because they can’t quantify the business case. Here’s the business case:

The Productivity Tax

According to a Stripe study, developers waste approximately 33% of their time dealing with technical debt and maintenance. CodeScene puts it even higher - up to 42% of developer time.

Let’s do the math on a 20-person engineering team at $200K fully-loaded cost per engineer:

• Team cost: $4M/year
• 33% productivity loss: $1.32M/year in wasted capacity
• That’s capacity you’re paying for but not getting

The Velocity Penalty

McKinsey found that organizations with high technical debt:

• Spend 40% more on maintenance costs
• Deliver new features 25-50% slower than competitors

If you’re losing 6-12 months on a major product launch because of tech debt, that’s not an engineering problem. That’s a market share problem.

The Quality Multiplier

High-debt codebases experience 2-3x more production bugs. Testing cycles expand by 30-50% as QA teams verify both new functionality and potential regressions.

More bugs = more support costs = more engineering time on fixes = less time on features.

It compounds.

Why This Is Hard to Model

Here’s my challenge as a finance leader: tech debt doesn’t show up as a line item.

Nobody writes “Tech Debt Resolution: $2M” in the budget. Instead, it appears as:

• Projects taking 30% longer than estimated
• Higher-than-expected maintenance spend
• “Unexpected” production incidents
• Engineers asking for more headcount despite constant hiring

If you don’t explicitly track tech debt, you just see “engineering is always behind” without understanding why.

What I’ve Started Doing

At my company, we’ve started quantifying tech debt in business terms:

1. Incident cost tracking: Every production incident gets a dollar cost (engineering time + support time + revenue impact)

2. Velocity benchmarking: We track story points per engineer over time. When it starts declining, that’s a tech debt signal.

3. “Tax rate” estimation: I now build a 15% tech debt tax into all engineering forecasts. It’s not perfect, but it’s better than pretending it’s zero.

4. Refactoring ROI models: When engineering proposes a refactoring project, we model it like any capital investment: cost now vs. productivity gain over time.

Questions for This Community

1. How do you communicate tech debt costs to leadership? What frameworks or metrics work?

2. Do you explicitly budget for tech debt reduction? Or does it just come out of “new development” capacity?

3. For engineering leaders: What metrics would help you make the business case for addressing tech debt?

I’m convinced tech debt is one of the most underappreciated drags on company performance. But we can’t fix what we can’t measure.

[cto_michelle]

Carlos, this is the framing engineering leaders have been trying to articulate for years. Having a finance leader put numbers to it is incredibly valuable.

On your “15% tax rate” estimation:

This is directionally correct but probably conservative. In my experience, the tax rate varies wildly based on codebase age and previous underinvestment:

• Well-maintained codebase (< 5 years, regular refactoring): 10-15% tax rate
• Moderately neglected (5-10 years, sporadic refactoring): 20-30% tax rate
• Legacy systems (10+ years, minimal investment): 40-60% tax rate

The teams I’ve seen with 60% tax rates are effectively in maintenance mode - they’re paying so much interest on past decisions that they can barely ship new features.

The number that convinced my board:

I once modeled what it would cost to keep our main platform functional for 3 more years with no refactoring vs. an 18-month modernization investment.

• Do nothing: $12M over 3 years (increasing maintenance, slower velocity, incidents)
• Invest now: $4M modernization + $6M over 3 years (reduced maintenance, restored velocity)

The modernization paid for itself in 18 months. But we only got buy-in because I framed it as a financial investment with a measurable return, not as “engineering wants to rewrite things.”

What metrics I track:

1. Change Failure Rate: What % of deployments cause incidents? Rising rate = accumulating debt.
2. Lead Time for Changes: How long from code commit to production? Increasing time = debt friction.
3. Mean Time to Recovery: How long to fix production issues? Longer MTTR often signals architectural problems.
4. Ratio of planned vs. unplanned work: If more than 30% of sprints go to unplanned work, you have a debt problem.

These all translate to business impact if you attach dollar values to them.

[eng_director_luis]

This thread is giving me language I’ve been missing.

The “projects take 30% longer than estimated” observation:

This is exactly right, and it’s how tech debt hides in plain sight. At my previous company, we had a running joke that all estimates needed to be multiplied by 1.5x.

What we didn’t realize was that 1.5x wasn’t bad estimation. It was accurate estimation plus hidden tech debt costs. We were paying a 50% tax on every project.

On explicit budgeting for tech debt:

We now allocate 20% of each sprint to “platform health” work. Not negotiable. Leadership initially pushed back, but we ran an experiment:

• Team A: 100% feature work for 6 months
• Team B: 80% features, 20% platform health for 6 months

After 6 months:

• Team A had shipped 10% more features… but velocity was declining
• Team B had shipped fewer features but maintained velocity
• By month 9, Team B was actually ahead on total feature output

The compound effect of not paying down debt is brutal. Team A spent month 7-9 firefighting what they’d neglected.

What convinced my leadership:

I stopped talking about “refactoring” and started talking about “reliability investment.”

Same work. Different framing.

“Refactoring” sounds like engineering wants to rewrite things for fun.
“Reliability investment” sounds like reducing risk and improving uptime.

One gets rejected. The other gets funded.

The hardest part:

@cto_michelle’s point about metrics is key. The challenge is that tech debt benefits are counterfactual - you’re measuring incidents that didn’t happen, delays that didn’t occur.

We solved this by tracking velocity trends over time. When velocity starts declining despite stable headcount, that’s the tech debt signal. When we invest in platform health and velocity recovers, that’s the ROI.

[alex_infrastructure]

I want to add a perspective on where tech debt costs are highest but least visible: AI/ML infrastructure.

The new debt category nobody’s tracking:

At my company, we’re accumulating ML-specific tech debt faster than we’re paying it down:

• Model versioning chaos: We have 15 models in production, each trained on different data pipelines. Updating the underlying data requires touching 15 separate systems.

• Prompt debt: We have hundreds of prompts across different services. Nobody knows which ones are still optimal. Updating them is a manual archaeology project.

• Inference cost debt: We optimized for speed-to-market, not cost efficiency. Now we’re paying 3-4x what we should for inference because refactoring the pipeline would take 3 months.

The AI multiplier on traditional debt:

Traditional tech debt makes code harder to change. ML/AI debt makes code harder to change and more expensive to run.

Every week we don’t optimize our inference pipeline, we pay an additional $20K in cloud costs. That’s $1M/year in “debt interest” - real dollars, not just engineering time.

What I’d add to Carlos’s model:

Track infrastructure cost per unit as a debt indicator. For AI companies, this is often more meaningful than developer productivity metrics.

If your cost-per-inference is increasing over time despite stable workloads, you’re accumulating architectural debt in your ML pipeline.

We now review infrastructure unit costs monthly alongside velocity metrics. When unit costs rise without a corresponding increase in capability, that’s a red flag that debt is accumulating.

The biggest mistake I’ve seen:

Teams treat ML infrastructure as “special” and exempt from normal debt management. “We’ll optimize later when we scale.”

But ML debt compounds faster than traditional debt because you’re paying in both engineering time and runtime costs. “Later” is already costing you money.