I once worked on a project where we weren’t able to think about technical debt until five years in.
Like many startups, we had to hustle to get off the ground. In those initial years, we didn’t have much time or capacity to even think about addressing the debt we accumulated.
And did it ever accumulate.
Touching one class in the code created ripple effects through many others. When new people joined the team, navigating it felt like sorting through dozens of unorganized filing cabinets.
We even had one engineer refactoring full-time. In one year, he untangled maybe 20% of the total volume of legacy code. At that rate, it would take another five years to do the whole system, and that’s not even counting the new technical debt generated during that time.
Not all examples are this extreme, but we all know technical debt is a major issue. However, many don’t. They’re more than prepared to make arguments about why, so the best you can do is prepare arguments against them.
Where most of these arguments come from
As you can probably guess (or may already know), the company’s business side creates most of the resistance to addressing technical debt. They’re not doing this maliciously, though – their job is to deliver products and features quickly.
So, if coding takes a month, sales reps will want the project finished within this timeframe. If you suggest addressing technical debt at the same time, it means adding a few extra weeks to the deadline.
While the improved code is attractive to us, they’ll resist, wondering what the point is if the product works on arrival without those adjustments. Your instinct will be to react impulsively, telling them how wrong they are and just how damaging the debt will be.
But all you’ll accomplish is a similar reaction from them.
Instead, learn what they’re really saying and speak to that directly. And you don’t have to spend a lot of your precious time on this task because most arguments boil down to a few common reasons people have against addressing technical debt.
“Technical debt isn’t our problem”
Some say sloppy engineers cause technical debt with bad code. Their follow-up is that since those engineers are responsible, they should care for the problems on their own time.
What they’re really saying
People who say this aren’t denying technical debt as a problem (as some do). But they’re shifting the blame to the engineers as if it’s something they can control. Their thinking is that if everything was done correctly, technical debt wouldn’t exist.
In other words, technical debt is the exception instead of the rule. And as you and I well know, nothing is further from the truth.
So, the trick here is convincing the people who make this argument that technical debt is a normal part of the process and shouldn’t be stigmatized.
What you can say back
Imagine you’re moving from one house to another. You need to transport a couch, and all you have is a Fiat 500. You can’t fit the couch inside, so you strap it to the top and start driving.
This looks funny, but what else are you supposed to do? You don’t have the money to rent a moving truck or the time, parts, and money to turn the Fiat into a minivan.
In short, the answer is you have to make do with what you have.
Blaming engineers for creating technical debt is like blaming the drivers for putting the couch on their car. In a perfect world, we’d have the time and capacity to do everything perfectly. But we don’t. We constantly have to make tradeoffs between perfection and speed.
Explain these concepts so the other side understands this, too, and you can start making decisions about how to deal with the problem together.
“We won’t meet our goals”
Imagine you’re talking to a project manager (PM) and ask for more engineers to be assigned to a difficult piece of technical debt.
“That’s not possible,” they reply. “If we assign more engineers, we’re not going to get everything done for our next milestone.”
What they’re really saying
This one’s easy to understand, but the argument is worth exploring further because why would anyone fall victim to short-term gains over long-term ones?
Because the industry supports this attitude. While you may stick with a company for many years, others won’t. And that’s if they have a choice. Sometimes, companies:
- Lay off workers
- Go out of business
- Merge and become redundant
- And so on
That’s not to mention people:
- Taking on short-term or part-time work
- Leaving the company for personal reasons, such as moving
- Or wanting to try something new
Regardless, would you care what happens to the work after you leave a company? No matter how passionate or dedicated you are, it’s not your concern anymore. Even if you are concerned, there’s nothing you can do about it.
Plus, a PM’s goals are always going to be different from your own, driven by a different perspective and pressure from their boss.
What you can say back
You have to make the case that if you don’t address technical debt now, the team will have even less time to make new things down the road. Older systems are just harder to:
- Use
- Maintain
- And learn
So, people waste even more time caring for the issues later than if they’d fixed them in the first place.
But this is as easy as telling a 20-year-old student they shouldn’t party so hard because they’ll need their body for years to come. Again, what’s the short-term benefit for them by considering the long-term ones?
No matter how you phrase your response, this is likely a discussion you’re going to lose. However, while you won’t get as much time or as many engineers as you’d like, you can get some.
Show them the value of assigning at least a few ICs to the work for however much time they’re willing to spare each month and settle for the compromise. Then, you can prove the value to them with the results the compromise created, and maybe you’ll get more next time.
“We have to think about survival first”
In most cases, you can advocate for addressing technical debt by appealing to your team’s long-term plans. Startups are the exception to this rule.
If you’ve never worked for one, know that they’re under incredible pressure to:
- Adapt
- Survive
- And find their market fit
What they’re really saying
Startups are in constant crisis mode. They don’t know what shape they’ll end up taking, let alone have the luxury of thinking about technical debt. Telling a startup to dedicate regular time to refactoring will only get you blank stares.
This is actually okay, though.
What you can say back
Imagine you’re a digital nomad.
You change where you live every year or so. With this in mind, why would you start buying furniture before you’re ready to settle down? You’ll just be wasting:
- Time
- Money
- And effort
In the same way, the first few years of a startup are deeply unpredictable. They change direction as they go along, so something that seemed like working code can become technical debt after a pivot. Immediately addressing it doesn’t make sense, then.
So, the solution is not to push for refactoring as much. Instead, spend time preparing to address the issue so that when it’s necessary, you’re ready.
Setting up a good logging practice is one step you can take. Then, at the very least, you’ve tagged and organized the issues for others to tackle later.
What to do if you can’t change someone’s mind
There’s almost always more room for negotiation and compromise than might first be apparent, but there will still be times when you won’t immediately change someone’s mind about addressing technical debt.
And this may have nothing to do with how well-crafted your responses are. Sometimes, people are just:
- In poor moods
- Not ready to hear another perspective
- Or unable to make the change you’re asking for, possibly due to directives from above
There are two things you can do at this point.
The first is to switch strategies and try to change their minds using metrics and numbers. This means learning how to measure the impact of addressing technical debt.
You may find this difficult at first, but you can measure most things, even if indirectly. Your main goal is having figures that show how addressing technical debt saves money down the line or will speed up other goals.
Again, frame what you say with problems they care about, and you’ll have more success.
The second is acceptance. Even if you’re the most well-spoken, convincing EM of all time, you won’t win every argument. Not every piece of technical debt you find worrying will (or even should) be addressed.
We talked earlier about compromise. Be prepared to offer this as well. When someone says they simply can’t prioritize technical debt at the moment, ask them what you can do to help them with their other priorities. This could very well speed those issues up (and do the same for freeing resources to address the debt).
Plus, they’ll be more likely to listen to you in the future once they’ve seen you’re willing to listen to them.
Ultimately, this mindset separates you as the EM from the engineers on your team. You have to balance competing priorities and make peace with suboptimal decisions. And you must become a master of salvaging imperfect situations.
As you do, you’ll find yourself living with those choices just a bit easier than before. You’ll start seeing issues you thought were the most critical alongside the ones others saw as the same, and you’ll be able to work together more effectively to find solutions to all of them.
The short version: prepare for resistance
You’re going to get pushback when you ask for resources to address technical debt. As the EM, you need to negotiate, inform, and remind your colleagues and upper management of how necessary it is to do so.
Some tips to do so are:
- Learn where these arguments come from: the business side of the company isn’t going to see things the way you do – understand their perspective so you can change it
- Convince them it’s everyone’s problem: inform business-oriented colleagues and partners that technical debt is a natural part of the process and not the fault of the engineers
- Convince them how it ties into meeting goals: people are going to say addressing technical debt distracts from wider goals – you have to remind them how not caring for it detracts from completing them
- Prepare for when survival mode is over: Accept that some companies (especially startups) aren’t ready to think about technical debt – nevertheless, suggest a logging system to make refactoring easier later
- Accept your losses and embrace compromise: you can’t win every battle, and sometimes, the best thing you can do is ask the other side what they need
Technical debt is well worth arguing for, but it is one of many problems and priorities companies face. Build relationships, show you’re a team player, and you’ll have more than enough good will when it comes time to advocate for this issue.
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.
