Tech Debt as a People Problem: Budgeting, Narrating, and Avoiding the 20%-Time Trap

60-Second Summary

Tech debt is the gap between the system you have and the system you'd build today. It is created by every shipped product and is not a moral failure.
Ward Cunningham's original metaphor (1992) was about deliberate, well-understood shortcuts. Most 'tech debt' today is actually accidental complexity, which is a different problem.
Budget tech debt explicitly: 15–25% of engineering capacity, named, tracked, defended.
'20% time' fails because it has no owner, no roadmap, and no review. Replace with a named, planned debt-paydown stream.
Translate to execs in business terms: customer outcomes blocked, incidents caused, hiring difficulty created. Never present a backlog of tickets.

Every engineering organisation past its first year argues about tech debt. The arguments are almost always the same: engineers want to fix it, product wants to ship features, finance wants to know what it costs, executives glaze over when someone says 'we need to refactor the auth system'. The framing is wrong. Tech debt is not primarily a technical problem and it is not solved by technical answers. It is a people problem — about attention, capacity, narrative, and trust.

What tech debt actually is

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid.”
— Ward Cunningham, OOPSLA 1992

Cunningham's original metaphor was narrow and useful: a deliberate decision to ship a known-imperfect implementation to learn faster, with a plan to revisit. Most modern usage is much looser and includes at least four distinct things — which is the first source of confusion.

Four things people call 'tech debt'

Type	Description	Solution shape
Deliberate debt (Cunningham's original)	Knowing shortcut taken to ship faster	Plan and execute the repayment
Accidental complexity	Code grown messy because no one had time to step back	Refactoring time, named owners
Outdated assumptions	System built for a world that changed (5x users, new regulation, deprecated dependency)	Replatforming project
Skill debt	Codebase requires knowledge the current team doesn't have	Hiring, training, documentation

Why this matters for HR

Skill debt looks like tech debt but is solved by hiring and training, not engineering time. Confusing the two leads to repeated failed 'refactor sprints' that don't address the actual gap.

Why it's a people problem

Tech debt is invisible to people who don't read code. Every story about it requires translation.
Engineers carry the cognitive load of working around it daily; non-engineers don't feel that cost.
The choice to incur it is usually social (deadline pressure, exec promise made externally) not technical.
The choice to pay it down requires saying 'no' to a roadmap item — a political decision, not a technical one.
The people who suffer most from it (new hires, on-call engineers) often have the least voice in roadmap decisions.

How much capacity to budget

Industry benchmarks from DX, McKinsey's Developer Velocity research, and Stripe's Developer Coefficient report converge on a similar number: high-performing engineering orgs allocate 15–25% of engineering capacity to system health work (debt paydown, refactoring, tooling, reliability). Below 10%, the org gradually grinds to a halt over 18–24 months. Above 40% for sustained periods usually signals a different problem (skill debt or a doomed platform).

The 'fixed allocation' model

1
Name the budget
E.g. '20% of every team's sprint capacity is reserved for system health.' Explicit, visible, defendable.
2
Owner per team
One named senior engineer per team owns the tech-debt backlog and prioritisation.
3
Quarterly business case
Each team presents the top 3 debt items, their business impact, and the cost of not paying them. Forces translation.
4
Visible in the same tracker
Don't hide debt work in a separate tool. If it's in Jira/Linear like everything else, it competes — and survives — visibly.
5
Protected, not 'if time permits'
The single most common failure mode is treating the budget as aspirational. Protect it like SLO error-budget time.

The 20%-time trap

Google's famous '20% time' is the inspiration for many tech-debt programmes. It is also the most-misunderstood model in the industry. Google's version had a clear (if informal) review structure, peer pressure to ship, and a culture where 20%-time projects were taken seriously as launchable products. Most copies have none of that. The result: engineers given '20% time for refactoring' typically spend 0% on it after the second deadline, because nothing about the system actually protects the time.

What goes wrong

Without a named owner, a planned roadmap, and a quarterly review, '20% time' degrades into 'work on what you want when there's slack'. There is never slack. The time is silently absorbed by the next deadline. Engineers learn the budget is fictional, and trust in the org's ability to commit to anything drops.

The fix is not more discipline. The fix is to convert the 20% from individual discretion into a named team-level commitment with a roadmap and review — what teams sometimes call 'fix-it Fridays', 'health sprints', or 'platform weeks'.

Narrating it to non-engineering execs

The three-sentence frame

1
Sentence 1 — Business impact
'Our checkout system fails on average 3 times per week for new payment methods, blocking ≈ $40k/month in expansion revenue.'
2
Sentence 2 — Cause and proof
'The root cause is a 2019 architectural choice that bundled all payment methods into one code path; here are the last three post-mortems showing it.'
3
Sentence 3 — Trade
'A 6-week effort by 4 engineers removes the bundling. We propose deferring the loyalty-rewards launch by 4 weeks to do it.'

Notice what is absent: technical jargon, finger-pointing, and any tickets. The exec is being asked to make a business decision with business inputs. Every successful tech-debt programme produces narratives in this shape; every failed one buries the ask in a backlog grooming session.

Worked example: the case for the migration

A 120-engineer Series C company has a payments service written in 2018. It now serves 5x the transaction volume, two new regulators, and three new payment partners. It causes 40% of all Sev-2 incidents. Two engineers maintain it; one is leaving. The case for migration:

Tech-debt business case template

Dimension	Today	After migration	Cost / risk
Sev-2 incidents per quarter	12	Projected 3	Cost of outages avoided: ≈ $400k/year
Time to onboard a new payment partner	8 weeks	2 weeks	Unlocks 2 named partner deals worth $1.2M ARR
Engineers with the knowledge	1 (after departure)	5	Mitigates a bus-factor risk of 1
Migration effort	—	4 engineers, 14 weeks	$280k loaded cost; delays loyalty-rewards launch 6 weeks

Present this with the exec; do not present a 30-ticket Jira list. The decision becomes a defensible trade, not a vague request for 'time to refactor'.

Anti-patterns

'Tech debt sprint' once a year — proves nothing was actually budgeted.
Engineers self-organising 'guilds' to fix debt on their own time — burnout in a hoodie.
Refactor without business framing — gets killed at the next prioritisation meeting.
Confusing skill debt with tech debt — six-month refactor concludes with the same team unable to maintain the new system.
Big-bang rewrites with no incremental milestones — Joel Spolsky's 2000 essay still applies; these almost always fail.
Tracking debt only in a private engineering doc — invisible to product and exec; competes with nothing.

Monday-morning checklist

Pick a fixed % capacity (start at 20%) and announce it explicitly.
Name an owner per team for the debt backlog.
Convert your top 3 debt items into the three-sentence frame this week.
Schedule a quarterly debt review with the product and exec partners.
Audit current 'X% time' programmes for ownership and roadmap; reform any that lack both.

FAQ

Frequently asked questions

What if leadership refuses to budget any debt time?

Track every incident, hire ramp slowdown, and missed deadline back to specific debt items for one quarter. The data forces the conversation. If it still doesn't, that's an org culture problem larger than this article.

Should we use a 'tech debt score' per service?

Useful internally, dangerous externally. Scores invite the wrong arguments. Stick to business-framed narratives in exec settings.

Is rewriting from scratch ever the right answer?

Occasionally yes (when the system's architectural assumptions are fundamentally wrong). Almost always more rarely than engineers propose. Read Joel Spolsky's 'Things You Should Never Do, Part I' before deciding.

How does AI tooling change the calculation?

AI coding tools reduce the cost of refactoring well-tested code; they do not help with the parts that are hardest (unclear ownership, fragile tests, deployment risk). They lower the technical cost moderately but do not change the people problem.

References

Cunningham, W. — The WyCash Portfolio Management System (OOPSLA 1992) — c2.com
Joel Spolsky — Things You Should Never Do, Part I (2000) — Joel on Software
McKinsey — Developer Velocity research — McKinsey
Stripe — The Developer Coefficient — Stripe

Written by Pawan Joshi.Sources cited inline.

First published 15 Jun 2026See site changelog →