organizationL1 Ad-hocTech Debt & Modernization

Debt grows

Debt grows is the default state of software engineering in organizations that have not made debt management a deliberate practice.

·Tech debt is growing with no systematic reduction plan
·Legacy systems are treated as "do not touch" zones

·Team acknowledges tech debt exists and can enumerate major items
·Migration backlog exists (even if years long with no progress)

Evidence

·Tech debt backlog with items older than 12 months and no progress
·Legacy system documentation (or lack thereof) showing avoidance patterns

What It Is

Debt grows is the default state of software engineering in organizations that have not made debt management a deliberate practice. Every sprint adds new features; every feature ships with small shortcuts, undocumented assumptions, and quick fixes that were meant to be revisited but never are. Over time the codebase accumulates a layer of entropy that makes every subsequent change slower and riskier than it would be in a clean system.

At L1, debt growth is not tracked, not measured, and not discussed in planning. Developers know it exists because they feel it every time they touch certain files - the ones where a simple change triggers a cascade of side effects, where tests are absent or unreliable, where the data model long since diverged from the domain model it was meant to represent. The knowledge of where the debt lives is tribal, held by whoever has been around longest.

The growth is compounding. A codebase with high debt is slower to change, which means features take longer, which means there is less time for cleanup, which means debt grows faster. Teams in this state often describe a feeling of running on a treadmill: working harder each quarter to deliver the same amount of value as the codebase resists them more and more.

The absence of AI tooling makes this worse. Without automated refactoring, every debt-reduction effort requires a developer to manually touch code - competing directly with feature work for the same finite engineering hours. In an organization without AI tools, the math almost always favors features over cleanup, and debt wins.

Why It Matters

Velocity erosion - Debt acts as friction on every development task; teams with high debt consistently deliver features slower than their counterparts on clean codebases, even with equivalent headcount
Onboarding cost - New engineers spend weeks or months learning the local workarounds, undocumented patterns, and danger zones before they can be productive
Bug multiplication - High-debt codebases have more bugs per line of change because the implicit assumptions are not obvious and the test coverage is sparse
Morale drain - Developers who spend most of their time fighting the codebase rather than solving problems become disengaged; high debt correlates with higher attrition on engineering teams
Strategic lock-in - The longer debt grows unchecked, the more expensive any future modernization becomes, effectively locking the organization into outdated technology stacks

Getting Started

Name the problem explicitly - Introduce "tech debt" as a first-class concept in team conversations. If it has no name, it has no budget and no plan. Start by acknowledging that debt exists and that it has a cost.
Do a one-hour debt audit - Have the team spend one hour listing the five most painful areas of the codebase. No tooling needed. Just answers to: "Where do you dread making changes?" This produces the first raw debt inventory.
Attach a cost estimate to one item - For one debt item from the audit, estimate how much slower it makes development. "This module takes 2x longer to change than a comparable clean module." Putting numbers on debt makes the business case for addressing it.
Reserve 10% of sprint capacity for debt - Make a policy decision that 10% of every sprint is available for debt reduction. This does not require permission to fix every item - just establishes the principle that debt is work, not a luxury.
Track before-and-after velocity - When a debt item is addressed, measure whether the next change to that area is faster. Even one data point starts building the evidence base that debt reduction has measurable ROI.
Stop adding to the debt intentionally - Establish a lightweight code review norm: "We don't accept new technical debt without a ticket to address it." This stops the bleeding before attempting to reduce the existing balance.

Tip

The goal at L1 is not to eliminate debt - it is to make debt visible. An organization that can see and name its debt is already in a better position than one that cannot. Visibility is the prerequisite for every subsequent level of debt management.

6 steps to get from here to the next level

Common Pitfalls

Treating debt as a moral failing. Teams that shame developers for creating debt create an incentive to hide it rather than surface it. Debt is the result of reasonable tradeoffs under time pressure - every mature codebase has it. The goal is to manage it, not assign blame.

Big-bang cleanup projects. "We'll fix everything in Q3" is a plan that almost never executes. Large dedicated cleanup sprints compete with feature pressure, get deprioritized, and produce partial results that are harder to maintain than the original. Incremental debt reduction is more effective than periodic cleanups.

Debt that is invisible until it breaks. If the only time debt is discussed is during a production incident, the team is operating reactively. Proactive debt audits - even informal ones - are more effective than waiting for a crisis to force the conversation.

Measuring debt in lines of code or age alone. Not all old code is debt; not all new code is clean. The relevant measure is: how much does this specific area slow us down? Debt that no one ever touches is far less costly than debt in hot paths that change every sprint.

Waiting for perfect categorization before acting. Some teams spend months trying to build a comprehensive debt register before addressing any of it. A rough list of the five most painful areas, acted on immediately, is worth more than a perfect inventory that never leads to action.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob manages a team that is consistently slower than stakeholders expect, and he suspects the codebase is a significant factor. Developers complain about certain modules being "impossible to change," but there is no formal record of what the debt is or what it costs. Bob's instinct is that fixing this requires a dedicated cleanup sprint, but every time he proposes one, feature priorities push it out.

Bob needs to reframe debt as infrastructure, not housekeeping. The conversation with stakeholders should be: "Our development speed is capped by the state of our codebase. Here is a specific area where we are 2x slower than we should be, and here is what it would take to fix it." That framing makes debt reduction a velocity investment, not a distraction from delivery. Bob should also establish the 10% sprint capacity rule as a team norm, so that debt reduction happens continuously rather than competing for a dedicated sprint that never arrives.

SarahProductivity Lead

Sarah is trying to measure developer productivity and keeps running into the same problem: the numbers vary wildly depending on which part of the codebase a developer is working in. A developer working in the clean microservices ships features quickly; the same developer working in the legacy monolith moves at half the speed. The variance makes aggregate productivity metrics nearly meaningless.

Sarah should use this variance as a debt measurement tool. The difference in velocity between clean and debt-laden areas of the codebase is a direct measure of what the debt is costing the organization. Sarah should instrument this: track PR cycle time and story point completion rate by code area, then map the slow areas to known debt. This gives both a debt priority list (fix the slowest areas first) and a business case (fixing this area would recover X% of lost velocity). Debt reduction tracked this way becomes a productivity initiative with measurable ROI, not a vague engineering preference.

VictorStaff Engineer - AI Champion

Victor has worked in this codebase long enough to have a mental map of every danger zone. He knows which files have implicit dependencies on global state, which modules silently ignore errors, and which abstractions were designed for a requirements set that no longer exists. That knowledge lives entirely in his head, and he is increasingly the person who has to review any change touching those areas - a bottleneck that scales badly as the team grows.

Victor should externalize his mental debt map into a structured form, even if it starts as a commented list in a markdown file. That map has two values: it tells other developers where to be careful, and it tells an AI agent where to start when automated debt reduction becomes available at higher maturity levels. Victor should also advocate for the 10% debt budget, because he is the one who pays the highest cost when debt-laden code breaks - the midnight pages, the complex debugging sessions, the hours explaining context to developers who are new to the area. His credibility is the most effective argument for treating debt as a first-class concern.