How to Present Technical Debt to Non-Engineers

Technical debt conversations with non-engineers fail for one reason: engineers explain what the debt is instead of explaining what it costs. A non-technical executive doesn't need to understand that you have a monolithic architecture with inadequate test coverage. They need to understand that your current codebase is why new features take twice as long as they should, why incidents are more frequent than they need to be, and why your engineers keep leaving. Frame the conversation around business cost, not engineering problems.

Slide 1: The Financial Analogy

Start by establishing the analogy that makes technical debt legible to non-engineers. Technical debt is like financial debt: it accumulates interest over time, it's not inherently bad (some debt is strategically rational), and at some point the interest payments crowd out investment in growth.

The analogy in slides:

• Principal: Shortcuts taken during development to ship faster — design decisions that were expedient at the time
• Interest: The ongoing cost of working around those shortcuts — slower development, more bugs, harder onboarding
• Default risk: The point at which the debt load makes it dangerous or impossible to continue operating — systems too fragile to change, security exposure, inability to scale

This slide answers:

• What is technical debt? (In business terms)
• How does debt accumulate?
• Why doesn't debt just stay stable?

---

Slide 2: What Our Debt Is Costing Us Right Now

Translate the current debt load into business impact. This is the slide that gets executive attention. Avoid technical descriptions — every point should connect to business outcomes.

Categories of business impact:

• Slower feature delivery: "Features that should take 2 weeks are taking 6 because engineers have to work around legacy constraints. We have specific examples: [name the feature, the expected timeline, the actual timeline]."
• Higher incident rate: "Our legacy payment module generates 60% of our incidents despite handling 20% of transactions. Each incident costs [X] hours of engineering time and [Y] in customer impact."
• Engineering turnover: "We've lost 3 senior engineers in the last year who cited code quality as a factor in their decision. Replacement cost per engineer is approximately $85K."
• Security exposure: "Our authentication system uses a library that hasn't been updated since 2019. Known CVEs exist that we haven't been able to patch because of dependency conflicts."
• Inability to adopt new technology: "We cannot use [specific capability] that would enable [specific business outcome] because our current architecture doesn't support it without a rewrite."

---

Slide 3: Why It Got Here

Explain the origin of the debt without blaming the engineering team. Technical debt is almost always the result of rational tradeoffs made under time pressure — shipping was the right call at the time, and the debt was the cost. Executives who understand this are more likely to approve remediation than those who think the debt reflects poor engineering.

Common honest explanations:

• "We moved fast during [growth phase] and took on debt deliberately to hit market timing. We're now paying the interest."
• "The original system was designed for [smaller scale/different use case] and has been extended beyond its design assumptions."
• "Acquisitions added systems that were never properly integrated."
• "The team that built [component] has turned over and the knowledge that made it maintainable left with them."

---

Slide 4: The Debt Inventory (Prioritized)

Show the technical debt portfolio, categorized by business impact. Don't list every issue — focus on the ones that have material business consequences.

Categories:

• Critical: Debt that is actively limiting revenue, creating security exposure, or causing significant reliability issues
• High: Debt that is meaningfully slowing feature development or creating operational burden
• Medium: Debt that creates friction but isn't materially limiting business outcomes
• Low: Debt that would be nice to address but isn't urgent

For each critical and high item, state: what it is, what it's costing the business now, and what it would cost to address.

---

Slide 5: Remediation Options and Investment

Show the options for addressing the debt and the investment each requires. Non-engineers need to understand that debt remediation is not a single project — it's an ongoing program with different approaches available.

Options to present:

Option A: Dedicated remediation sprints Allocate a fixed percentage of engineering capacity (typically 20-30%) to debt reduction each cycle. Slower but lower disruption. Best for debt that can be addressed incrementally.

Option B: Focused remediation project Dedicate a team to a specific high-impact debt item. Faster resolution of the highest-priority debt, but requires temporarily pulling engineers off product work.

Option C: Rewrite / re-architecture Full replacement of a system that is too far gone to remediate incrementally. Highest investment, highest risk, but sometimes the only viable path. Requires careful business case and executive sponsorship.

For each option: Show expected investment (engineering time, external resources), timeline to impact, and expected business outcome.

---

Slide 6: The Cost of Inaction

Address the question executives will ask implicitly: "What if we just live with it?" Show the trajectory if debt is not addressed: how development velocity will continue to slow, what the incident trend looks like, and whether there are specific near-term risks.

Be specific: "If we don't address the payment module debt in the next 12 months, the EOL of its core dependency means we'll be running unsupported software in a PCI-DSS environment, creating compliance exposure."

---

Slide 7: The Recommended Path and Ask

Make a specific recommendation and ask for a specific decision. Don't ask for blanket authority to fix everything — propose a prioritized remediation investment tied to specific business outcomes.

Format:

• Recommended approach (which option, why)
• Investment required (engineering time and any external cost)
• Expected outcome (what improves, by when)
• How you'll measure progress
• Decision needed from this room

Common mistake: Asking for permission to "pay down technical debt." This is too abstract. Ask for: "20% of engineering capacity over the next two quarters to address the payment module and authentication system, with a target of reducing incident rate in those systems by 70%."