By Seth Crosby, Structured Enterprise Services Sr. Consulting Engineer —

“Tech debt” has been bandied about in IT-infrastructure conversations for over 20 years, but without much clear definition. I’d be willing to bet that you’ve heard it thrown around and questionably used to elicit fear of some hidden force of reckoning looming over your IT practice.

Our goal today is to clarify the term, spotlight its usefulness as an intelligible concept, and lead you to the conclusion that your tech debt might be worth quantifying clearly, not left to lurk around in the shadows. Let me review some of the ways I’ve seen it show up with a hypothetical conversation. 

A CIO walks into an informal meeting (door open) with his IT Director. Meanwhile, the IT Manager is working nearby and sitting within earshot.

CIO: “We’ve got backing for a new project, and I’ve got confirmation of available budget. Feasibility studies need to confirm, and I need your help with the technical side of feasibility.”
IT Director: “This is out of the blue. Shouldn’t we deal with our tech debt before we commit to this new initiative?”
CIO: “You sound like you’ve got some negative tech debt in mind. What would you like to redress?”

IT Manager: <sitting near the open door> “How about we start by refreshing our old servers? They were supposed to be replaced 2 years ago.”
IT Director: <rises to close the door> “We do need new servers, but they’re still under warranty. I think we need to look at the software we purchased last year. We only rolled out 25% of its features and no one uses it. The need still exists, how about we start there?”

CIO: <working to remain objective and reasonable> “I understand that software never got fully deployed, and your team wants servers, but “Project Johnny-Utah” is going to change the direction on the ways we do the business of IT. That said, you grabbed my attention with the point about technical debt. How much time would it take you to quantify that?”
IT Director: <sighs, blinks a couple times> “Well, we should start looking at our documentation. That would help us go end-to-end with an analysis.”
CIO: “Do you think your documentation has what you need to get a good snapshot?”
IT Director: “Honestly, I don’t think so. Our documentation really needs a major update and keeps leading our engineers wrong when they need it most. But maybe we can start there.”

This fabricated conversation is hitting a few common tensions:

1) Tech debt really is quantifiable even if many practitioners don’t know where to start.

2) Aged (but supported) assets ≠ tech debt. Many people think the debt is money that wasn’t spent when originally planned and has now come due, but that’s deferred spending.  

3) Shelfware ≠ tech debt. Even if the sunk cost of that license and failed deployment project hasn’t helped the business move forward, that’s shelfware.

4) General documentation isn’t likely to help you comprehensively quantify the tech debt. In fact, it might be a form of debt.

5) Tech debt is treated like “he who shall not be named,” and is considered all bad by some. In truth, it has a place.

The Tech Debt Origin Story

The concept of tech debt comes from the early days of software development and was first named by Ward Cunningham in 1992. Working on financial software at the time, Cunningham coined the metaphor specifically to explain refactoring a financial systems application, and the financial services tie-in helped cement the analogy for his finance managers.

He observed that “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… Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load.” [i]

Many things have changed in 34 years, but Cunningham’s metaphor is still relevant — not only in software development but across the whole IT data estate.[ii] Here are the essential parts to modern tech debt:

1. Has an artifact or asset attached – this is a piece of code, software, hardware configuration, or a platform solution.
2. Expediency motivated a shortcut instead of aligning to ideal business standards.
3. Principal – the debt must be measurable, and the measurement is the level of effort or cost of the remediation. Scope the remediation, and you know the principal of the debt.
4. Interest is being generated right now. There is work today that is slower, less efficient, and costlier to the organization than if the debt was paid. This slowdown or inefficiency is the interest. Paying interest burns time that could have gone toward paying the debt, or better yet, driving the business forward.

Working toward a definition and then how we can add it all up, let’s look at what tech debt is not.

• Legacy Hardware or Software: An old mainframe or legacy server that is still well supported and functional is not tech debt.
• Shelfware: Software, services or features you purchased but have not implemented are not tech debt, even if they might help the organization.
• On-premises data center: There’s a place for an on-premises data center, and there’s a place for cloud-hosted workloads. On-premises does not equal debt any more than cloud-hosted equals money in the bank. Ask any CFO.
• Over-provisioned cloud resources: One of the hidden costs of the cloud is when resources are not right sized, but that’s not tech debt, that’s just inefficiency.
• Anything that a hyperscale cloud provider is trying to migrate you out of: OK, this is a little tongue-in-cheek, but — seriously — don’t let “tech debt” language scare you into an ill-informed decision. Be sure to properly calculate the costs of both staying with traditional technology or going with a new, modern approach.

Definitions: Ackchyually…

If you know the meme, you know where I’m going. My point isn’t to make you the smarty pants in the room. The one who has a better definition than anyone else, ready to drop the truth bomb that no one can comprehend. When comprehensibly defined, tech debt is a useful construct because it helps move your decision making from “I hope” to “I’ve calculated.” Let’s look at a few options for definitions.

McKinsey & Company defined it this way in 2020:
“[Technical debt is] the ‘tax’ a company pays on any development to remediate immature or substandard technology choices… a degree of tech debt is an unavoidable cost of doing business, and it needs to be managed appropriately to ensure an organization’s long-term viability.”[iii]

You should see the four elements right in that definition:

1. Asset or Artifact: “any development”
2. Expedient Decision or Shortcut: “immature or substandard technology choices”
3. Principal + interest: tax
4. Principal: [paydown] “managed appropriately”

Personally, I prefer something a little more succinct:
Tech Debt is future cost created when an expedient technology choice trades short-term results for long-term value. Subsequent changes become more costly unless they are paying down the debt.

Simpler yet:

Tech Debt is the cost you pay for calculated shortcuts. Improve those shortcuts soon and you pay less interest.

Here’s a simple example, simplistic for the sake of making the point. A new server is being added to the data center to help shoulder the load of a cluster that is beyond target capacity.

Note this last bit — tech debt likes to hide. It’s notoriously difficult to keep documented over time, and it’s easy to miss. Patching a 12-host cluster, engineers might notice that only 11 hosts got patched, but they also might miss the straggler. Even when the interest itself keeps taking your resources’ time and attention, the source of the problem — the tech debt’s principal — is hiding in the shadows. (This is where a senior operations engineer can really prove their worth.)

Crushing Some Dreams (But Enabling Others)

What’s surprising to many is that zero tech debt is neither achievable nor desirable, so just strike “tech debt free” from your dreams. The expediency that causes tech debt is actually one thing keeping the organization moving forward with the velocity required to achieve financial objectives.

Researchers not only acknowledge this, but encourage the appropriate use of tech debt.[iv] Forrester Research advocates that a 20% portfolio spend on tech debt paydown is reasonable.[v]  Manageable, well-documented tech debt is what you’re after. You want to be able to explain calculated decisions, you need a plan for managing the debt and continuing business velocity, and it’s all a justified part of accelerating the business.[vi] The citations and references here mostly point to the world of software engineering, but these same principles can apply to the management of IT at large.

McKinsey’s 2020 survey of 50 large-cap CIOs cited that tech debt accounts for 20%-40% of the value of the tech estate. In 2023 McKinsey updated their survey and stated that tech debt is roughly 40% of the IT balance sheet.[vii] CISQ’s 2022 report: Cost of Poor-Quality Software in the US estimated $1.52 trillion had been accumulated in software tech debt in the US alone.[viii] Gartner estimates 25% of engineering time and budget goes to managing technical debt.[ix] [x] In each of those samples, it’s safe to assume that the interest is getting paid more often than the principal. Otherwise, those trends would move down.

Adding Up the Liabilities Beyond Dollars and Cents

So how do we navigate a path forward? If you’re expecting a single formula that will generate one big, beautiful number (“$X is our total tech debt”) set that expectation aside for a moment. That single number quantification might be achieved (with some margin of error), but it is not all that helpful. And practically, that big number can cause unhelpful distress because the meaning isn’t apparent. It just looks really bad.

There’s a better way to understand the data, and that approach also gives you a path toward eliminating negative debt and better explaining good debt. Organizations that get this right pick a small number of defensible metrics and report those consistently managing them down to desired levels.

There are three views on which to focus with a metric attached to each: Financial View, Capacity View, and Risk View. To forecast progress, it is helpful to have a fourth Funding Benchmark. This benchmark is the debt paydown allocation. In other words, what part of your IT spending will go to paying down the principal, not just keeping up on interest?

Here’s what a regular report card might look like with action items included:

Let’s break down the views and action items with a little more detail.

Financial view: Ideally, you want to use KTLO or Run/Grow/Transform tools, but they aren’t necessary. They’re also expensive in time and consulting to really nail. Building a debt register is the universally available substitute. It doesn’t require a TBM platform, an APM tool, or finance instrumentation. It requires a spreadsheet, a few hours from architects and tech leads, and the discipline to keep the fields populated. The output is a defensible range, which is what you want since exact estimates of remediation cost are almost always false precision.

Capacity view: Operational time spent servicing debt. The most direct measure is how much of the infrastructure team’s week is consumed by the accumulated friction of the estate rather than new capability. This can be a simple one-question monthly survey to engineers: “How much of your average week is spent working around or correcting tech debt?” IMPORTANT: Be sure to clearly define debt for the engineers.

The signals an infrastructure leader can track without new tooling:

• Provisioning time for a new workload,
• Mean time to recover from incidents or close tickets,
• Share of changes requiring manual intervention,
• The percentage of capacity consumed by unplanned work (a concept The Phoenix Project identifies as the operational signature of unpaid debt.)[xi][xii]

Risk view: Documentation debt is a risk-view item, not a capacity-view item, because its cost is contingent, i.e., you don’t pay until something breaks or a key person leaves. The “single-point-of-failure documentation” line captures both undocumented systems and systems where only one person knows how they work. This is what practitioners call “bus factor of 1.” Build an aging register listing Security, EOL, audit findings, and documentation debt. This will make troubleshooting risk visible to executives in the same units as the other liabilities.

Funding benchmark. Kept as the forward-looking commitment. The other three views measure the current state; this column is the only one that commits to action.

The End of the Matter…

It is rare that any organization can fully track its tech debt, or ever achieve “I’m tech debt free!” status.  (Dave Ramsey may cry.) However, when you set up simple frameworks for how to manage tech debt, two things happen. First, you set the posture for what your organization does when encountering a surprise area of debt. Second, you will start to get a better picture of what technology-related slowdowns are holding your organization back from fulfilling its goals.

The big idea is this: measurement is achievable without colossal effort and the payoff for trying is organizationally transformative – in efficiency, clear thinking, morale, risk reduction, and hard dollars.

At Structured, I work with a team of senior engineers who are highly experienced at helping identify and eliminate tech debt principal. We spot the patterns of inefficiencies (debt’s interest) and help manage those by proactively paying down the principal. We’ve built this into a focused practice called Enterprise Platform Managed Services (EPMS) to help you eliminate the worst of your tech debt and optimize your organization’s capacity for speed and agility.

[i] Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ’92 Experience Report. http://c2.com/doc/oopsla92.html

[ii] Further reading: Cunningham, W. (2009). Ward Explains Debt Metaphor [Video]. Transcript: http://wiki.c2.com/?WardExplainsDebtMetaphor

[iii] Dalal, V., Krishnakanthan, K., Münstermann, B., & Patenge, R. (2020, October 6). Tech debt: Reclaiming tech equity. McKinsey & Company.

[iv] Gartner. (2024). Optimize Costs and Value by Guiding Technical Debt Deferral. Gartner Research, document G00807234.

[v] Betz, C. (2024). Technical Debt By A Thousand Cuts. Forrester Research. https://www.forrester.com/blogs/technical-debt-by-a-thousand-cuts/

[vi] Ozkaya, I. (2011, May 2). Enabling Agility by Strategically Managing Architectural Technical Debt. Carnegie Mellon University Software Engineering Institute (SEI) Insights blog. https://www.sei.cmu.edu/blog/enabling-agility-by-strategically-managing-architectural-technical-debt/

[vii] McKinsey & Company. (2023). Breaking technical debt’s vicious cycle to modernize your business. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business

[viii] Krasner, H. (2022). The Cost of Poor Software Quality in the US: A 2022 Report. CISQ. https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/

[ix] Friedman, B. (2025, June 18). Tech debt, AI, and the future of software engineering: Lessons from GartnerAPPS 2025. Moderne. https://www.moderne.ai/blog/gartner-application-innovation-business-summit-2025-recap

[x] Further reading: Gartner. Infrastructure and Operations Leaders: Technical Debt.

[xi] Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. IT Revolution Press.

[xii] Further reading: Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). Site Reliability Engineering: How Google Runs Production Systems, Chapter 5: “Eliminating Toil.” O’Reilly Media.

If you need help harnessing the principal on your tech debt and reducing the interest, contact your Structured account manager today or email info@structured.com. We’re here to help!

About the Author

Seth Crosby is an Enterprise Services Senior Consulting Engineer with more than 20 years’ experience spanning the full technology endgame, from infrastructure to data systems to business outcomes.

An early adopter of virtualization technologies and a practitioner in the Web 2.0 and early container application space, Seth brings a rare perspective that pairs deep application development and data systems experience with enterprise infrastructure expertise. He holds multiple iterations of VMware’s core certifications across the SDDC, Network Virtualization and Security, and Desktop Virtualization tracks, most recently in VCF, and has led several cybersecurity incident recovery efforts that restored critical operations under pressure.

Seth’s full-stack fluency — from platform architecture through data systems to the business questions they serve — allows him to help clients connect technology decisions to measurable outcomes. Whether the workload lives in a private datacenter, the public cloud, or both, his end-to-end perspective puts clients on stronger footing to secure and deliver the data that drives their business.