Technical Debt Isn't What Slows Teams Down. Unclear Ownership Is.
I've seen fast codebases that look messy and slow codebases that look clean. The difference was never the code quality. It was who felt responsible for which decisions.
Technical debt is one of those terms that gets applied to so many different problems that it's starting to lose its diagnostic value. Bad code, slow code, code nobody understands, code that's hard to test, code that's using an outdated pattern, code that was written in a rush — all of it gets labeled "tech debt," and the implied solution is always the same: we need time to clean this up.
In my experience, the cleanup rarely solves the real problem. The messy code gets replaced with clean code. Six months later, the clean code has become the new mess. The pattern repeats because the cleanup addressed the symptom — the specific code that was hard to work with — without touching the underlying cause: nobody is clearly responsible for preventing the mess from accumulating in the first place.
Code doesn't become a maintenance burden because engineers are careless. It becomes one because no one has a mandate to say "this isn't good enough to ship."
What slow codebases actually have in common
I've worked in codebases that moved slowly despite being reasonably clean, and I've worked in codebases that moved quickly despite being full of patterns that would make a senior engineer wince. The slow ones shared a consistent set of characteristics that had nothing to do with code quality.
First: every cross-cutting change required buy-in from multiple teams or individuals, and that buy-in was hard to get because nobody had clear authority over the shared space. Want to update the authentication middleware? Three teams use it. Which team owns it? Nobody, really, so the change stalls. Want to refactor a core utility that's imported everywhere? Same problem.
Second: architecture decisions were made implicitly, through the accumulation of individual choices, rather than explicitly through deliberate design. Nobody decided the app would end up with five different state management approaches — it happened gradually, as each team solved their problem with the tool they were most comfortable with at the time. Cleaning it up requires undoing decisions that were never formally made, which is much harder than changing a decision that was.
- PRs sit open for days because nobody knows whose approval matters
- The same architectural pattern is implemented differently in different parts of the app
- Shared utilities drift out of sync because nobody's job it is to maintain them
- Cross-team changes require extensive coordination for work that should be routine
Ownership doesn't mean gatekeeping
When I say ownership, I mean something specific: there is a person or a small group who feels responsible for the quality and direction of a particular part of the codebase, has the authority to make calls about it, and will notice and care if it degrades. That doesn't mean nobody else can touch it. It means someone is accountable when something goes wrong or when standards slip.
The absence of that accountability is what creates the tragedy-of-the-commons dynamic that makes shared codebases so hard to maintain. Nobody makes a deliberate decision to let the shared utilities get messy. But when cleaning them up isn't anyone's responsibility, it never quite makes it to the top of anyone's priority list either.
The thing worth investing in
Before the next refactoring sprint, it's worth asking a harder question: not "what code should we clean up?" but "why did this code become hard to work with, and who should have prevented that?" The answer usually involves a gap in ownership, a missing architectural decision, or an implicit standard that everyone assumed someone else was enforcing.
Clean code is easier to maintain than messy code. But clean code without clear ownership will become messy again. The investment that actually compounds over time is the one that clarifies who is responsible for what, and gives those people the authority to act on that responsibility. The code will follow.