Technical Debt as a Balance Sheet Entry: Communicating Cost to Non-Technical Leadership
Framing tech debt as a deferred maintenance cost — with an interest rate — resonates with finance-minded executives in ways that 'we need to refactor' does not.
"We need to refactor" does not survive a budget meeting. "We are paying approximately $180k/year in engineer time on workaround tax, compounding at ~15% annually" sometimes does. Framing technical debt as a balance sheet entry — deferred maintenance with an interest rate — is how I get finance-minded executives to engage without pretending they care about cyclomatic complexity.
Pair with writing RFCs that get read for the document structure. For a concrete cost line item executives already understand: cost of cloud egress honest accounting.
The metaphor, precisely
Principal: the one-time cost to fix the underlying problem to "good enough" standard.
Interest: recurring cost paid every sprint because the problem remains — slower development, incident response, manual ops, customer support load, over-provisioned infra compensating for inefficiency.
Interest rate: interest divided by principal, annualized. A 20% rate means the workaround tax grows if you do nothing.
This is not GAAP accounting. It is a communication model. Do not let finance call it a literal liability unless your CFO wants that fight.
Worked example: payment idempotency debt
Situation: Original payment API had no idempotency keys. Three years of patches: client-side dedup, support-run SQL scripts, a Redis lock that fails open under partition.
Principal estimate (fix properly):
- 2 senior engineers × 6 weeks = 12 eng-weeks
- Loaded cost ~$15k/week (salary + overhead blended) = $180k one-time
Interest estimate (annual workaround tax):
- ~4 hours/week support/engineering on duplicate charge tickets: $20k
- ~2 eng-weeks/quarter on related incident follow-ups: $30k
- Customer credits issued (tracked): $25k
- Opportunity cost: delayed marketplace feature (team estimate, not fantasy): $50k conservative
- Total interest ~$125k/year
Implied rate: 125/180 ≈ 69% annualized. Painful. Easy prioritization conversation.
Compare to a low-rate debt: outdated linter config costing 30 minutes/week → ~$2k/year interest on $8k principal → 25% but tiny absolute dollars. Queue behind revenue work.
How to estimate without lying
Executives smell invented precision. I use ranges with sources:
| Line item | Method |
|---|---|
| Incident time | PagerDuty × on-call rate × last 4 quarters |
| Support tickets | Zendesk tag × avg handle time × loaded rate |
| Delayed features | PM documents slipped OKR; eng estimates delta |
| Infra overage | Cost explorer delta attributed in writing |
| Developer velocity tax | Survey + sample: "hours/week lost to X" × team size |
Show the spreadsheet. Label assumptions yellow.
What not to do: multiply total eng salary by "30% slower." Too vague to defend.
The one-slide version
TECH DEBT: Payment idempotency
Fix cost (principal): $150k – $200k (one-time)
Annual cost if unfixed: $100k – $150k (interest)
Payback period: ~18 months
Risk if deferred: E1 duplicate charges at scale
Recommendation: Q2 initiative, 2 engineers, exit criteria =
idempotency keys on all write endpoints + migration complete
Exit criteria matter. "Refactor payments" is not a project. Finance funds projects with end dates.
When the metaphor fails
Greenfield rewrite fantasies. Principal quoted as 18 months for "new platform" with interest modeled as zero after flip — fiction.
Debt that is actually sunk learning. First API version taught you the domain. Calling it debt insults the learning. Reframe as "version 1 retirement."
Regulatory or security debt. Sometimes interest is binary (breach, fine), not linear. Use risk register language from security review, not amortization.
Negotiation tactics that worked
Ask finance to co-own the model. One CFO staff analyst helped me validate loaded rates. Their stamp beats engineering guesswork.
Tie paydown to revenue unlock. "This debt blocks enterprise tier" converts abstract interest to pipeline dollars.
Offer phased principal. Month 1: stop bleeding (feature flag + manual process). Month 2–3: structural fix. Lowers perceived lump risk.
Never compare to zero. Compare to alternative investments with same capacity. "These two engineers on debt vs on Feature Y" — PM chooses with eyes open.
Organizational hygiene
Maintain a tech debt register visible to product:
| ID | Description | Principal | Interest/yr | Rate | Owner | Status |
|---|---|---|---|---|---|---|
| TD-014 | Payment idempotency | $180k | $125k | 69% | @payments | Q2 planned |
| TD-022 | Manual K8s deploys | $40k | $35k | 88% | @platform | In progress |
Review quarterly. Archive items when interest hits zero with evidence.
Anti-patterns
Debt bombing before reorg. Everything is P0 debt; nothing gets funded; credibility lost.
Interest without principal. "We are slow" is not a balance sheet entry.
Principal without exit criteria. Open-ended refactor = budget black hole.
Using debt language for normal maintenance. Upgrading EOL runtime is maintenance, not debt. Different budget line, same approval path — do not muddy the metaphor.
What I would do next
Hook the register to incident postmortems — any postmortem tagging "known debt" auto-suggests an interest line item update. Manual registers rot.
Train EMs to bring one debt slide per quarterly business review. Volume stays low; signal stays high.
Related
RFC writing for structuring the paydown proposal. Cloud egress costs as a template for honest recurring cost accounting.
Manish Bookreader
Electronics enthusiast, Embedded Systems Expert, Linux/Networking programmer, and Software Engineer passionate about AI, electronics, books, and cooking.
