Published on

Explaining Tech Debt to Non-Tech Stakeholders — The Translation Problem

Authors

Introduction

"Tech debt" is engineering jargon for a financial concept that non-technical stakeholders actually understand very well: the idea that taking shortcuts now creates ongoing costs later. The translation failure isn't about intelligence — it's about language. Engineers talk about technical quality; business stakeholders talk about velocity, cost, and risk. The engineers who successfully get tech debt work prioritized don't explain the code — they translate the technical conditions into business impact their audience is already equipped to reason about.

The Translation Problem

Engineer says: "We need to refactor the authentication service — it's a mess."
Stakeholder hears: "Engineering wants to rewrite something that works."
Result: Request denied. New features prioritized.

Engineer says: "The authentication service has no test coverage and no documentation.
Every change to it takes 3x longer than a similar change elsewhere, because
engineers have to reverse-engineer how it works before modifying it. Last
quarter, it caused 2 production incidents that cost $X to resolve. The
3 features on next quarter's roadmap all touch auth. At our current velocity
penalty, those features will take 6 weeks instead of 2."
Stakeholder hears: "Those 3 features will take 4 extra weeks and cost an extra $Y."
Result: "How long does the refactor take?" Conversation started.

The pattern:
Tech debt is a tax on future development.
Quantify the tax. Show the tax applies to work the stakeholder already cares about.

Fix 1: Debt Register — Make Technical Debt Visible

// tech-debt-register.ts — track debt items with business impact
interface TechDebtItem {
  id: string
  title: string
  system: string
  description: string
  velocityImpact: {
    slowdownFactor: number  // 1.5 = 50% slower
    affectedFeatures: string[]  // Features this slows down
  }
  riskImpact: {
    incidentFrequency: 'high' | 'medium' | 'low'
    lastIncident?: Date
    estimatedCostPerIncident: number
  }
  repaymentCost: {
    engineeringWeeks: number
    riskOfRepayment: 'high' | 'medium' | 'low'
  }
  businessCostPerMonth: number  // Calculated below
}

function calculateBusinessCost(item: TechDebtItem, engineerCostPerMonth: number): number {
  // Cost from velocity penalty
  const velocityCost = (item.velocityImpact.slowdownFactor - 1) * engineerCostPerMonth

  // Cost from incidents
  const incidentCostPerMonth = {
    high: item.riskImpact.estimatedCostPerIncident * 2,    // ~2 per month
    medium: item.riskImpact.estimatedCostPerIncident * 0.5, // ~1 per 2 months
    low: item.riskImpact.estimatedCostPerIncident * 0.1,    // ~1 per 10 months
  }[item.riskImpact.incidentFrequency]

  return velocityCost + incidentCostPerMonth
}

// Example output:
const authServiceDebt: TechDebtItem = {
  id: 'DEBT-001',
  title: 'Authentication service: no tests, no documentation',
  system: 'auth-service',
  description: 'Service written 2 years ago, original author left. No tests. Undocumented.',
  velocityImpact: {
    slowdownFactor: 3,  // Changes take 3x as long
    affectedFeatures: ['SSO integration', 'OAuth refresh', 'Role management'],
  },
  riskImpact: {
    incidentFrequency: 'high',
    lastIncident: new Date('2026-02-15'),
    estimatedCostPerIncident: 5000,
  },
  repaymentCost: {
    engineeringWeeks: 4,
    riskOfRepayment: 'medium',
  },
  businessCostPerMonth: 18_000,  // $18k/month this debt is costing us
}

Fix 2: The Business Case Template

# Tech Debt Remediation: Authentication Service
*Business case for Q2 2026 planning*

## The Situation
Our authentication service handles 50,000 logins per day. It was written 2 years ago
and the engineer who wrote it left the company. There are no tests, no documentation,
and no one on the current team fully understands it.

## Current Business Impact

**Development velocity:** The 3 features on Q2's roadmap all require auth changes.
Based on our last 5 auth changes, each takes 3x as long as comparable work elsewhere.
Q2 roadmap estimate: +6 engineering weeks if we don't address this.

**Production risk:** Auth has caused 3 incidents in the last 6 months. Average incident
cost (engineering time + customer impact): $5,000. At current rate: $10,000/quarter.

**Recruitment risk:** Two candidates this quarter asked about code quality during
technical interviews. Codebases with known debt in critical systems affect hiring.

## The Proposal
4-week engineering investment to:
- Add test coverage to auth service (2 weeks)
- Document architecture and decision rationale (1 week)
- Refactor most error-prone components (1 week)

## ROI Analysis
Cost: 4 engineer-weeks = $24,000 at fully-loaded cost
Annual savings:
- Velocity: 6 engineering weeks per quarter × 4 quarters = 24 weeks = $144,000
- Incidents: reduced from 2/quarter to ~0.5/quarter = $30,000 savings
Total annual savings: ~$174,000
Payback period: 6 weeks

## Recommendation
Prioritize in Q2. The roadmap cost alone (6 extra weeks for planned features)
exceeds the remediation cost. We're paying for this debt regardless — better to
pay it directly than through feature delays.

Fix 3: Visualize the Debt Tax on Upcoming Work

// Show how debt affects features the stakeholder already cares about
// Don't abstract — connect to their specific roadmap

function calculateDebtTaxForRoadmap(
  roadmapFeatures: Feature[],
  debtItems: TechDebtItem[]
): RoadmapDebtAnalysis {
  const analysis = roadmapFeatures.map(feature => {
    // Which debt items affect this feature?
    const applicableDebt = debtItems.filter(debt =>
      debt.velocityImpact.affectedFeatures.includes(feature.title) ||
      feature.systemsTouched.includes(debt.system)
    )

    const slowdownFactor = applicableDebt.reduce((max, debt) =>
      Math.max(max, debt.velocityImpact.slowdownFactor), 1
    )

    const estimatedWithDebt = feature.baselineEstimateWeeks * slowdownFactor
    const estimatedWithoutDebt = feature.baselineEstimateWeeks

    return {
      feature: feature.title,
      estimateWithDebt: `${estimatedWithDebt.toFixed(1)} weeks`,
      estimateWithoutDebt: `${estimatedWithoutDebt.toFixed(1)} weeks`,
      overhead: `+${(estimatedWithDebt - estimatedWithoutDebt).toFixed(1)} weeks`,
    }
  })

  const totalOverheadWeeks = analysis.reduce((sum, a) =>
    sum + parseFloat(a.overhead.replace('+', '').replace(' weeks', '')), 0
  )

  return { features: analysis, totalOverheadWeeks }
}

// Output in a sprint planning meeting:
// Q2 Roadmap — Debt Impact:
// Feature A (auth refactor): 3 weeks instead of 1 → +2 weeks
// Feature B (SSO): 6 weeks instead of 2 → +4 weeks
// Total Q2 overhead from debt: 6 weeks
// With 4-week payoff now: save 2 weeks this quarter, full savings next quarter

Fix 4: Categorize Debt for Different Audiences

Different stakeholders need different framings:

For CEO/CFO (financial impact):
"This costs $18,000/month in slowed development and incidents.
The fix costs $24,000 once. Payback period: 6 weeks."

For Product Manager (velocity impact):
"Every feature that touches auth takes 3x longer than normal.
Q2 has 4 features touching auth — that's +10 weeks on your roadmap."

For Engineering Manager (risk and hiring):
"Auth has caused 3 incidents this year. Every engineer who touches it
needs 2 days to understand it first. It's a retention risk for senior engineers
who don't want to work in systems like this."

For CTO (architecture and risk):
"Auth has no abstraction boundary — everything calls it directly.
A failure or change cascades everywhere. It's a single point of fragility
in our most critical security component."

Same debt, four different business cases, four different audiences.

Tech Debt Communication Checklist

  • ✅ Debt register maintained — business cost calculated per item
  • ✅ Debt items linked to upcoming roadmap features (concrete velocity tax)
  • ✅ Business case uses financial language: cost, ROI, payback period
  • ✅ Proposal includes specific deliverables and timeline — not open-ended
  • ✅ Framing matches the audience (CFO, PM, EM, CTO each need different angle)
  • ✅ Comparison to "doing nothing" is explicit — debt costs money either way
  • ✅ Post-payoff metrics planned — measure whether the investment paid off

Conclusion

Tech debt never gets prioritized when it's framed as an engineering preference. It gets prioritized when it's framed as a cost — a quantified, ongoing tax on the features the business is already committed to building. The business case isn't hard to make: look at the last five changes to the system, measure how long they took vs. comparable systems, multiply by the engineer cost, add incident costs, and show the payback period for the fix. When the payback period is shorter than the current quarter's delay, the conversation changes from "should we fix this?" to "when do we start?"