If you’ve ever owned a house, how did that feel? 

If you’re like most, walking inside for the first time probably felt amazing. But even the best homes eventually need work. 

Some of this will be cosmetic, such as: 

  • Repainting a room
  • Installing different floor tiling
  • Or putting in new windows

But some of these tasks will be more urgent, such as fixing old pipes or replacing a leaky roof. In a perfect world, you’d have an infinite amount of time and money to do so. 

In the real one, none of us do. And because of these limits, you have to make hard choices. 

For instance, where does your money go? Probably to the house’s mortgage, food, and kids if you have them, although maybe not in that order. 

And what about your time? Aside from work, definitely to your kids (again, if you have them), but probably also to cleaning and home maintenance. You can’t complete everything for that last responsibility all at once, so you have to determine which jobs are the most important and urgent.

Doing this requires knowing what:

  • You want
  • You actually need
  • Has to happen first, and how you’d go about the work

As an engineering manager (EM), you already have or will face the same difficulties and choices with new products and features and the technical debt they collect over time. And effectively managing these issues requires a structured and careful process.

1 - Negotiate for resources

I’ve written before about the reasons you need to add technical debt to your list of priorities. This should be obvious to experienced EMs. The problem is that what’s obvious to EMs isn’t obvious to everyone, including upper management and project managers (PMs). 

So, the first step to effectively managing technical debt is negotiating with decision-makers to allocate resources to the work. Getting them to agree to those resources (namely, time, people, and money) sometimes takes some convincing, though. 

What you’re up against is the fact that if engineers work on technical debt, they’re working less on new features and products. In other words, they’re not focusing on tasks that generate direct value for the company, so this can be a hard sell to those charged with overseeing and increasing that value.

You know what kind of effect technical debt can have in the long term, but that’s also why technical debt isn’t so obvious to everyone else. Ultimately, they think nothing has to be done because its short-term effects are minimal or even unnoticeable.

So, your job is to show them how the slowly rotting roof of the house will eventually lead to destructive leaks. And you need to do that before those leaks happen as well as convince them this issue is more important than buying a new (and also very necessary) car. 

You can see why this might not be so easy. But having a log of the debt helps.

2 - Track and categorize the debt

You can’t address a problem if you don’t know what exactly needs fixing. You’ll also have an easier time convincing others to focus on technical debt with a clear representation of the number, depth, and impact of the issues you’re facing. 

So, engineers must write down, tag (more on this below), and store everything they consider technical debt in a log. And everyone who works with code should know: 

  • Where this log is
  • How to access it
  • And how to update it

Encourage your engineers to take these steps instead of trying to refactor code informally as they go along. As you know, this can be a big temptation. 

But trying to address technical debt spontaneously often leads to wasted time. Logging things immediately should instead free those engineers to focus on the work at hand, knowing someone will refactor the code later.

Also, don’t focus too much on the tool you use for the log - using something like Github issues should be more than enough to get you started. The important thing is having one that works and using it consistently.

The log is also only one piece of the solution – the other is organization. You can choose how to categorize technical debt as works best for your needs, but some options include:

  • Services affected
  • Severity
  • Business impact
  • Appetite (see below in “4 - Prioritize”)
  • And so on

These tags save you a lot of time when you or other team members review the log to see what’s in there. They also help you prioritize tasks more quickly.

3 - Assess work demands

Before you begin addressing technical debt, you have to figure out what’s even required and why.

So, you need to ask yourself questions such as:

  • How complex is the issue?
  • Is there a clear solution, or will your engineers need to do some work to produce ideas?
  • Will the task take a few hours, days, or even months? 

You’ll also need to consider:

  • The impact: refactoring code can affect multiple parts of the project in different ways, so account for this beforehand
  • Who would best handle the work: a junior engineer might be able to handle the task, but it may also require a system architect – keep in mind that their salaries will differ widely 
  • The need for a regression test: relevant if you’re working on a critical part of the project infrastructure and a process that could add a week (or weeks) to the job
  • And how the work will affect other team members: an engineer may need an hour, but others may need days to navigate their changes

4 - Prioritize

Prioritization is an art. There are no exact rules you can use in every situation. Your decisions ultimately depend on factors like:

  • What resources are available
  • What sections of your product or feature are in development
  • How experienced your team is
  • What your long-term goals are
  • And more

As the EM, your job is to see the big picture, consider these and other relevant factors, and determine the 5-10 things you need to tackle first. 

An important aspect of this is “appetite.” 

By this, I mean how much time you can stomach spending on a task. Knowing your appetite means that if you figure out a task will take too long, you can confidently de-prioritize or shelve it completely. 

Another is severity. 

Some issues are critical, others you can live with. If an app crashes on startup, we can agree that’s critical. But if there’s just one specific screen only 1% of users visit, consider if it can wait a month or two before you address the problem.

5 - Make a plan

Once you’ve figured out what you need to do first, create a plan to actually do it. If you’re new to management, this part can feel overwhelming. Especially when the technical debt is large. 

But that’s just it – you don’t want to tackle the problem as one big chunk. You have to break the work down into smaller, more manageable pieces. 

You also have to make a preliminary timeline. And keep your limited resources in mind. 

For example, if your engineers are on duty 40 hours a week, meetings, communication, and so on will take up a lot of that time. So, you and your fellow managers have to share what’s remaining between new work and addressing the debt. Or, as an alternative, you could have dedicated people working on the issue (usually as a rotating duty).

This includes consulting with PMs to schedule technical debt work into specific engineers’ timetables. Complex cases might require a specialized or senior engineer, but securing their time may be difficult as they’re highly coveted.

You could also recommend people who are experienced with a particular piece of technical debt, as this causes fewer complications and speeds things up. 

Or you could assign a less-experienced engineer to the task. This would help them improve their skills and strengthen the team in the long run. However, you would have to allocate extra time to account for their learning process.

6 - Know when to stop

As you well know, engineers are perfectionists by nature. They think anything imperfect or not otherwise up to their standards is technical debt and should be: 

  • Addressed
  • Fixed
  • Refactored
  • Or changed 

But even if you address everything engineers call technical debt, all you’ll ever do is improve already functional systems. They often have in mind a perfect version that’s impossible to build or would take an infinite amount of time to work on. 

But you know this doesn’t work in competitive business environments. Your team needs to create new products and features, not merely improve on what’s already been made. 

So, as the EM, you have to balance perfection with completion. In other words, you have to keep that big picture in mind and help your engineers see it, too. 

And you’ll need to consider what limits your engineers will be okay with to increase the chances of them accepting that compromise. For example, you might suggest giving them 30% of their remaining 20 hours this week to work on the issue. 

Unfortunately, you’ll still often have to fight with them to stop working on debt. To make this easier, highlight the constraints on your resources and normalize “good enough” instead of “perfect.” 

Otherwise, you’ll never get anything done, even dealing with new technical debt.

The short version: rot is inevitable – inaction isn’t

Addressing technical debt is about more than just resolving it. You have to create a pipeline that allows the work to get done. As the EM, this is your job. 

You facilitate this process by:

  • Negotiating with upper management: you need their approval to allocate resources for addressing technical debt
  • Tracking and categorizing: make a system for logging existing technical debt and tagging it by type
  • Assessing the work: determine what will be required in order to resolve technical debt
  • Prioritizing: decide which tasks should be addressed in what order
  • Making a step-by-step plan: break the work down into steps, create a timeline, and collaborate with PMs to schedule these tasks into specific engineers’ timetables
  • Knowing when to stop: understand when the job is done “well enough” and make sure engineers don’t work on tasks endlessly

Being on top of your team’s technical debt is an important task. You bridge the gap between technical specialists who would be perfectionists if left alone and fellow managers who might not see the need to do something about it. You are uniquely positioned to keep this process running smoothly for the long haul.

Want more tips on leading effective software engineering teams?

Join my newsletter if you’ve found this content useful

Originally published on Medium.com

Content in this blog post by Alex Ponomarev is licensed under CC BY 4.0.