By
Tech debt is one of those topics that tends to make cameo appearances in leadership conversations. It takes center stage when mentioned but then recedes into the background – where it festers, grows, and potentially implodes – mostly due to misunderstandings about its nature and impact. It’s often mischaracterized as merely an engineering issue, leaving developers to grapple with it while the rest of the organization overlooks its broader implications.
I recently had the pleasure of discussing tech debt with David Haney, a senior engineering leader at Stack Overflow. Our conversation explored what tech debt is, why it occurs, its impact on organizations, and strategies for management and mitigation. Out of the many insights I gained, four key points stood out – points I believe every executive should understand and consider.
Tech debt is nebulous. Define it.
The term “tech debt” was originally coined by software developer Ward Cunningham to describe the “cost of additional rework” that results from choosing quick, suboptimal solutions over better but more time-consuming approaches. (David Haney refers to this concept as the “iron triangle” of good, cheap, and fast. Check out the video >)
Cunningham created a financial metaphor so that he could help non-tech stakeholders understand why resources were needed to address the issue. He explained, “With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money, you’ll be paying interest”.
Even though Cunningham’s definition provides an initial framework for grasping the concept of tech debt, the term has since evolved and taken on various meanings depending on the context and organization. For some companies, tech debt refers to code shortcuts or quick fixes that developers use to meet tight deadlines. For others, it’s about outdated legacy systems that are still in operation. Some define tech debt as the absence of proper documentation, while others primarily associate it with “bad code.”
It’s a slippery concept to pin down. Because it’s so varied and context-dependent, it is crucial to reach a common understanding of what tech debt means within your specific organization. Only then can you set the stage for informed, constructive discussions on how to effectively manage it.
It’s an inherent part of the creation process. Embrace it.
Tech debt isn’t just a byproduct of haste or shortcuts; it’s essentially a part of what David Haney calls the “creative art” of software development. Let’s face it, we’re only human, and despite our best efforts, we’re limited in our ability to predict future issues or craft flawless solutions.
Even when you’re not scrambling to meet quarterly goals or be the first to market, planning and coding any application or system inevitably introduces tech debt. This isn’t a flaw. It’s a feature of the ever-evolving nature of technology and business requirements.
Take Facebook, for example. Ryan Donovan from Stack Overflow mentions in his article, “If You Want To Address Tech Debt, Quantify It First” that Facebook was initially written in PHP – which hit a scalability wall as it expanded. It wasn’t a mistake. PHP was awesome for what Facebook needed at the time. But as the company grew, so did its tech and business requirements. PHP itself became the tech debt. Sticking with PHP would’ve been costly, not just in terms of maintenance and updates, but also in stifling innovation and potential user and revenue growth. (And demoralized engineers.)
Let’s get real -- the decision to migrate away from PHP probably wasn’t made lightly. The leadership team knew it meant temporarily sacrificing resources, possibly affecting revenue, and dealing with the complexities of data migration and system outages. Yes, it was a calculated risk, but it was aimed at long-term sustainability and growth. There’s always a trade-off.
So when we talk about tech debt, we’re not merely discussing an engineering challenge. We’re looking at a holistic business strategy. Ignoring or mishandling it can spell disaster, impacting your company’s viability, scalability, innovation, and bottom line. It’s not a ‘someday’ concern. It’s an ‘everyday’ imperative. We need to collectively anticipate it, embrace it, and plan smarter for the long haul.
It’s invisible, but consequential. Find and quantify it.
We’ve established that tech debt is an inevitable part of software development. Accepting that is the easy part. Now comes the tricky and challenging part of identifying and quantifying it. How do we do that?
To quote Haney, tech debt operates much like a “plumbing system.” You know the water’s flowing, but you can’t see what’s happening inside those pipes until there’s a leak or a blockage signaling that something is off.
At times, tech debt is glaringly obvious – think of an app that keeps crashing. These are high-priority issues because they directly affect the user experience. More often though, tech debt accrues quietly through a series of small, seemingly insignificant choices that compound over time.
So, how do you go about spotting this elusive rolling snowball? Regular audits are a good start. The exact approach will differ depending on your organization’s particular context. Proactively checking in with other departments like product, marketing, sales, and customer success can offer invaluable insights. Crowdsource information. What are their pain points? What inconsistencies or glitches are they noticing? And what about those closest to the code? What are we getting vs what we’re supposed to be getting? Haney’s advice is clear: consult the experts – the engineers – they’re the ones who can immediately tell you where the challenges lie.
Once you’ve identified your tech debt, the next step is to quantify it, even if it remains somewhat of a “black box.” It’s important to assign value to its impact on business outcomes. If a part of the codebase is breaking down and will take weeks to fix, it becomes imperative to calculate the business cost of both action and inaction. For example, “Fixing this code could increase the system speed by 50%, potentially boosting signups by 25%. Ignoring it could lead to a 40% drop in sign-ups by end of year.”
Quantifying tech debt in this way and communicating it accordingly not only makes its business impact explicit, but also helps leaders make informed decisions. After all, the premise of this entire post is that understanding, embracing, and managing tech debt is not just an engineering problem – it’s part of growth.
It’s not just a tech issue. It’s a business imperative. Own it.
I hope at this point we can see that tech debt isn’t an isolated concern that solely resides in the engineering department. Yes, engineers may be the first to grapple with it, but its ripple effects extend across the entire organization – touching every department, every team member, and even customers. Whether it’s delays in product launches, complications in customer service features, or missed sales targets, the impact of tech debt is far-reaching and multifaceted.
This isn’t about pointing fingers at engineering or labeling it as incompetence. Tech debt is a byproduct of growth and the inherent complexities of the technology landscape we operate in. It demands a holistic approach, one that sees leadership collaboratively working to define, embrace, measure, and most importantly, own it.
By framing tech debt as a collective responsibility and understanding its broader business implications, we can approach its management more strategically. It’s not a sidebar in an engineering meeting; it’s an integral part of your organization’s overall strategic planning and risk assessment.
When we truly own tech debt as leaders, seeing it as a business imperative rather than an “annoying” technical challenge, we’re better equipped to mitigate its risks and manage its impacts. And that’s how you turn a perpetual challenge into an opportunity for continual improvement, scalability, sustainability, and growth.
