Most engineering teams have a backlog of work they call "tech debt." Developers understand how it can slow down feature development, increase support costs, and threaten system stability. Yet when they bring these concerns to stakeholders, the work often stays deprioritized indefinitely. The term positions engineering work as backward-looking cleanup rather than forward-looking value creation. It's defensive, it's ambiguous, and it guarantees the work never gets prioritized.
"Tech debt" is a self-fulfilling prophecy that perpetuates the communication gap that created it in the first place.
Why "Tech Debt" Guarantees Deprioritization
The metaphor creates the outcome everyone complains about by shaping how people think about and discuss the work.
The term is too ambiguous to be actionable. When someone says "tech debt," what do they actually mean? Intentional tradeoffs made under time constraints? Unanticipated consequences of reasonable decisions? Outright mistakes? Code that worked fine but is now outdated due to evolving requirements? The term conflates deliberate strategy with failure, which makes it impossible to have productive conversations about what to do next.
The metaphor obscures actual costs and consequences. Real financial debt has clear terms: borrow $100K at 5% interest, pay it back over 5 years. "Tech debt" has no such clarity. What's the interest rate? When is it due? What happens if we don't pay it? The metaphor lets everyone avoid confronting actual costs and timelines. Without clear costs, there's no urgency, and without clear consequences, there's no accountability. Stakeholders hear "the code is messy" and think "so what?" They don't hear "we're losing $50K per month in support costs because this implementation is brittle, and we can't ship the feature roadmap because every change breaks three other things."
The debt metaphor implies inevitability. "We'll always accumulate some debt; that's just how software works." This defeatist framing makes people accept poor decisions as unavoidable rather than asking "why are we making decisions without enough information?" The term normalizes dysfunction instead of demanding clarity.
The term frames it as engineering's problem. When you say "we have debt to pay down," stakeholders hear "you made a mess, now clean it up." This doesn't invite collaborative problem-solving. It creates an adversarial dynamic where engineering owns the problem and stakeholders reluctantly allocate time to "let them fix their mistakes."
Missing architectural context creates an assumption of incompetence. When architectural decision records don't exist, future teams assume incompetence rather than recognizing intentional tradeoffs. The original context disappears: why this approach was chosen, what constraints existed at the time, what the intended evolution path was. Without that clarity, the current team either blindly perpetuates a bad pattern because they don't understand the original intent, or rewrites everything because they assume the previous team didn't know what they were doing. Both outcomes are expensive.
Consider how different this looks with context. If the architect had documented "We chose NoSQL here because we needed to ship in 3 months with the team we had. The long-term design uses relational storage; we've isolated this behind an interface so we can swap it later without touching business logic," the team has a roadmap instead of a mystery. The architect becomes the translator between constraints, decisions, and evolution paths. Without that translation, the cycle repeats: poor communication creates problems, vague language prevents fixes, and the gap widens.
An Alternative: Categories That Communicate Impact
Developers can keep using "tech debt" internally as shorthand within engineering teams, but when talking to product owners and stakeholders, retire the term entirely.
One approach is to categorize work by business impact: Corrections, Optimizations, and Re-Alignments.
Corrections: Problems Causing Harm Now
What it is: Mistakes, tradeoffs, or outdated decisions actively harming the business right now.
Examples:
- Security vulnerabilities exposing customer data
- Bugs causing support escalations or customer churn
- Reliability issues causing downtime or SLA violations
Why this works: Stakeholders already understand bugs and security problems as priorities because they're causing measurable harm today.
Language to use:
- "We have a security vulnerability that exposes customer payment data. The fix takes 2 weeks."
- "This bug is costing us $30K per month in support escalations. Fixing it unblocks the support team."
- "The authentication service has 99.5% uptime. Our SLA guarantees 99.9%. The gap creates $100K annual credit exposure. Fixing the root cause takes 3 weeks and eliminates the SLA risk."
Corrections communicate urgency. The business is being hurt now, and addressing it stops the bleeding immediately.
Optimizations: Improving Efficiency and Cost
What it is: Mistakes, tradeoffs, or outdated decisions affecting cost, performance, or efficiency.
Examples:
- Database queries causing slow page loads (affecting conversion rates)
- Infrastructure configuration costing more than necessary (budget impact)
- Manual deployment process taking hours per release (velocity impact)
- Inefficient algorithms causing excessive cloud compute costs
Why this works: Stakeholders understand optimization as improving what exists. It's not "paying debt," it's "increasing margin" or "improving user experience."
Language to use:
- "Our cloud costs are $50K per month. A 3-week optimization brings that to $20K per month, saving $360K annually."
- "Checkout page loads in 8 seconds. Optimizing to 2 seconds increases conversion by 15% based on industry benchmarks. The work takes 4 weeks and projects to $500K additional annual revenue."
- "Automating deployments cuts release time from 4 hours to 15 minutes, letting us ship features faster. The automation work takes 2 weeks and doubles deployment frequency."
Optimizations communicate efficiency gains with measurable ROI. The business improves margins, performance, or velocity.
Re-Alignments: Unlocking Future Capabilities
What it is: Mistakes, tradeoffs, or outdated decisions that, when fixed, unblock new features, integrations, or business capabilities.
Examples:
- Monolithic architecture preventing independent team scaling
- API design preventing mobile app development
- Data model preventing real-time analytics feature
- Vendor lock-in preventing multi-cloud strategy
- Legacy authentication system preventing enterprise SSO integrations
Why this works: Stakeholders understand opportunity cost. If the current architecture blocks a $2M revenue opportunity, fixing it isn't "paying debt"; it's "unlocking growth."
Language to use:
- "We can't build the mobile app until we redesign the API. The redesign takes 6 weeks and unblocks a $2M annual opportunity."
- "Our current data model prevents real-time dashboards (top customer request). Re-aligning the schema takes 4 weeks and delivers the feature."
- "The monolith prevents us from scaling the checkout team independently. Splitting it out takes 8 weeks and doubles that team's velocity."
- "Moving to OAuth 2.0 unblocks enterprise SSO integrations. The $500K deal waiting on this capability closes once we deliver it. The migration takes 5 weeks."
Re-Alignments communicate strategic value. The business unlocks capabilities that enable growth, close deals, or meet customer demands.
Breaking the Cycle
The self-fulfilling prophecy persists because both sides perpetuate it. Developers tend to use use vague language, stakeholders have little choice but to ignore those vague requests, and the cycle continues.
Break it by being the solution:
- Replace "tech debt" with Corrections, Optimizations, and Re-Alignments when talking to stakeholders
- Communicate business value from the start in architectural proposals and decisions
- Mentor developers on translating technical concerns into stakeholder priorities
- Enforce quality standards at every increment through code reviews, architecture reviews, and quality gates
- Document decisions with ADRs so context doesn't disappear and future teams have roadmaps
These aren't debts to be paid; they're opportunities for value. If the term itself guarantees the problem, replace it.
Top comments (0)