Manage Technical Debt Tradeoffs

Required inputs

• Technical debt area or initiative
• Estimated cost: time required to address
• Estimated impact of debt on: velocity, reliability, user experience, or risk

Optional inputs

• Engineering assessment of debt severity
• User or business impact data (incidents, slow features, bugs)
• Opportunity cost: what feature work is blocked or slowed?

Upstream context

Works best when:

• Engineering has characterized the debt
• Product velocity or quality data is available

Downstream handoff

Output can feed:

• build-roadmap-prioritization (debt investment goes on roadmap)
• build-business-case (debt investment needs justification to stakeholders)

Instructions

1. Characterize the debt: what type, how old, what caused it?
2. Quantify the current cost of the debt: delivery slowdown, bug rate, reliability impact, user impact.
3. Quantify the investment: estimated effort and timeline to address.
4. Calculate the payback: how long until the investment pays off in recovered velocity or reduced cost?
5. Identify the risk of not addressing: will the debt compound? Is there a cliff?
6. Make a recommendation: address now / schedule / accept.

Output

Provide:

• Debt characterization (type, cause, age)
• Current cost of debt (velocity, reliability, user impact)
• Investment estimate
• Payback analysis
• Risk of deferral
• Recommendation: address now / schedule next cycle / accept as-is
• Stakeholder communication framing

Risks / caveats

• "Tech debt" without business impact quantification will never beat feature work in prioritization
• All debt is not equal — distinguish structural risk (blocking growth) from cosmetic debt (annoyance)
• Accepting debt deliberately is valid — accepting it accidentally is not