Tech Debt vs Quality

Managing Debt, Quality, and Speed with Intention

Last week’s newsletter talked about the inevitable increase in bugs when changing something, including changing a team’s velocity. It also argued that great teams react to this turbulence by building slack, ownership, and feedback loops to restore quality. In this week’s post, I want to include tech debt into the conversation because sometimes people confuse tech debt with bugs.

Tech debt is the implied cost of rework caused by choosing an easier or simpler solution now instead of using a better approach that would take longer. This arises from decisions, sometimes deliberate and other times not so deliberate. The impact of accumulated tech debt is that it slows down future development, makes it harder to add new features, and can lead to more bugs, but it is a manageable and sometimes necessary part of development. Bugs are different. They are a specific error, flaw, or fault in the code that causes an unexpected or incorrect result. The impact is that the software does not work as intended, leading to a poor user experience and potentially requiring an immediate fix.

Everything new has bugs and every engineering organization that moves quickly accumulates technical debt. Both are inevitable as gravity but they are different. With tech debt the question is whether that debt is intentional, the cost of smart, strategic bets, or accidental, the byproduct of haste and neglect.

In fast-moving environments, leaders often frame debt as a moral issue: something to be ashamed of, cleaned up, or avoided. But that’s the wrong metaphor. Technical debt isn’t like personal debt; it’s more like leverage. You take it on to gain momentum, to make progress faster than your systems or teams can evolve. The key is knowing when the interest payments start eating your future.

A decade ago, Etsy was one of the earliest companies to talk publicly about this. They were a PHP monolith growing faster than their codebase could handle, and they realized that trying to “rewrite cleanly” would kill their velocity. So instead, they adopted a culture of “continuous cleanup.” Every sprint included time for paying down small, local debts, renaming variables, improving tests, refactoring bits of business logic, while deferring big architectural overhauls until the cost of not doing them became greater than the disruption of doing them. They didn’t treat debt as an emergency; they treated it as part of the operating budget.

The healthiest teams make debt visible. They track it, measure its impact, and prioritize repayment deliberately. Google has gone so far as to embed debt work into its quarterly planning process, allocating capacity explicitly for maintenance and cleanup. It’s a quiet acknowledgment that debt is not a separate category of work; it’s an inseparable part of building anything that lasts.

There’s also a cultural side to this. Engineers need to feel safe acknowledging debt. Too many teams bury it under optimism, afraid to admit the shortcuts they took to hit deadlines. But sunlight is the best disinfectant. When debt is out in the open, documented, discussed, and scheduled, it stops being a liability and becomes a tool. You can reason about it. Trade it. Retire it when the timing is right.

And this ties directly back to speed. The faster your organization moves, the more deliberate you have to be about managing debt. Every time you increase release velocity, take on a new platform, or scale the team, you’re creating small inefficiencies, corner cases, duplicated logic, tests that don’t quite fit anymore. None of it is fatal. But left unmanaged, the interest compounds, and eventually, it slows you down more than the original gains in speed.

So if moving fast is the goal, and in product development it always is, then managing debt must be the discipline. The trick isn’t to avoid it; it’s to make sure you’re the one deciding when and how to pay it down. Because when you don’t, the system decides for you, and it always charges interest.

The way I view this is a cycle where tech debt impacts velocity. As we discussed last week, an increase in velocity impacts quality, often an increase in bugs. Many teams address this by implementing slack into their sprints, allowing time to clean up bugs and generally pay down tech debt. If we don’t allow for that eventually our tech debt grows, which can slow down velocity.

Intentional vs. Accidental Debt

One of the biggest misconceptions about tech debt is that it’s always bad. It isn’t. Some of the most effective engineering organizations I’ve worked with carry plenty of it, by choice. They treat it the way a good investor treats leverage: as a tool to accelerate progress when the opportunity is worth it. Intentional debt is a calculated trade. You knowingly take a shortcut to gain something more valuable, time to market, user feedback, or simply learning faster than your competitors. You do it with a clear reason and, most importantly, a plan to pay it down.

Accidental debt is different. It’s the kind that creeps in when decisions aren’t recorded, when ownership is diffuse, or when “we’ll fix it later” becomes a habit instead of a strategy. It grows silently in the shadows of velocity, duplicated logic here, missing tests there, until every small change feels risky. Teams begin to slow down not because they’ve lost talent or motivation, but because the system itself resists modification. The cost of change becomes unpredictable, and that unpredictability kills momentum.

The difference between intentional and accidental debt isn’t in the code; it’s in the conversation. Mature teams talk openly about the tradeoffs they’re making. They leave breadcrumbs for their future selves, comments, design docs, even TODOs with context, so that when the time comes to refactor, the “why” is still visible. Immature teams, by contrast, hide their debt under optimism. They sprint ahead, hoping tomorrow’s version of the team will have more time or discipline. But tomorrow never comes.

Treating debt as a strategic choice rather than an accidental consequence is what separates teams that grow sustainably from those that burn out under their own complexity. When you decide deliberately which corners to cut, and which ones you’ll come back to, you’re not being reckless. You’re managing risk. And that’s the difference between hacking and engineering.

Every piece of tech debt carries an interest rate, whether we admit it or not. Some of it accrues slowly, a confusing variable name, an awkward class hierarchy that mostly stays out of the way. You can live with those for a long time. Other debt compounds fast, an untested deployment script, a shared utility that everyone depends on but no one owns. Each week it grows more expensive, like an unpaid balance quietly eating into your future productivity.

The trick is learning to recognize the rate before it’s too late. High-interest debt shows up in the parts of the system you touch most often. Every time you need to ship a feature, it’s there, slowing reviews, breaking tests, or forcing manual workarounds. You start to see the pattern: the same fragile module causing merge conflicts, the same brittle API mocked in half a dozen ways. That’s the kind of debt that needs to be paid down early, because every new project you build on top of it multiplies the cost.

Low-interest debt, on the other hand, can wait. It’s the slightly clumsy configuration file or the naming convention that no one loves but everyone understands. You track it, you acknowledge it, but you don’t drop everything to fix it. Treating all debt as equally urgent is like paying off your mortgage before your credit card, it looks responsible but makes no financial sense.

The healthiest engineering cultures talk about debt in these terms. They measure it, not emotionally but economically. They ask, “What’s this costing us in developer time, in incidents, in missed opportunities?” When you quantify the interest, prioritization becomes clearer. Instead of hand-wringing over “clean code,” teams make pragmatic trade-offs that keep them both fast and sane.

This is where leadership matters most. Engineers naturally want to fix everything; product teams naturally want to ship everything. The balance lies in understanding that some cleanup work pays dividends immediately, while other refactors are long-term investments. Knowing the difference, and acting on it, turns debt management from an endless guilt cycle into a form of strategic planning.

Designing for a Better Cycle

If tech debt, velocity, quality, and slack form a cycle, then the goal isn’t to freeze it in equilibrium, it’s to improve it with each rotation. Every time you complete a loop, the system should get a little smarter, a little cleaner, and a little faster. The healthiest engineering organizations don’t simply manage the turbulence that comes with speed; they harness it. They treat every dip in quality or surge in debt as feedback, not failure.

Improvement starts with intentional design. High-performing teams don’t stumble into better cycles; they engineer them. They plan for incremental upgrades, automating what used to be manual, refactoring brittle subsystems, tightening observability, or improving test reliability, so that each pass through the loop increases the system’s resilience. They use metrics like build time, incident frequency, or code review latency as barometers of progress, not vanity. Every improvement compounds, shortening the lag between speed and stability.

Slack becomes the lever for progress. Instead of viewing it as downtime, great teams use their breathing room to make the next iteration smoother: cleaning up scripts, reducing manual toil, simplifying abstractions. This is how you accelerate sustainably, not by pushing harder, but by removing friction. The point isn’t just to survive the cycle; it’s to evolve through it.

Leadership plays a decisive role here. Teams mirror what leaders measure. When leaders value learning velocity as much as delivery velocity, when they reward the quiet improvements that make future sprints easier, the cycle naturally trends upward. Over time, what once felt like chaos begins to feel like momentum.

Tech debt, velocity, quality, and slack aren’t competing forces, they’re interdependent gears. Each one drives the others, and the art of engineering leadership lies in turning that motion into controlled improvement. Every release, every postmortem, every cleanup sprint should make the system a little more capable of handling the next turn of the wheel.

That means debt isn’t the villain; unmanaged debt is. Slack isn’t a luxury; it’s the fuel for evolution. Quality isn’t the absence of bugs; it’s the presence of care. And velocity isn’t a number, it’s the pace at which your organization can learn safely.

If you’re leading a team, here’s the challenge: don’t just manage the cycle, upgrade it.

• Use retrospectives to identify the friction points in your current loop.

• Invest a portion of every sprint in strengthening the system, not just shipping features.

• Track how long it takes your team to recover from change, and aim to make that recovery shorter each quarter.

The goal isn’t to find balance; it’s to build acceleration that lasts. The best teams don’t just move fast once, they design a cycle that gets faster, safer, and more intelligent every time it turns.