The constant feeling of pressure to develop features as fast as humanly possible should be familiar to anyone who has managed a software team. It comes from the culture we work in, from within ourselves, and mostly — from leadership teams. Even the most empathetic business executives are prone to exert pressure on their engineering teams. This makes it hard to argue the cost of consistently prioritizing speed over quality.

In an ideal world, your team would work at a sustainable pace, methodically producing and deploying thorough, maintainable, tested code. They would calmly hit every milestone while keeping your software ecosystem completely free of technical debt.

But we don’t live in that world.

Even if you’ve been finding time in between the big tasks for minor refactors, dependency updates, and security patches, the encroaching reality of technical debt has a way of eventually catching up with you. When the pile of debt finally gets too large to ignore, you know it’s time to stop, take stock, and pay down the debt before your development process grinds to a halt.

But how do you get your boss (or your boss’s boss, the board of directors, or an investor group) to approve the necessary resources?

Leadership’s Perspective: Go Fast, but Don’t Break Things

Paying down technical debt requires slowing down or pausing your team’s regular work stream. When your biggest customer is asking for new features, it can be hard to tell them they’ll have to wait. Slowing down is good for code quality, but bad for the timelines and budgets that make leadership look good.

When you prioritize speed over quality, ultimately, you pay in the form of technical debt. And left long enough, the fallout from technical debt will cause more pain than the proactive rework will.

Leaders on the business side can be uncompromising in their mission to go faster no matter the cost. You’ll likely hear a variety of arguments from your boss about why there’s no way to pay down technical debt:

• “We just have to get through this next milestone.”
• “We’ll handle it after the next round of funding.”
• “We have to ship this, we’ve got to do that, this needs to get out the door for a customer…”

There will always be a reason to postpone. Leadership wants speed, but they also don’t want things breaking. And left unchecked, technical debt will, without fail, cause your codebase to break at some point. Luckily, there are tactful arguments that will convince your boss to see it from your perspective—no matter what type of leadership style they have.

4 Arguments for Funding Technical Debt Reduction, Based on Your Boss’s Personality

As a software developer, you’ve got a keen eye for details and you’re observant. So you likely have a good read on your boss. You might not know everything about them, but we bet you know enough to craft the most compelling argument to fund technical debt paydown.

Depending on their leadership style, work habits, and general level of fear and anxiety, there’s an argument for paying down technical debt that will resonate.

1. For The Organized, Rational Boss: The Low-Hanging Fruit Argument

Is your boss level-headed, logical, and generally easy to work with as long as you have a good reason for choices? Then you should employ the low-hanging fruit argument.

Find a tangential task — like a minor redesign of a feature — that touches the code you need to fix. Frame your argument like it’s an inconvenience not to do it. “While I’m tinkering around in there, I might as well take a bit of extra time just to fix it up. It’s irresponsible not to!”

This argument appeals to your boss because it’s framed as a convenient effort with no real downsides.

2. For the Eternal Optimist Boss: The Carrot Argument

Is your boss chipper even before they’ve had caffeine? If you’d characterize them as a glass-half-full optimist, then persuade them with a vision of a spotless codebase in the future.

The carrot argument is for those with a rosy outlook — “If we take the time to get the house in order now, it will be in good shape for a long time. Doing the rework now avoids risks, and might even save us some change on the AWS bill!”

This argument works because it focuses on the benefits of rework, and makes a case for what your company as a whole can gain from cleaner code.

3. For the Skeptical (Maybe Cynical) Boss: The Stick Argument

If your boss can’t be swayed by anything other than the hard facts, then the stick argument is for you. The polar opposite of a carrot, this argument focuses on the worst case scenario. What will go wrong if you never pay down your technical debt?

This argument works because you’ll weaponize their cynicism against them. “Every time someone comes to you with a new feature request, we assume more risk. Eventually, entropy will take over and we won’t be able to push any code. Do you want to explain THAT to the board?”

Bonus points if you include a timeline to go with your estimated date of failure … and maybe start a pool with the other developers.

4. For the Irrational, Doomsday-Prepper Boss: The Gone Tomorrow Argument

For the worry-wart, doom-and-gloom boss who always fears the worst possible outcome, lead with the most unlikely yet scariest possible outcome — “What if the developer who holds the keys to the code gets hit by a bus tomorrow?”

It’s a bad situation to be in. If one of your developers was told to “go fast” they might have gotten it done. But if they aren’t there to explain their work, it might be impossible to fix. So encourage your boss to seize the opportunity to fix it while you can!

How to Mitigate Future Technical Debt Battles

Nearly every application, team, and company accrues technical debt over time. It’s a natural, unavoidable, and sometimes even healthy byproduct of a focused and productive team.

Think about it like this: If you have a friend with one million dollars under their mattress, they are missing some ripe opportunities. Sometimes you need to take on technical debt to get to a minimum viable product, or work toward a specific deadline, after which you have planned time for cleanup.

Working with leadership to develop criteria on when it’s ok to assume technical debt and when you need to start paying it off is the first step.

Then, the developers need to create a routine that keeps the codebase clean. For some, it’s incorporating a week into a sprint — like a week 6 if you run 5-week sprints — where the main focus of the whole team is debt repayment.

If you have the kind of team where everyone is working in the same monolith, you can stagger developers to achieve a real-time debt payoff cadence. Structuring the workload so one engineer is always on debt cleanup duty can be a good option.

Open Lines of Communications Make Your Boss Your Ally

At a certain point, technical debt becomes like building a bridge. Pushing more features without resolving the bugs is like paving the road before finishing the supports. Eventually, it’s all going to collapse. Instead, get yourself and your team to a point of scalability. Then talk openly about the technical debt and address it in a proactive way, to avoid heading back to the battlefield against your boss.