#26 When to Pay Down Tech Debt
Handling technical debt is a recurring subject among software engineering teams.
, former principal engineer with 30+ years experience, wrote a guest post on newsletter, where he shared his lessons from managing tech debt and a guide on how to reduce it effectively. My motivation for covering this topic is to share my take on when it makes sense to pay down tech debt, and also because this is something I’m currently managing with my team.In this post, I’ll answer two questions:
How to think about tech debt.
When to pay down tech debt.
First, there will always be tech debt
In early 2023, my manager asked me to chair the backend weekly meeting and own the platform backlog. I was responsible for curating the backlog, tracking ongoing progress with the backend team every Monday, and managing comms with the platform users.
In first few months, I noticed that the platform backlog was somewhat static, very few things are being added every month or two. So I figured, what if I encouraged the team to divide-and-conquer on these tech debts in parallel to working on the upcoming sprints? Our backlog should be clean in a few weeks. 🧹
My assumption was wrong, obviously. I assumed that our new implementations would not generate any new tech debt, our tools would not push us to do any version upgrades, and no legacy code constraints would surface over time. Thinking of squashing all the debt is a positive approach, but not a realistic one.
So rather than thinking of debt as a finite set of tasks in a fixed bucket, think of it as an infinite stream of tasks, where the rate of change depends on how your teams operate. Following good design patterns and abstractions in writing code = fewer debt. Writing messy spaghetti code = more debt.
As long as you’re building new things, there will always be tech debt.
Why you should care
A technical debt can be defined as an issue in the codebase or infrastructure that makes it harder for engineers to introduce new changes.
Tech debt is sometimes viewed as a quality-of-life opportunity for engineers working on the product.
While the main goal should still be focused on the product roadmap for delivering business value. However, the engineers working on the roadmap should have the least amount of friction to do their work. Tech debt is a secondary backlog that accumulates over time, and neglecting it too often can harm developer productivity, reduce team morale, and eventually lead to engineers leaving.
A friend of mine who worked at a tech company once shared that the main reason she left her job, was the unwillingness from her team and leadership to address tech debt. She became frustrated working in an environment with broken tools, flaky tests, failing pipelines, and missing READMEs.
I empathise with her story. While delivering business value is always a priority, neglecting developer productivity too much ultimately slows down the engineering team. If businesses need to delight their customers, they’ll need to support their engineers.
However, on the flip side, not all tech debt is worth fixing. Some of them are nice-to-haves with no noticeable improvement to developer productivity. Possibly in 6–12 months, they can start to make a dent at developer productivity. At that time, we can pay down the debt. But for now, we should focus on shipping new features and make a note of these potential future dents.
We should only care about tech debt that improves our ability to deliver business value.
When to pay down tech debt
Going back to the platform backlog story, one day I received an email from Google Cloud Provider (GCP) announcing the deprecation of their Container Registry service and the migration to Artifact Registry. Since we were using the soon-to-be-deprecated service for storing images, I saw this as tech debt, a critical one. However, looking back, the email that was sent was only announcing a 2-year deprecation window. So by prioritising and pushing for immediate action amid all the other things we were working on was a hard sell, one that didn’t seem like a good idea. I raised it during our weekly backend meeting, had a good discussion, and took some notes. But the general consensus was, “Is this a problem we need to solve right now?” The answer was no.
So my advice is this: pay down tech debt for today’s problems and plan for 3-6 months. Focus only on those that will (A) increase developer productivity or (B) improve user experience.
To reiterate using
’s quote:“The heuristic I use to pay tech debt these days is this: by reducing a specific tech debt, can I increase developer productivity and deliver business value right now?”
One thing I’d also avoid is solving far future problems, like the 2-year deprecation window I mentioned earlier. I reported something we should fix before March 2025 in February 2023. That’s over-engineering.
Over-engineering: Solving a far future tech debt (> 12 months).
If it requires action within 6 months, discuss and plan. If it’s 6-12 months, depends on the impact. If it’s 12+ months, that’s over-engineering.
Starter decision tree
If I could visualise an engineer’s decision-making about tech debt in the form of a decision tree, there would still be differences across different orgs. Some would have short binary trees (yes/no questions), while others would have deep B-trees, with each branch containing less obvious answers.
However, if I could picture an initial tree for a skilled engineer, it would look something like this:
This tree provides a set of simple questions to narrow down the problem into quick actions. Note that this is not a static tree to paying down tech debt. Engineers are responsible for continuously refining their decision-making process when assessing tech debt.
Take this starter tree as an inspiration and refine it as you go.
Your relationship with your product manager
The types of tech debt generated are somewhat similar across different tech companies, except for early-stage startups.
An early-stage startup is typically in the process of validating and finding its product-market fit (PMF). Product managers (PMs) are mainly focused on:
Identifying unmet needs in the market through customer research.
Developing a value proposition or hypothesis to be tested via an MVP.
In my view, a successful Product <> Engineering relationship is one where PMs can communicate an unmet user need, define a product vision and strategy, while engineers provide technical feasibility, review the roadmap, and build a solution. This is the most important relationship in any software company.
PMs trust engineers to deliver, while engineers trust PMs that their work serves the users.
In an early-stage startup, a product typically goes through multiple iterations (pivots), and so does tech debt. With each product iteration, new technologies or abstractions are introduced, codebase is rewritten, or architecture is redesigned.
If a product isn’t live and used by at least one customer, real tech debt hasn’t been created, and any previous debt isn’t worth discussing.
Once the product is live and being used by customers, then we can start measuring developer productivity. PMs trust your judgment as an engineer on highlighting impactful work that increases developer productivity and delivers business value. It’s important for both of you to be in sync so you can decide what should go on the priority backlog for the next sprint and what can be put on hold.
Invest in the PM <> Eng relationship. Staying in sync will make a PM’s decision tree for resolving tech debt similar to yours.
Wrap up
Paying down tech debts as an engineer require:
Evaluating the maturity of the product and solving today’s problems.
Being aware of over-engineering, i.e., solving far future problems (>12 months).
Thinking critically about the engineering cost beyond the individual, considering the business impact as well.
Building a relationship of trust and transparency with PMs to get buy-in.
One last thing: PMs trust your skills and opinions as an engineer. When discussing tech debt, make sure you highlight its relevance and impact on developer productivity so you both stay aligned while working on the product roadmap. Once you’re out of sync, discussions about tech debt will become ineffective and may raise eyebrows.
💬 Quick Note:
I recently launched a testimonial page for readers to share their thoughts about the newsletter, and I’d love to feature yours! You can add one through this link 🙌
Special thanks to Ingy E. for her latest testimonial!
FYI: New issues of The Proactive Engineer will be sent out every Friday at 12 PM GMT.
If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.
Tech debt is a fact of life. But, it doesn't mean we cannot tackle it at some point!
Great post! Also, can you walk us through how you built your testimonials page? Maybe an idea for your next post 🤗🤞