Most enterprise technology estates carry two very different kinds of weight. One was chosen. The other accumulated. Most organizations diagnose them, fund them, and explain them to the board as if they were the same thing, usually under the heading of tech debt, and that is a large part of why modernization programs stall. The distinction is not semantic. It determines whether a problem can be paid down on a schedule or has to be escaped all at once.

What tech debt actually means

Tech debt is a legitimate and useful term. It describes a deliberate shortcut, taken with management’s sign-off, for a concrete business reason: the budget is fixed or the deadline is immovable. Everyone involved knows it is not the right way to build the thing, and everyone accepts that it will cost more later. It sounds like this: “We can spend this much and we have to ship in two weeks, so we take the shortcut now and clean it up next quarter.”

That is a rational trade. It was chosen, it was approved, and, critically, it can be repaid. It can be scheduled, prioritized, and paid down like any other liability.

What is being carried under that label

Increasingly, “tech debt” is applied to something else entirely: the whole catalog of modernization needs. The mainframe. The on-premises estate. The first-generation cloud architecture that predates what the hyperscalers offer today. Integration layers built for a world without generative or agentic AI.

None of these were shortcuts. When the mainframe was purchased, it was expensive, state of the art, and the right decision. The decision was not wrong; time moved. Better options appeared that no one could have anticipated, and the pace of that change is now measured in months.

Different cause, different fix. Treat the two alike and you get the same disappointing result: a liability that never seems to get paid down, because it was never a liability in the first place.

Three kinds of weight

Looked at closely, the estate is carrying three distinct things, and only two of them are debt.

1. Tech debt is a deliberate, approved shortcut taken for a concrete business reason, time or money. It can be repaid.
2. Shadow tech debt is a shortcut taken without approval. It has to be found before it can be repaid. This is a more serious strategic problem than shadow IT, which is usually a small, practical workaround: a credit card charge for a quick cloud instance, a consumer-grade router because the approved one is a month out. Shadow IT rarely commits the enterprise to a large future expense. Shadow tech debt does. It is one person deciding that the company will pay for a corner cut a year from now, without the company knowing it agreed.
3. The third has no accepted name, which is part of the problem. It is the accumulated weight of legitimate decisions that time has overtaken. It was not incurred; it was earned, by systems that worked. It cannot be repaid, because there is no shortcut to undo. It can only be escaped. It behaves less like a debt than like gravity: a pull created by mass, exerted on everything, and no one’s fault.

We have taken to calling it:

Tech Gravity

The distinction in one line: you repay debt; you escape gravity.

A maritime image makes the difference concrete. Tech debt is an anchor: someone chose to drop it, and it can be raised. Shadow tech debt is an anchor dropped without telling the captain. Tech gravity is the weight of the ship itself. You cannot raise it. You can only generate enough thrust to leave.

Why the distinction matters

Three audiences pay the price when the categories collapse into one, and the true meaning is obfuscated behind one incomplete and inaccurate term.

The board

When every modernization need arrives labeled “tech debt,” the board hears a single, undifferentiated liability with no clear owner and no clear end.

Directors are trained to evaluate liabilities on three questions: (1) how large is it, (2) who is accountable for it, and (3) when will it be retired. Tech debt, as commonly presented, fails all three. The number grows every year, ownership is diffuse across IT and the business, and there is no visible retirement date because the category keeps absorbing new items: the mainframe this year, the first-generation cloud estate the next.

A board that hears the same label attached to a growing number, year after year, draws the reasonable conclusion that the problem is not being managed, but the truth is usually different: several problems are being managed at once, some of which can be paid down and one of which cannot, and the single label hides that. That is not persuasion; it is confusion. Boards support and fund what they understand and defer what they don’t. Separating the categories gives directors what they need: a repayable balance they can track toward zero, a governance gap they can assign, and a strategic commitment they can debate on its merits.

The CFO

A CFO can tell when three different problems show up under one label with one price attached, and the skepticism is well placed.

Finance leaders spend their careers detecting bundles – line items that combine things which should be evaluated separately – because bundles are where soft justifications hide. When “tech debt” arrives as a single ask, the CFO sees a cost with no natural ceiling, no way to distinguish the portion that should have been budgeted years ago from the portion that requires a new decision, and no way to test whether the number is right. The predictable response is to trim it, defer it, or ask for it to be re-justified next year, which is exactly how modernization ends up underfunded and stuck in orbit.

The failure is not the CFO’s. It is a presentation that invites the wrong question. Present clean categories, each with its own cause and its own remedy, and the conversation changes. Debt can be shown as a balance with a paydown schedule. Shadow debt can be shown as a control gap with a remediation plan. Gravity can be shown as a threshold, a level of commitment below which spending buys nothing durable. The question moves from “why is this so expensive?” to “which of these are we committing to?” That is a question a CFO can answer.

The vendors

A single label invites a single solution. When the buyer’s own vocabulary makes no distinction between a shortcut that can be repaid and an estate that has to be escaped, the vendor is under no obligation to make it either.

It becomes easy to sell a modernization program as if it were debt repayment – fixed scope, defined end state, predictable schedule – when the underlying problem is a threshold the program’s budget may never clear. The reverse happens too: debt cleanup gets repackaged as transformation, with a price to match. None of this requires bad faith. It requires only that the buyer’s categories be blurry enough for the vendor’s to fill the gap.

One-size-fits-all is the vendor’s preferred strategy because it moves the buyer from simple to simplistic: one program, one number, one story for the board. The defense is not distrust of vendors; it is precision. A buyer who can say “this portion is debt, and I want a paydown plan; this portion is gravity, and I want to know what escape actually requires” has changed the negotiation before it starts. Each problem now has to be priced on its own terms, and the buyer can see which is which.

The physics of getting out

If the weight behaves like gravity, the rest of the physics follows, and it describes what most CIOs already know from experience. These systems pull the enterprise, and its strategy, toward what has already been built and away from what needs to be built next. Three consequences fall out of that.

1. Tech gravity

…is the condition: the pull exerted by everything an organization has built- every system, integration, and decision that worked. The more you have built, the stronger the pull.

2. Operational orbit

…is the trap, and it is where most enterprises actually are. Not stuck on the ground, not free. Enough investment to keep things moving; not enough to change position. An orbit takes no decision to maintain, which is why organizations stay in one for years. Nor is it free. Satellites burn fuel just to hold position, and the IT run budget is the equivalent: money spent to stay exactly where you are.

3. Escape velocity

…is the threshold: the minimum investment and commitment required to break free for good. It is a threshold, not a slope. Half the required energy does not get you halfway out; it gets you a return trip. The physics is specific on this point. The speed needed to hold an orbit is roughly 70 percent of the speed needed to escape one, so an organization that funds 70 to 99 percent of what modernization actually requires does not get 70 to 99 percent of the result. It gets orbit. This is the case against modernization that is underfunded and re-justified every budget cycle.

4. Thrust capacity

…is what senior leadership is actually willing to commit: funding, talent, and sustained attention. Comparing thrust capacity to escape velocity is the diagnosis, and it produces three states. Below gravity, the business case never closes. Above gravity but below escape velocity, activity without progress. Above escape velocity, modernization that lands.

Three further rules follow, and each has an enterprise equivalent.

1. Gravity is strongest near the core and weakest at the edge. That is why edge modernizations succeed, core systems such as ERP, core banking, and the mainframe stall, and organizations mistake progress at the edge for progress at the core.
2. Escape velocity rises with mass. A larger, older, more successful enterprise needs more energy to escape than a smaller one. That is not an indictment; it is arithmetic. It is also why startups have escape velocity by default.
3. Nothing escapes on its own. Gravity does not let go. The energy has to come from outside the system, which in an enterprise means a decision.

The takeaway

An organization’s ability to derive value from its technology depends on whether its thrust capacity exceeds the escape velocity set by its tech gravity. Below that threshold, it stays in operational orbit, spending to hold position. Above it, every increment of surplus capacity reaches the frontier.

Tech debt is a shortcut someone chose, and it can be scheduled and repaid. Most of what enterprises are carrying today was never a shortcut. It is the weight of decisions that worked, and it yields to a different strategy: not repayment on a schedule, but a commitment large enough to clear the threshold. The first modernization decision is not which system to replace. It is recognizing which kind of weight you are carrying.