The innovation tax audit: Is your R&D actually just OpEx?

In the high-stakes world of enterprise technology, we are culturally conditioned to celebrate addition. We throw launch parties for platform modernizations, issue press releases for AI integrations and track delivery velocity as a proxy for progress. Roadmaps grow longer. Backlogs get fuller. Teams stay busy.

Yet in my work advising boards and executives on capital allocation, I have found that the most dangerous number in an IT organization is not how much you are building. It is how much you are refusing to retire.

I call this the innovation tax. It is the silent, compounding levy placed on engineering capacity by software assets that have outlived their economic utility. Unlike financial debt, which appears clearly on the balance sheet with a defined interest rate and maturity date, this tax hides in the margins of the P&L. It shows up as slower delivery, declining morale, rising operating expenses and an ever-present sense that, despite record effort, the organization is falling behind.

For CIOs attempting to position themselves as strategic business partners rather than delivery executives, this liability is existential. If you cannot explain where engineering capacity is being consumed, you cannot credibly argue for new investment.

The psychology of hoarding

To understand why this tax persists, we must look beyond the spreadsheet and look at the human brain. The barrier to decommissioning legacy software is rarely technical. It is emotional.

I experienced this firsthand during a portfolio review for a mid-sized logistics company. I had identified a legacy reporting module that cost $250,000 annually to maintain but was used by only three customers. The math was obvious. We should kill it.

I walked into the meeting expecting a quick approval. Instead, I faced a wall of emotional resistance. The VP of Sales argued that killing the feature would damage the relationship with those three customers. The Engineering Director, who had written the original code for that module a decade ago, argued that it was “stable core infrastructure” that shouldn’t be touched.

I realized in that moment that we weren’t debating economics. We were debating identity. Psychologists call this loss aversion. We feel the pain of losing something roughly twice as intensely as the pleasure of gaining something of equivalent value. When a product manager considers deleting a feature, they don’t see a gain in efficiency. They see a loss of optionality.

This is compounded by a deep-seated bias to overvalue things we created ourselves. That Engineering Director didn’t want to save the module because it generated value. He wanted to save it because it represented his contribution to the company’s history.

I eventually solved this not with logic but with process. I worked with the CTO to establish a quarterly “sunset committee,” an operational body with one KPI: code retirement. By formalizing asset destruction, we removed the emotional weight from the creators and placed it on a governance framework. In the efficiency economy, detachment is a competitive advantage.

The mechanics of carry cost

Consider the difference between a project and an asset. A project has a distinct end date. An asset has an indefinite carry cost.

I recently audited a portfolio for a logistics enterprise where leadership was baffled by their inability to ship new features. They were not suffering from a lack of talent but from asset congestion. Every feature they had shipped in the previous five years was still active and requiring security patching, infrastructure monitoring, compliance reviews and dependency updates.

This situation is often mislabeled as technical debt, implying a code-quality issue that can be resolved with refactoring. That framing is dangerously incomplete. This is a capital allocation problem. When you allow low-value assets to persist, you are effectively taxing every future initiative. New work must accommodate old assumptions that no longer serve the business.

Industry data supports this view. Gartner estimates that unmanaged technical debt and portfolio complexity can consume up to 35 percent of IT budgets, effectively crowding out investment in innovation. If a third of your technology spend is devoted to sustaining yesterday’s ideas, you are not underfunded. You are misallocated.

The zombie asset diagnostic

After seeing this pattern repeat across dozens of organizations, I developed a specific diagnostic to identify what I call “Zombie Assets.” These are features that are technically alive but functionally dead. They consume compute resources and engineering attention but generate zero marginal value.

I use a simple heuristic called the Rule of Two. When I audit a portfolio, I look for features that have not been touched by a user in two months or updated by a developer in two years. If a feature hits both markers, it is a candidate for the morgue.

I applied this Rule of Two at a healthcare SaaS company that was struggling with margin compression. We scanned their codebase and usage logs and found that nearly 22 percent of their features met the criteria. These weren’t obscure back-end scripts; they were customer-facing buttons and reports that had simply fallen out of fashion.

The engineering team was terrified to turn them off. They cited the “Sunk Cost Fallacy” in reverse, arguing that because they had spent millions building them, they had to keep them running “just in case.” To prove them wrong, we ran a “Scream Test.” We turned off the features in the staging environment and waited for someone to complain.

Silence.

We then turned them off in production. Still silence.

By decommissioning those zombie assets, we reclaimed 18 percent of the engineering team’s capacity in a single quarter. That capacity was immediately redeployed to a high-priority AI initiative that had been starved for resources. We didn’t need to hire more engineers. We just needed to stop maintaining the dead. This diagnostic is now the first step in every turnaround I lead.

The hidden talent drain

This compounding burden not only affects financial performance. It quietly destroys talent density. Top engineers want to work on meaningful problems. They want to build new capabilities, modernize systems and see their work drive measurable outcomes.

I recall a specific exit interview with a senior architect who was leaving a well-funded fintech startup. When I asked her why she was leaving, she didn’t mention money or culture. She said, “I spend 70 percent of my week patching a system that should have been turned off two years ago. I’m not an engineer anymore. I’m a curator.”

When most of an engineer’s time is spent patching brittle systems that exist solely because no one dares to retire them, disengagement follows. The cost of this churn is often invisible until it is too late. As top talent leaves, the remaining team becomes increasingly specialized in maintaining legacy systems and further cementing the status quo.

Research from McKinsey on developer velocity highlights that the top quartile of companies experience 4-5x faster revenue growth than their peers, largely because they minimize low-value toil. The correlation is clear. You cannot retain top talent if you treat them as museum curators for legacy code.

The innovation tax isn’t just a code problem; it’s a talent problem. The Audit Interview Protocol is designed to filter for “Capital Judgment”—ensuring you hire engineers who prioritize asset retirement and simplicity over blind code generation.

The portfolio surgeon’s playbook

Breaking this cycle requires governance rather than heroics. CIOs must institutionalize a governance of subtraction.

• Automatic sunsetting thresholds: Features should not live indefinitely by default. Adoption metrics must trigger impairment reviews automatically. When usage drops below a defined threshold, the burden of proof shifts. Product teams must justify continued investment by demonstrating positive margin contribution.
• Zero-sum roadmaps: In capital-constrained environments, complexity must be budgeted. Introducing new scope requires retiring equivalent legacy scope. This forces trade-offs before code is written, not years later.
• Maintenance margin reporting: CIOs should report the percentage of R&D spend devoted to defensive versus offensive work. Forrester research indicates that organizations allowing defensive spend to exceed 40 percent experience declining innovation velocity.

From code bloat to capital discipline

The innovation tax is not a failure of engineering. It is a failure of governance. Boards would never allow factories, real estate or inventory to remain on the books without periodic impairment testing. Software deserves the same discipline.

In the efficiency economy of 2026, leaders are remembered not for the volume of code they shipped but for the durability of the value they created. Sometimes the most profitable, strategic and courageous decision a CIO can make is to hit delete.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?