Technical Debt Triage: How Mid-Market Owners and Operators Decide What to Fix, Fund, or Leave Alone

Technical Debt Triage: How Mid-Market Owners and Operators Decide What to Fix, Fund, or Leave Alone

2026-10-21

The takeaway: Technical debt triage beats a big rewrite. Most companies don’t need to pay off all their tech debt, and shouldn’t try. List it system by system, price the “interest” each one charges you every month, fix the few systems that cost the most, and leave the cheap stuff alone on purpose.

What technical debt actually is

The debt metaphor goes back to a March 26, 1992 experience report by software developer Ward Cunningham on his team’s WyCash portfolio system: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.” The catch: “Every minute spent on not-quite-right code counts as interest on that debt” (Cunningham, 1992).

McKinsey splits it the same way a CFO would. The principal is all the work needed to modernize your technology: deferred upgrades, heavy customizations of packaged software, nonstandard data. The interest is the “complexity tax” every project pays today: fragile integrations, manual workarounds, data that has to be cleaned before anyone trusts it (McKinsey, October 6, 2020).

For a mid-market company, that looks like the ERP nobody dares upgrade, the spreadsheet that bridges two systems, and the integration only one contractor understands.

How big the bill gets

The best-known numbers come from big companies, so treat them as direction, not a benchmark. In a July 2020 McKinsey survey of 50 CIOs at financial-services and technology companies with more than $1 billion in revenue, CIOs said 10 to 20 percent of the technology budget meant for new products gets diverted to tech debt issues. They estimated tech debt at 20 to 40 percent of the value of their entire technology estate before depreciation (McKinsey, 2020).

McKinsey’s April 25, 2023 follow-up adds an observation from its client work: tech debt “is not spread evenly.” There is “always a set of ten to 15 assets that are responsible for the majority of the tech debt in an enterprise,” and “some tech debt is best left alone” (McKinsey, 2023). In a smaller company, we’d expect that list to be shorter still. That’s the whole case for triage.

Step 1: List the debt by system, not by complaint

Make one row per system or integration: what it does, who owns it, what breaks, and what workarounds people use. Include the bridging spreadsheets and the manual re-keying. Those count.

Look hardest at structure. A Carnegie Mellon Software Engineering Institute (SEI) survey of 1,831 participants, mostly engineers and architects on long-lived projects at three large organizations, found architectural decisions were the most important source of technical debt. Of 544 who ranked 14 possible sources, 54% put “bad architecture choices” in their top three (SEI, August 30, 2015). Old data, big organizations, but the lesson travels: the expensive debt usually lives in how systems connect, not in one ugly screen.

Step 2: Price the interest in plain numbers

For each row, estimate:

  • Staff hours lost per month to workarounds and fixes
  • Outages or errors in the past year, and what they cost
  • Projects delayed or blocked because “that system can’t do it”
  • Security exposure, like software the vendor no longer supports

Rough numbers are fine. You’re ranking, not auditing.

Step 3: Sort into four buckets

  • Fix now: high interest and it touches revenue, customers, or security.
  • Pay down steadily: real interest, but it can be chipped away.
  • Leave alone: low interest. Martin Fowler, chief scientist at Thoughtworks, notes that debt in “a rarely touched part of the code-base” may not be worth paying down if the interest is small (Fowler, October 14, 2009).
  • Retire or replace: the system costs more to carry than to swap. McKinsey calls these “bankrupt” areas and treats a rebuild as a last resort (McKinsey, 2020).

Step 4: Budget it steadily, not as a megaproject

McKinsey advises against “a big-bang approach,” recommending a portion of the IT budget earmarked for paying down debt “consistently, predictably” (McKinsey, 2020). Its 2023 piece adds that carving out a percentage alone “is insufficient.” Tie each dollar to a specific result, like better resiliency or new revenue (McKinsey, 2023).

Step 5: Stop taking on reckless debt

Fowler separates prudent debt (a deliberate shortcut to hit a date) from reckless debt (a mess made from not knowing better, or from rushing) (Fowler, 2009). Shortcuts are fine when they’re decisions. So make them decisions: every one gets a named owner, a written reason, and a payback date. McKinsey describes one company that required CEO approval for any tech debt exception (McKinsey, 2023). You may not need to go that far. You do need a list.

Four questions for your next leadership meeting

  1. Which three systems cost us the most staff time in workarounds?
  2. Which project got delayed this year because of an old system?
  3. Which shortcuts did we take on purpose, and who owns paying them back?
  4. What are we deliberately leaving alone, and why?

Where outside help fits

Architecture reviews, build vs. buy decisions with cost and risk side by side, and a 12-month IT roadmap and budget the CFO can read are all part of Yellow Coop’s work (what we do). That comes as virtual advisory hours or fractional leadership at 1 to 4 days a week (how we engage). If your tech debt list lives in one developer’s head, book a call.

Sources