How to Persuade Your Organization to Pay Down Technical Debt

We don’t want to invest in the past, right? Investment should be all about the future.

Not always.

At last week’s LeadDev Live, Lisa Karlin Curtis, product engineer and employee No. 2 at Incident.io, gave her arguments in favor of paying down technical debt. And she offered engineers techniques to persuade others to invest in that debt — even when everybody else just wants to focus on shiny new features.

Technical debt is an umbrella term for what’s leftover after all the short-term decisions an organization makes for quick feature wins. Also called design debt or code debt, it’s all the things a team should recode or refactor, that takes time and doesn’t automatically add customer value.

Unless dealing with it is built into a digital transformation strategy, technical debt becomes a “mañana, mañana” situation, constantly put off because it’s not usually simple to fix. That’s why it’s usually found among the bug reports at the bottom of your backlog. As more organizations go cloud native, technical debt will only keep growing.

But, as technical debt accrues, the risk of something going wrong increases. This usually appears in the form of operational risks, like something malfunctioning or struggling under heavy loads. This makes observability uncertain, which in turn increases the blast radius when things inevitably go wrong.

‘An Unfair Fight’

Engineers need to learn to speak up on behalf of paying down technical debt, Karlin Curtis told the LeadDev Live audience.

Prioritization meetings come with a natural imbalance or asymmetry of skills, she said. Product managers bring communication as a core skill. They often come from consulting roles where comms, coaching and continuous feedback are all part of the day-to-day. On the other hand, most engineers don’t have exposure to this kind of conversation until they take on a leadership role.

“Ultimately, this makes our meeting a bit of an unfair fight,” Karlin Curtis said. “The product managers have brought guns and us engineers have just picked up a kitchen knife and we may not be holding it the right way round.”

And so the technical debt piles up and prioritization meetings center on building new. One thing to point out, the speaker suggested, is how much technical debt can impact the quality of delivery when parts of a feature get cut because it’s simply too hard to update in the current state of architecture.

Technical debt also affects morale, Karlin Curtis said; no one likes being woken in the middle of the night, especially for something avoidable.

“Delivery speed and quality often ties closely with developer happiness and satisfaction,” she said. “Most engineers like building things, so having something that slows them down or makes that harder isn’t well received.”

Empathetic Engineers Ease Arguments

Drawing on her own previous experience as a consultant at Accenture, Karlin Curtis argued that empathy is a core skill to bring to any prioritization meeting.

Start by explaining why you think a change like technical debt is important. Your gut feelings are of value, but whenever possible you need to understand and explain the impact of not investing in paying down that debt.

Next, it’s essential to identify all the stakeholders ahead of the meeting — not just the product owner. Be aware of anyone who influences the final prioritization, even if they aren’t in the room.

“If you can, try to foster a culture of one decision, one owner,” Karlin Curtis said. “But there might also be people who aren’t the explicit owner on paper but [who] hold a lot of power and may block you pursuing something, even if it’s not officially their call.

“Those people are just as important to persuade, and, as much as you might not like that they’re wielding their power in this way, you’ll have more success if you identify and accept it, than if you try and fight it.”

For each decision-maker, ask yourself:

• Why does it matter to them?
• What does success look like for them?
• Why is it even relevant to them?

In her work at Accenture, consultants were asked to always preemptively answer “So what?” Do the work for your counterparts, laying out why it’s a good idea, not just from your perspective, but for them, quantifying specifics whenever possible.

Karlin Curtis laid out three stages of the art of persuasion:

• Basic persuasion: The billing platform is a mess and we need to fix it.
• Intermediate persuasion: The billing platform is really hard to work with and it’s making delivering new features really slow.
• Advanced persuasion: The billing platform is really hard to work with and if we don’t deal with it it’s going to make features like X, Y and Z take double the length of time, and that is going to make it harder for us to reduce churn this quarter.

Ditch the Jargon

Another thing you have to do is plan ahead what not to say, Karlin Curtis said. Not everyone in a prioritization meeting cares about every technical detail. An engineer must learn to highlight key technical points and then connect them to crucial business arguments.

“For some reason, there is a universal temptation to explain the technical stuff that’s actually wrong in excruciating detail,” she said. “If your audience is technical, that information might be useful to them so that they can understand the impact of the mess themselves, but, to most people, that information is just not relevant.

“If it doesn’t help them understand why we should do the investment, it won’t persuade them that you’re right, and you’re wasting precious air time on having a rant. Probably at the expense of some poor engineer who made a pragmatic choice a couple of years ago. If you get really unlucky, that engineer might have been you.”

If you need to get all the technical details out of your system before a prioritization meeting, she suggested taking a colleague out to lunch for that. And then dedicate time to thinking about how to help the product manager understand where you’re coming from — in their own language.

“For some reason, there is a universal temptation to explain the technical stuff that’s actually wrong in excruciating detail …  but, to most people, that information is just not relevant.”

— Lisa Karlin Curtis, product engineer, Incident.io

Also, she advised, pick your battles: No matter how respected you are, you have limited political capital. “You should spend it on the things that matter to you, not on something frivolous, like indentation rules,” she said.

Championing investment is usually an exhausting endeavor.  Karlin Curtis said, and not a particularly rewarding one. You have to be able to know when it’s time to give up and walk away, before you find another reason to contribute to your own burnout.

Remember, both sides have the same goal — to build a maintainable and reliable product that will delight users. But they come at this friction in a different way.

“As soon as it feels like a battle, you’ve already created a broken culture that is really difficult to recover from,” Karlin Curtis said. “You have different roles for a reason.”

“The product manager is there to consider a whole range of inputs and make decisions about product direction and strategy. The engineers are there to build something that provides value to someone, and can be maintained so that it will continue to provide value in the future.”