The quarterly planning meeting. The engineering lead presents a slide titled “Tech Debt Reduction.” It lists 15 items, ranging from “upgrade Node.js from 16 to 20” to “rewrite the payment service.” The total estimate is 18 engineering-months.

The product manager asks: “What’s the impact?”

The engineering lead says: “If we don’t do this, things will get worse.”

The product manager nods sympathetically. Then allocates zero capacity to tech debt.

This conversation happens every quarter at every company I’ve worked with. And it happens because engineers have turned “tech debt” into a catch-all label that means everything and communicates nothing. The term has become so overused that it’s lost its ability to convey urgency, risk, or business value.

What Tech Debt Actually Is

Ward Cunningham’s original metaphor was specific and deliberate: tech debt is a conscious decision to ship faster today knowing you’ll pay interest later. Like financial debt, it made strategic sense to take on — you needed to ship, you made an informed trade-off, and now you need to service the debt or pay it off.

The critical aspects of the original metaphor: the debt was deliberate, the consequences were understood, and the repayment was planned. Financial debt with these characteristics is manageable and often advisable — companies take on debt to fund growth all the time.

What engineers call “tech debt” today is usually one of these categories, and conflating them under a single label destroys the ability to communicate each one’s actual urgency:

Maintenance Work

Upgrading dependencies, updating frameworks, rotating certificates, patching security vulnerabilities, maintaining CI/CD pipelines, updating documentation. This isn’t debt — it’s routine operations. Every system requires maintenance, just like every building requires maintenance.

Calling maintenance work “tech debt” makes it sound optional — like a strategic choice that can be deferred. It’s not optional. Deferred maintenance isn’t debt; it’s neglect. Nobody calls changing the oil in their car “automotive debt” — it’s just maintenance. And when leadership hears maintenance described as “debt,” they file it under “nice to have” instead of “required to operate.”

What to call it instead: Operational maintenance. Frame it like building maintenance: “We need to update our Node.js runtime because the current version loses security support in 4 months. This is equivalent to maintaining fire suppression systems — not optional, not negotiable, not deferrable.”

Design Limitations

The architecture was designed for 1,000 users and now serves 100,000. The database schema was optimized for write-heavy workloads when the application was transactional, but the business has shifted to analytics-heavy access patterns. The API was designed for internal use and now has 50 external consumers.

These aren’t failures of past engineering judgment. They’re evidence of past engineering success — the product grew beyond what was originally anticipated. Presenting them as “debt” implies negligence when the accurate framing is “our architecture needs to evolve because the business has grown.”

What to call it instead: Scaling investment. “Our current architecture was designed for our 2022 scale. It handles our 2026 load, but it does so with degrading performance and increasing cost. Investing in architectural evolution will reduce our per-request infrastructure cost by 40% and eliminate the performance degradation our customers are experiencing.”

Unfamiliarity

“This code is hard to read” sometimes means exactly what it says — the code genuinely violates readability norms and lacks documentation. But it also frequently means “I didn’t write this code and I don’t understand the previous author’s patterns.” That’s a knowledge gap, not a debt.

The distinction matters because the solutions are completely different. A knowledge gap is solved by documentation, pair programming, and time. Genuine code quality issues are solved by refactoring. Conflating them under “tech debt” means that perfectly functional, well-designed code gets flagged for rewriting simply because the current team didn’t author it.

What to call it instead: Knowledge gap — if the code works but isn’t understood. Quality improvement — if the code genuinely violates maintainability standards. Each requires a different solution and a different investment case.

Actual Tech Debt

Deliberate shortcuts taken to meet a deadline, with known consequences and an implicit or explicit plan to address them. The team shipped the feature with hardcoded configurations because the feature flag system wasn’t ready. The data migration was done with a script that handles 95% of cases, and the remaining 5% are managed manually. The API returns more data than necessary because the filtering logic was descoped.

This is the only category that fits Cunningham’s original metaphor. It’s the only category where the financial debt analogy is accurate: a conscious borrowing against the future to achieve a present objective.

Why the Language Matters

When everything is “tech debt,” nothing is urgent. Leadership hears the phrase so often that it triggers an automatic response: “the engineers want to work on things that don’t ship features.” They mentally categorize the entire tech debt list as optional maintenance that can always wait one more quarter.

And they’re partially right — because the list includes things that genuinely can wait (upgrading a well-functioning framework version) alongside things that will cause production incidents if ignored (a known race condition in the payment processing pipeline) alongside things that are normal operational costs (certificate rotation).

By lumping these together, the engineering team has communicated that none of them are individually important enough to distinguish. Leadership responds rationally: they defer the entire list.

The irony is devastating: the most critical items on the tech debt list — the actual risks, the ticking time bombs — are deprioritized because they’re surrounded by items that genuinely can wait. The boy cried wolf, and now the wolves are eating the sheep.

The Better Framework

Stop using “tech debt” as a category. Start using a framework that communicates risk and value in terms that leadership evaluates every other investment with:

Risk Reduction

“If we don’t upgrade the database driver, we’ll lose security updates in 6 months. This creates compliance risk — our SOC 2 auditor flagged unsupported dependencies as a finding last year. The remediation takes 4 engineering-days now or 4 engineering-weeks under audit pressure.”

Now leadership understands the consequence in terms they manage daily: compliance risk, audit findings, and the cost multiplier of doing work under pressure versus proactively.

Capacity Investment

“If we improve our CI/CD pipeline, deploys drop from 45 minutes to 8 minutes. Over 40 deploys per month, that’s 24 engineering-hours recovered per month — equivalent to hiring an additional 15% engineer. The investment is 3 engineering-weeks.”

Now leadership sees the ROI in terms they understand: capacity gained versus capacity invested. A 3-week investment that yields 24 hours per month in recovered capacity has a 5-month payback period. That’s a better ROI than most feature investments.

Revenue Protection

“The payment service handles $2M per day. Its current error rate is 0.3%, costing approximately $180K per month in failed transactions. A refactoring of the retry logic and error handling would reduce this to 0.01%, recovering approximately $175K per month. The investment is 6 engineering-weeks.”

Now leadership sees the P&L impact. This isn’t “tech debt” — it’s revenue recovery. Nobody would delay a $175K/month revenue improvement to build a feature that generates $50K/month.

Velocity Investment

“Adding integration tests to the checkout flow would allow us to deploy that component daily instead of weekly. This means bug fixes reach customers within hours instead of days, and new features reach the market 5x faster. Our competitors deploy their checkout flow continuously.”

Now leadership sees competitive advantage. Speed-to-market is a strategic concern, and framing infrastructure work as a speed improvement connects to board-level priorities.

Talent Retention

“Our engineering attrition rate is 18% annually. In exit interviews, 60% of departing engineers cite codebase quality and tooling frustration. Each departure costs approximately $150K in recruiting, onboarding, and lost productivity. Investing in developer experience improvements could reduce attrition by 5 percentage points, saving approximately $375K annually.”

Now leadership sees a workforce investment — something HR and finance already have frameworks for evaluating.

Making the Shift

Each of these framings is a business case, not a complaint. Each connects engineering work to business outcomes. Each can be evaluated against other priorities on the same terms — risk, ROI, revenue impact, competitive advantage, talent retention.

When you speak the language of risk, ROI, and business impact, “tech debt” stops being an engineering wish list and becomes a strategic investment portfolio that leadership can evaluate, fund, and track with the same rigor they apply to every other business investment.

---

The Garnet Grid perspective: Technical investment decisions should be business decisions. We help engineering leaders quantify and communicate the value of technical improvement initiatives in terms that get budgets approved. Contact us →