Chapter 1: Understanding Technical Debt

Technical debt is a term commonly encountered in the realm of digital product development, representing a challenge that we cannot ignore. For product managers and digital leaders, grasping the nuances of technical debt is essential—not merely to resolve it, but to effectively manage it.

One of the most pervasive misconceptions is that technical debt is purely a technical problem. In reality, it influences strategy, product development, and ultimately affects all organizational objectives. Unfortunately, many individuals fail to recognize this or simply choose to remain oblivious. While ignorance might be bliss in other contexts, it certainly is not here.

To illustrate the typical dynamics between product and engineering teams, consider this classic scenario:

A Typical Technical Debt Narrative

Once, a product team aimed to enhance a feature used by multiple clients. This initiative was included in the roadmap, receiving stakeholder approval along with some revisions. Naturally, any roadmap exercise invites changes from stakeholders.

The product team approached the engineering team to outline their plan, seeking an estimate on the timeframe required to realize this roadmap goal. The engineering team analyzed the strategy, expressing their concerns. They identified potential repercussions in one product area and noted existing code quality issues.

“We need to tackle the technical debt in this segment of the code.”

From this point, a tug-of-war ensues between the product and engineering teams. The technical team is eager to address the issues, which complicates various levels of design, architecture, and coding. This, in turn, affects their estimates and overall product enhancements.

The development team faces challenges in predicting changes since they are dealing with code that is not well understood. Meanwhile, the product team and management are focused on delivering value swiftly, unwilling to accept any obstacles.

Often, the prevailing mindset is that the tech team is obstructing their path to success. The product team presses for estimates, emphasizing the urgency of their company’s goals and mission, while making the engineering team commit to a timeline. Eventually, the engineers relent, understanding that fighting against this current is futile. They provide estimates that lack credibility.

Both teams are aware that these estimates are largely meaningless, yet the product team believes they have secured what they wanted. Unfortunately, as the project unfolds, issues arise, leading to delays in delivery.

This creates a vicious cycle, escalating conflicts and straining relationships. Everyone feels the pressure from the other team, resulting in dissatisfaction and disengagement, which compounds bad debt, raises development costs, and compromises quality.

Misunderstanding Technical Debt

This scenario exemplifies the typical relationship between product and technical teams. The core issue lies in the widespread misunderstanding of technical debt, particularly among those who wield decision-making power regarding roadmaps and priorities.

Technical debt is merely the visible portion of a larger iceberg, concealing deeper organizational challenges. A former colleague of mine, who worked on transitioning a legacy system to a modern platform, aptly stated:

"As an engineer, I struggled to convey to the business why addressing technical debt was essential. It became clear that everyone is motivated to deal with it due to its financial implications and its potential to significantly impact the business, such as losing customers due to poor experiences or making software less secure and efficient." — Vedrana

The blame does not rest solely on product, design, and stakeholder teams; it is also prevalent among tech teams, which often misinterpret the concept of technical debt.

What Is Technical Debt in Software?

Technical debt serves as a metaphor—it is not a tangible entity. The term was coined by Ward Cunningham, one of the Agile Manifesto's founders, in a report presented at OOPSLA 1992. Here’s Cunningham’s explanation:

"Shipping first-time code is akin to incurring debt. A small amount of debt can expedite development, provided it is repaid through refactoring. The real danger arises when that debt remains unpaid. Every minute spent on suboptimal code adds to the debt's interest. Entire engineering teams can become paralyzed under the burden of unrefactored implementations."

This excerpt is from a case study by Dave Nicolette, who expands on Cunningham's insights.

The Roots of Technical Debt

To understand the implications of technical debt, it is essential to consider its origins. I firmly believe that strategy, product design, and development significantly influence technical debt.

The burden of technical debt cannot be placed solely on engineering teams; it affects everyone involved in the product lifecycle. Code, design, architecture, and the product itself are interrelated entities that evolve from the moment they are created. Debt is an inevitable part of this evolution.

Much like human decisions incur future liabilities, every choice made in product development can accumulate debt. For instance, excessive drinking leads to a future cost in terms of health, just as honing a particular skill opens new opportunities.

Companies, products, and codebases all accumulate debt. It is not merely a matter of poor code or quality; there exists a correlation between technical debt and decisions made throughout the software development process.

The Importance of Addressing Technical Debt

Technical debt accumulates over time, much like financial debt. Its effects ripple through the software development team, impacting code quality, increasing development costs, and altering the development process itself.

Agile teams often feel overwhelmed when technical debt ratios spiral out of control, affecting the entire software development lifecycle. For digital leaders, understanding technical debt is a critical competency that contributes to productivity. This expertise allows them to grasp the implications of technical debt within their organizational context.

The analogy of financial debt serves to illustrate the importance of understanding investments and financial choices. It has always unsettled me that discussions around technical debt are limited to engineering contexts.

To foster an engaged culture surrounding digital products, we need to redefine our vocabulary. The semantics of the term "debt" should encompass more than just technical aspects.

Why You Can’t Afford to Ignore Technical Debt

Various factors contribute to the accumulation of technical debt:

#### Resource Constraints

Much like a poker game, we cannot change the cards we have been dealt. Complaints won't alter our situation; we must accept the reality of our resources.

In our digital endeavors, we face limitations in time, talent, and finances. These constraints shape our products and cannot be avoided; instead, we must manage our debt responsibly.

#### Market Pressures

Our work operates under time constraints. The market does not wait for us; it continuously evolves. Competition, emerging technologies, and market dynamics can render our previous strategies obsolete.

Each decision influenced by market changes can lead to the accumulation of debt. Reflect on the last time the sales team pressured you for new features to compete with a rival.

#### Evolving Requirements

Developing products is akin to pursuing a moving target. Just when we feel we've achieved stability, everything shifts again. The landscape is fast-paced and ever-changing.

This evolving environment means that customer expectations are also in flux, leading to new demands and, consequently, more debt.

#### Innovation Over Stability

Startups and new projects often resemble wild horses—untamed and unpredictable. Goals remain unclear as we build foundations for potential successes. Rapid market learning often demands changes that accumulate debt.

Companies that scale often do so without adjusting their products to address underlying issues. Slack, for example, began as a browser-based application and had to undergo significant refactoring to accommodate its explosive growth.

#### Complexity

I liken the role of a digital leader to that of a quartermaster on a ship, tasked with navigating through a labyrinth of challenges. As a product evolves, it becomes more complex, with added features and dependencies.

This complexity means that even minor modifications can take considerable time and effort. Technical debt can ensnare teams unexpectedly, much like a spider web.

In the next section of this article, I will delve into the various types of technical debt, the trade-offs involved, and effective strategies for managing it.