How to Get Buy-In for Addressing Technical Debt
How to Get Buy-In for Addressing Technical Debt
Here are some strategies for getting those in the highest levels of leadership to support and understand addressing technical debt.
Join the DZone community and get the full member experience.Join For Free
If anyone understands the immediate impacts of technical debt, it's development teams. Engineers and engineering leaders experience firsthand the slowdowns, the death-by-a-thousand-paper-cuts, and in drastic cases, the soul-sucking repercussions of unmanaged technical debt.
But communicating those results to non-technical stakeholders is a challenge. CTOs might understand it if they were once coders themselves. Anyone without intimate or necessary knowledge of the codebase, though, is unlikely to comprehend the pain caused by technical debt. They may simply never understand (from their perspective) why engineers always make messes that need to be cleaned up later.
The key is to reframe technical debt away from the debt itself and into terms that matter to other key stakeholders. That's how you get organization-wide buy-in for addressing technical debt, as well as the trust that your team is actively contributing to the company's forward-looking goals.
Translate Technical Debt Into More Relatable Terms
You may understand full well that technical debt in the codebase is slowing down your team's ability to sustainably deliver product at full speed. But when you tell executives that you need to tackle a big refactoring project that will take months, all they're likely to see is dollar signs going down the drain.
What they need to hear instead is what you are delivering to the organization.
"We're fans of the cost of delay model," Zuber says. "If you can quantify these problems, it's a lot easier to have a conversation. We always try to convert everything into dollars."
The specifics of this conversion will depend on your circumstances, but let's say that the technical debt is causing quality issues that are driving customers away. That's fairly simple to convert into dollars lost.
"Or developer time," Zuber says. "How much time are we spending just maintaining our build platform or doing manual work in this area? Manual work is a form of technical debt, and if you can categorize that and itemize it, then you can show where that eventually converts into better product delivery."
In other words — to continue the financial metaphor we so often see with "tech debt" — you're investing in future rewards, rather than paying down past debt.
"You're looking at things in a bigger context, from the business side of it," Goulet says. "Once you have that kind of analysis, it's a matter of translating it. Get a good understanding of what the business wants. More customers? Awesome. We can increase the number of concurrent users, but we need to [tackle technical debt] first in order to do it."
Goulet recommends developing empathy for the other stakeholders in order to communicate better with them.
"Seek first to understand and then be understood," she says, crediting Stephen Covey. "Understand what it's like to be a business owner first, or to be a CFO. Practice having empathy for making business decisions. Do some research on what kind of pressure they are under or what kind of problems they are trying to solve. Then take your problems and translate them in a way that is going to make sense to them."
"Do some research on what kind of pressure they are under or what kind of problems they are trying to solve," Goulet says. "Then take your problems and translate them in a way that is going to make sense to them."
Not only will converting technical debt into more meaningful terms make it much easier for you to earn buy-in, but as a bonus, it will also help you ensure that addressing that particular technical debt is actually impactful right now. If you can't make a business-driven case for why your team's resources are best spent on that project, then you know you're working effectively — and you now know when in the future that project will be more necessary than it is right now.
Present the Value to The Whole Organization
One of the reasons that technical debt accumulates in the first place is that very few organizations have teams or individuals whose purpose is reducing that debt. Everyone has a mission-oriented around developing products, enhancing the customer experience, bringing in sales, but no one owns technical debt.
"Teams are never necessarily owned by someone who shows up and says, 'Okay, great, I'm going to take the time and fix this problem from a cost delay or investment perspective,'" Goulet says. "'It's not that valuable for my team, but it's going to be valuable for all the teams.'"
Even if you don't have the power to be that person, you can always advocate for that perspective. Essentially, you're moving beyond showing the value in meaningful terms like dollars or customers, and demonstrating that this one team's efforts are going to ripple benefits across the organization.
"Impact is the common language that slices across teams and functions." - Jean Hsu
"You basically need some management support to say you should carve out time and not do the thing right now that your team has been tasked with, so that you can help all of us across the organization," Goulet says. "Someone to recognize this cross-team thing will be more valuable to us as an organization."
Pasqua accomplishes this sort of buy-in by planning larger technical debt initiatives at the same time and in the same way that her company plans its product strategy and roadmap.
"Whether that's monthly, quarterly, or every half-year, we do it hand-in-hand and we do it with the same visibility," she says. "And we always relate back to why these bigger initiatives are important based on the company strategy, the product strategy that's being planned at the same time."
Rebrand Technical Debt
No one likes having debt, and paying down debt is hardly a sexy endeavor. Rather than translating technical debt into other terms, then, another approach is simply to reframe the idea of technical debt itself.
"We've branded it here as continuous product health," Pasqua says. "We get people in a room and talk about technical debt and everyone's shoulders slump. But we tried out the notion of continuous product health. Everyone loves that, right? It's helped get people to think about it as just a healthy, happy part of what you do every day. Just the name alone has worked."
Goulet echoes that idea, as well, with certain kinds of technical debt. There are problems that need fixing, and then there's always ongoing maintenance. Her organization calls that latter kind "self-care."
"You don't ever stop eating healthy if that's a goal of yours," she explains. "It's just that you can go into maintenance mode as opposed to losing-weight mode. We found that metaphor to be more effective than the debt metaphor as well. Instead of focusing on what you don't want, empowering people to focus on what the outcome will be and the benefit of it is powerful."
So try one of these metaphors, or come up with your own, to reframe the onerous-sounding "technical debt" with a more constructive concept that can be supported organization-wide.
Make Sure You Have Buy-In from Your Engineers, First and Foremost
In trying to earn buy-in for addressing technical debt, we think about needing to convince or persuade our managers, executives, leaders, and other higher-up stakeholders. But what about the engineers on our teams?
It's easy to assume they will support any initiative to tackle it. After all, they're feeling the impacts of the tech debt most directly. They're the ones suffering all the little inconveniences along the way to bigger repercussions.
But you know what they say about assuming: don't.
"I definitely see much more in needing to convince the business and product side of things," Pasqua says. "But if you're not aligned as an engineering team that this is important, you have a fundamental cultural problem that your leadership should be addressing before you even try to sell it to Product or the business outside."
You need your engineers on board to make any debt initiative matter. Making sure they understand the need for such a project, and are in support of its outcomes (even if not everyone relishes the refactoring work that goes into it), will be invaluable once you've gotten buy-in from everyone else.
Besides, you may have menders on your team already — those developers who thrive on the challenge of addressing technical debt. We'll celebrate those engineers in our next post on technical debt.
Published at DZone with permission of Jennifer McGrath . See the original article here.
Opinions expressed by DZone contributors are their own.