How I Learned to Stop Worrying and Love Tech Debt

Tech debt, the specter looming over every product team. It hobbles features, stresses developers, and frustrates customers. Everyone on the team is aware of it. Team members mention it in every retro, post mortem, and product quality review. Yet, it persists. Tech debt feels inevitable and immortal, a presence your team cannot escape.

Reframing the problem

But despite its bad rap, tech debt can actually be a good thing...when it’s managed well. As Sandi Metz says, “If it makes you feel any better, there's a way in which having a big mess is a sign of success. The reason your competitors don't have messes is that they went out of business. You won, and your prize is an application that betrays the ravages of time.” Tech debt comes from learning and growing. It will always be here; our goal isn’t to eliminate it but to tame it.

Learning to accept tech debt requires taking an honest look at your product’s needs and capabilities. But be careful here — it's easy to succumb to recency bias and over-index on the pain your team experienced in the last couple of sprints. Ultimately, the goal is to make it easier to forge new paths, not to retread old ground.

Taming tech debt requires a holistic approach that comes from a deep understanding of your customer needs, the product org’s priorities, and the overall business. It is impossible to understand the whole picture alone; you need to rely on your allies. On your journey to clean up the product, it’s easy to think of your Product Manager or your Engineering Manager as antagonists. Instead, they are critical allies. Leverage their knowledge and perspective to round out your own.

Accepting tech debt means acknowledging that no project will be a panacea. As long as your product is flourishing, there will always be another project to tackle. Let this free you. There will be more chances to address anything that you missed.

However, this means that one of the primary goals of any technical project is building and maintaining trust, so that you and your team can successfully tackle future projects. Trust starts with considerate collaboration. Start conversations with stakeholders early. Run ideas past your PM and EM and seek feedback from your teammates. When working on a team, thinking becomes a group activity.

Goals and expectations

Effective tech debt projects start with setting aggressive goals. It can be easy to fall into the trap of scoping your project according to what’s been approved in the past, prematurely cutting pieces off to try and make it fit. Roadmap planning is a negotiation for resources: the finite time, people, and money the company has to spread over an ever-growing list of competing priorities.

Let roadmap planning do its job: comparing your proposal to the others to determine how to make things fit. Trying to predict how leadership would prioritize your project means you might miss out on resources or not have anything to cut when a compromise is needed.

A good plan should generate a lot of feedback, sparking discussion about the roadmap, the overall technical health of the product, team strengths, etc. You must approach each of these conversations with honesty.

Overselling a project to try and get it approved creates a warped perception of the project in your Product Manager’s mind. They will plan based on the outcome you presented, expecting the project to unlock certain capabilities without further technical work. A quick way to lose trust is by setting up false expectations. Once trust has been lost, future projects are in jeopardy.

Set clear and honest expectations. Focus on the impact of upcoming features, which are projected to stay relatively stable. Be concrete and concentrate on outcomes:

• What do you expect this work will address?

• How much work is left to get the affected systems in an ideal state?

• How does it impact business goals?

• Does it make certain roadmap features easier?

• Does it unlock a class of work we previously thought was too costly to attempt?

Sometimes your plan will get rejected. Maybe the timing is wrong, or a critical stakeholder disagreed with your analysis. Whatever the reason, remember that what’s a ‘no’ right now could become a ‘yes’ in the future.

If you’re passionate about this investment, try pitching it again after some time passes and you’ve had a chance to refine it. If you can, put the plan aside and try to find smaller steps that can make the investment less costly or risky, such as work the team can tackle opportunistically during routine feature work.

A recipe for palatable plans

The future is impossible to predict three months out, let alone a year. But remember, your goal isn’t to be right; your goal is to avoid being wrong. Don’t seek perfection. Each project is a single step along the path. And making each step worthwhile requires knowing where you are going. Think of your long-term technical vision like a compass — it gives you a general sense of the direction in which your team needs to move.

By synthesizing what’s hurt you in the past with how your product will evolve in the future, you’ll be able to develop a more accurate long-term vision. Here you’ll find that the input of your Product Manager in this process is invaluable. Close collaboration with your PM will improve both your plan and theirs. It will provide natural, even obvious, opportunities to include your project in the product roadmap. Once you’ve found the opportunity, the challenging work begins.

Start by making your plan digestible. The unfortunate reality of making technical investments as a product team is that your first and ultimate priority is shipping features that directly impact business goals. Just as a customer-facing project may get scaled back or canceled when the company’s goals or projections shift, so too, technical projects often need to be left undone.

Not every change needs to be releasable, but a project should have regular “checkpoints” where the eject button can be pressed with minimal mess. Scuttling the project may involve rolling back code that was already committed. Don’t stress though — code is cheap. The important thing is that you learn something valuable from the attempt to make the next attempt more successful.

After you’ve broken down the project into digestible chunks, it’s time to make them more palatable. Your PM needs to be able to sell your plan to their boss or their boss’s boss. Don’t make them try to pitch it on technical merits alone. Start by focusing on the specific features and use cases that your plan will enable. Next, learn to leverage change.

A common belief is that tech debt projects should yield no functional change. But that’s an unrealistic expectation. Significant technical work in complex systems will cause accidental changes in functionality. So instead of avoiding change, take advantage of it.

Be strategic. As part of the tech debt cleanup, look for product improvements that harmonize with current priorities. Invite the design and product teams to help you identify small changes, like touching up some legacy UI or cleaning up an inconsistent interaction, in each step of the project.

Of course, more significant improvements are fantastic… when they spur on further technical investment rather than distract from it. The end goal is to find ways that you can capitalize on complementary product and tech investments like you would during regular feature work.

The missing ingredient: papercuts

You might be familiar with the papercut ticket. It’s the ticket that keeps getting reopened by your CS team, or the ticket you skip over in backlog grooming because there’s more critical work to do. You know you could fix it in half a day, tops, if you could just pull it into a sprint.

But with a bit of work, you can turn these perpetually overlooked tickets into a source of significant value. The key is establishing a sustainable process that normalizes pulling papercuts into your sprint planning. This process doesn’t have to be complex. For example, the process my team settled on is “pull in one quick win a sprint.” After a few sprints, we noticed that not only did pulling in a papercut or two had little impact on feature cadence, but also the tickets we had previously believed were unimportant had significant value for our customers.

Further, the decision to give papercuts value transformed how we talked about issues. Conversations about pain points that had previously ended in resigned sighs, resulted instead in a new papercut. That papercut turned into a discussion at the next backlog grooming. It became a tool for contextualizing our tech debt.

A good PM notices patterns. If papercuts keep getting closed because tech debt makes them too costly, sooner or later, PMs will need to understand why. It’s like a snowball rolling down a hill. With each task that’s closed, the abstract technical problem becomes a little more concrete, a little more tangible, until it’s unavoidable. Until the magnitude of the problem crashes down on you like an avalanche. Let the product argue that the team needs to address a technical issue so you can worry about how to handle it.