What is technical debt, and why does it pile up faster when the team changes?

Technical debt is the future cost of choosing the fast solution today instead of the cleaner one: every shortcut sits there like a loan, and it collects interest in the form of bugs, features that get more expensive to build, and code nobody wants to touch. It isn't a synonym for bad code — it's a decision, conscious or not, to push a piece of work off until later. The real problem isn't that it exists: it's not knowing how much has piled up, or who's going to end up paying it off.

Every software project generates some amount of technical debt — it's not avoidable, and it isn't always a mistake. What decides whether it becomes a problem is whether someone tracks it and pays it down on purpose, or whether it piles up quietly until the system becomes more expensive to change than to throw away and rebuild.

Where does the term come from, and what does “paying it off” actually mean?

The metaphor was coined by programmer Ward Cunningham in 1992, in a report about building a financial system: he compared writing code the fastest possible way to taking out a loan. That loan lets you move faster in the short term, but every cycle that passes without refactoring that code adds interest — the system gets more rigid, slower to change, and more expensive for someone who didn't write it to understand. “Paying it off” means spending development time rewriting, documenting, or simplifying that code instead of building new functionality on top of it.

How much time and budget actually go toward paying it off?

The most widely cited industry figure comes from Stripe: in a survey of over 1,000 developers and 1,000 C-level executives across five countries, engineering teams reported spending an average of 17.3 hours a week — 42% of the surveyed work week — on maintenance and badly written code instead of building new functionality (Stripe, The Developer Coefficient, 2018). 79% of the executives surveyed said time lost to legacy systems was a significant concern for the business.

McKinsey surveyed 50 CIOs at large financial-services and technology companies and found that, on average, technical debt accounts for 20% to 40% of the value of a company's entire technology estate — and that 10% to 20% of the budget earmarked for new product work ends up going toward fixing legacy issues instead (McKinsey, Tech debt: Reclaiming tech equity, 2020). Deloitte's most recent Global Technology Leadership Study puts that drag in a similar range: 21% to 40% of an organization's total technology spend (Deloitte, Global Technology Leadership Study, 2026).

Why does it pile up faster once the team that wrote the code is gone?

Code doesn't document the reasoning behind each decision — that lives in the memory of whoever wrote it. When that team changes mid-project, the reasoning disappears with them: the next team inherits the result without the context, and when in doubt, almost nobody refactors someone else's code they don't fully understand — they build new code around it instead, until touching that part of the system becomes something people avoid. That's exactly what speeds up the buildup: it's not that a new team writes worse code, it's that every handoff resets the tacit knowledge that was keeping the debt in check.

It's the same reason a squad that has already worked together on other projects — and stays the same team from start to finish — tends to build up less invisible debt than one assembled from scratch for each contract: not because the people are better, but because the knowledge of why the system was built a specific way doesn't get lost along the way.

Is all technical debt bad?

No. Martin Fowler himself, in 2009, proposed thinking about it along two axes: whether it was a deliberate or inadvertent decision, and whether it was a prudent or reckless one (Martin Fowler, Technical Debt Quadrant, 2009). Consciously taking a shortcut to quickly validate a business hypothesis — knowing you'll need to come back to that part of the code later — is prudent, deliberate debt. The problem isn't taking that shortcut: it's not writing it down anywhere and discovering it months later, when nobody remembers it was supposed to be temporary.

How do you keep it from piling up without slowing down delivery?

The most effective way to avoid building up invisible debt isn't to stop and refactor everything before moving on — it's making sure every delivery is documented with explicit criteria from the moment it's defined, and that the work goes through review before it merges into the rest of the system. On Zenit, every milestone gets agreed on with acceptance criteria signed in advance, so “done” isn't an ambiguous word that everyone interprets differently six months later.

Kaizen adds another layer during execution: it doesn't just build the initial match, it stays with the project milestone by milestone and goes back to the company if it picks up a real risk signal — before it turns into the kind of silent shortcut nobody documented.

Visibility matters too: when the evidence of progress is the code itself — commits, pull requests, code review — instead of a verbal report, the debt that's building up stays visible to the company, instead of hiding behind an “everything's going fine” in the weekly meeting.

Technical debt doesn't get eliminated — no software project gets to zero. What changes the outcome is whether someone knows how much there is, who created it, and when it's due to be paid down, instead of finding out only once the system has already become too expensive to touch.