You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 6 minutes
Key takeaways:
- Tech debt doesn’t just slow you down – it makes you unpredictable.
- Debt kills optionality: when everything takes longer, you stop experimenting. The real cost isn’t the work, it’s the ideas you never tried.
- Reserve 20% for maintenance or pay more later!
The things we refer to as tech debt manifest their costs in a few ways: underestimated work, missed target dates, estimates that are padded or rounded up just because they involve a certain area of the code, and social costs like grumbling and frustration.
When we’re lucky, this debt translates into lower velocity that we can plan for. When we’re not, we don’t just lose velocity, we lose predictability.
Consider a familiar story: this feature will be easy. There are libraries or framework features that make this quick to do. We’ll pay a little bit of a premium the first time, because we need to install it or turn it on, but after that, we’re off to the races!
Except, wait, that new library requires a newer version of the language than we’re using. Also, we already depend on an old version of another library that doesn’t support the newer language, so we’ll need to update that, too.
Or we build our feature without the new library, which will take longer and mean creating a bunch of extra code that we’ll have to maintain. Then we’ll need to iterate and we’ll be building on top of that extra code, making it harder and harder to remove even if we do upgrade. Furthermore, there are a bunch of old feature flags in here, and we never turned some of them on, but they all add complexity.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Low velocity reduces your options
Even predictable drag on our delivery velocity changes the cost-benefit analysis of doing work in the first place. Within long-lived teams, cost is synonymous with time and opportunity cost. If we invest in doing X, we can’t be doing Y.
The less certain we are about the upside of a feature or a capability, the more we need to learn and iterate, the less we, as a business, can afford to invest in it. For large investments, we need high confidence in our expected returns. When our engineering velocity is slow, every investment gets bigger.
The more time we have put into a project, the more likely we are to succumb to the sunk cost fallacy, which is the tendency to continue an endeavor because you have already invested time, money, or effort into it, even when doing so is no longer in your best interest.
After all, we had to be very confident to even start a project that was this large, right? The stronger the business case was when we started, the harder it can be to change priorities or pivot in response to changing conditions.
Both of these factors reduce our optionality. There are fewer things we’re willing to try when everything takes more time. If we can’t make exploration cheap and low-commitment, we won’t do it, and we lose the opportunities to learn.
Missing targets erodes trust
One of the most effective ways to build trust is to consistently do the things you say you’ll do. One of the most effective ways to lose trust is not doing the things you said you would.
For teams that make commitments to outside stakeholders – which is most of them, at least from time to time – that means hitting the targets that we set. If we miss those targets too often or by too much, we teach our stakeholders that they should not believe the estimates we share. Ironically, consistently beating our estimates can have the same effect!
Exactly what constitutes too often depends on the culture of the organization as well as on how proactive and open the team is able to be about progress and setbacks. What counts as too much can mean time, or functionality, or polish.
A good time estimate is off by less than an order of magnitude of time – e.g. an estimate in weeks can be off by days, an estimate in months off by weeks, etc. The impact of delivering less than we intended depends on what didn’t make the cut: low-stakes, nice-to-have goals are negotiable, while missing a key outcome looks like a failure.
Trust can be like a bank. Building trust – i.e. making deposits – makes it easier for us to make withdrawals or borrow when we need to. When we do need to do a larger technical investment, or have proposals that have more business risk, having that banked trust from an existing track record makes the difference between support from the organization and getting shut down.
When we carry the kinds of technical debt and depreciation that causes our estimates to be consistently wrong, our business partnerships suffer. Other teams will be less eager to work with us, and so we won’t have the kinds of relationships or the trust we need to make more impactful changes.
As the damage of lost trust can be so difficult to repair, teams will often fall back to the first case: padding estimates and assuming the work will contain surprises.
More like this
Tech debt is manageable
Tech debt and depreciation can be managed proactively. When debt is deliberate, teams can plan the follow-up work to pay down that debt together with the work that will take it on.
Making an intentional, informed decision to get some business outcome – e.g. a product launch, cost savings – sooner, in exchange for some opportunity cost afterwards, can be prudent. If the tradeoffs are clear and communicated, the flexibility and effective planning can help build trust.
Sustaining engineering work – keeping third-party code up-to-date, updating patterns and abstractions, pruning old code and branches, etc. – is how teams can stay ahead of depreciation, the slowly-accrued debt that becomes surprises. Setting aside some portion of time, usually around 20% of the engineering capacity, for this work is a simple (if not always easy) way to ensure it is happening consistently.
Of course, we will never be able to stay completely on top of our sustaining work, and pay down every bit of debt as soon as we take it on. When we need to carry debt for longer, maintaining an inventory of known areas of debt and their impact helps in a few ways.
Keeping an inventory keeps it top of mind, and visible, so that we know when we do need to plan extra time. How the list grows or shrinks over time lets us know when we may need to invest more in maintenance. Having a list helps us prioritize the most impactful debt when we do have time to pay it down.
New York • September 15-16, 2026
Full LDX3 lineup is here 🙌
Final thoughts on tech debt
I have seen many engineers struggle to make the case to do technical work or pay down tech debt, even when they intuitively understand the impact of deferring it. Translating that intuition into language and effects that are meaningful to the business can be the missing piece.
The business may not be aware that the team could be going faster, or that a well-defined, finite project could reduce uncertainty and risk. It is up to engineering leaders to tell that story in terms our business partners can understand.
