Technical debt is a concept we are all familiar with when building digital products.

It's something we have to live with. As product managers and digital leaders, we must understand how it works. It is a skill in itself to develop.

Not how to solve it but how to manage it.

The biggest misconception is that it's a technical issue. Whatever people think, Technical debt impacts strategy and product. And it affects all other company goals.

Yet most people don't understand it, or they don't want to.

Ignorance is a blessing, but not in this case.

Let me show a classical relationship between the engineering team and strategy.

A classic technical debt story

Once upon a time, a product team wanted to expand the capability of one feature used by several clients. They put it on the roadmap. The stakeholders agreed and sponsored it with some modifications.

It will not be a roadmap exercise without change from the stakeholders.

The product team turned to the engineering team to explain their plan. They wanted to run a simple exercise: estimating how long it will take to make the roadmap a reality.

The engineering team analyses the strategy and explains their concerns. Their first analysis shows the impact on one product's area and the code quality.

"We must address the tech debt in this part of the code."

Release the Kraken!

From that moment, the product and software development teams enter a tug-of-war.

On one side, the technological team want to address it. It creates complications at different levels, whether in design, architecture or code. In return, it hurts estimates and improvements of the product.

Worse. The development team has trouble estimating the changes as they will change a code area that is not understood.

The product team and the management are pushing to deliver value faster. They don't want any blockers.

The typical mindset is that the tech team is blocking the road to their success.

The product team starts their push for estimates. They explain the company's urgency, prioritisation, strategy, goals, and mission. They explain the timescale and make the engineering team commit.

The engineers cease to resist and give to the product team what they desire. With their experience in those kinds of situations, they know it's a lost battle. They provide estimates that are worth little.

The engineers know the estimates are worthless. And the funniest, the product team knows that, too.

The product team has what they want, or at least it's what they believe. But, during the delivery, issues occur, and the project is late for delivery.

There is a vicious circle occurring, creating conflicts and worsening relationships. Everybody feels pushed and pressured by the other teams. It results in unhappiness and disengagement, creating even more bad debt, increasing development costs and compromises in quality.

The situation above is a classic example of the relationship between product and tech teams.

The real problem with this context is that the concept is misunderstood. It is most misunderstood by people who have the power of decision on the roadmap and priorities.

Technical debt is just the tip of the iceberg, masking other organisational problems and issues.

Here is a quote from one of my ex-teammates who worked with me in moving a legacy system to a new experience:

"As an Engineer, I always found it hard to explain to the business why we must deal with technical debt. Until I realised that everyone wants to deal with it  due to its financial effect and seriously negative influence on business, it can have consequences like losing customers because of poor experience, making software vulnerable, insecure or less performant." - Vedrana

Product, design, and stakeholders are not the only ones to blame. I have seen also that it is misunderstood in tech teams.

What is Technical Debt relating to Software?

It is a metaphor. It's not an entity. Ward Cunningham, one of the founders of the Agile Manifesto, coined the term in a report for  OOPSLA 1992 and this video:

Here is an explanation of the debt by Ward Cunningham: 

"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise."

This quote is an extract from Dave Nicolette, who expands on Ward's opinion in this case study.

What causes technical debt?

I want to explain the importance to everyone. It occurs when you think about product conception. I have a strong belief that strategy, product and design have a direct impact on it in general.

The concept can't be the engineering team's responsibility. It has an impact on the full team and the product.

The code, the design, the architecture and the product are all entities. Entities live, and they add some from the moment they are born.

Debt is inevitable.

We can make a comparison with humans. Each decision we make is a debt to our future selves.

If you drink too much, you will pay the interest of one night of alcohol for the foreseeable future. If you choose to develop one specific skill, your goal is to gain new opportunities.

In the same way, companies, products and codes accumulate it. It's not about bad code or code quality. There is a causation and correlation between it and decisions made during the software development process.

Understanding the concept is crucial for digital leaders and product managers. It's even essential for anyone who directly or indirectly impacts the product.

Why should you care about reducing debt?

Technical debt builds up as it goes. Like financial debt, it accrues. The impact is on the software development team, the code quality, the increase in development cost and the development process in general. 

Agile teams are distressed if the technical debt ratio becomes out of hand. The entire software development life cycle is impacted. 

In the framework of a digital leader, it is a skill part of the true productivity area. The expertise to understand the impact of tech is something else. The digital leader has to develop this productivity skill needed to be great at what they do.

The financial debt comparison is as if we were borrowing expecting a return. We must analyse and understand what we do with investment or financial decisions.

I have never been at ease because we only discuss it as an engineering issue.

We need to redefine concepts if we want an engaged culture around digital products. Semantics and words matter.

This is why I will talk about debt, not just technical debt.

Why can't you ignore it?

There are many factors resulting in it:

Resource Constraints

Like poker, we can't change the cards we are dealt with. We can complain as much as we want about it. We hope to have a pair of Aces in our hands. The result is the same. The situation is out of our control.

It's the same with resources.

The context of our situation, the team and the capabilities at our disposal impact us. We have little control over it.

Time, talent, money, you name it.

Our digital journey is up against the walls.

Sure, we can read about theory and best-case scenarios, but this is the reality we have to deal with.

These aren't annoying roadblocks; they're the fabric moulding your product.

The constraints are not about avoiding them. It's about choosing to keep debt in check.

Like life, you make trade-offs, and those trade-offs stick with you.

Market Pressures

Our work is a timed one. We are all chasing time and working against time.

The market doesn't pause for us. We can't stop.

Competition, the market, new entrants, and technologies are moving and evolving around us.

What we believed was true today can be completely obsolete tomorrow. We can't foresee future or global changes.

It isn't wrong. It's a tactical issue.

Each time you decide, based on market movement, you are accumulating it.

If you are wondering when it happens, do you remember the last discussion on features? Remember when the sales team pressured you for custom software development with the latest feature of a competitor for a customer?

Evolution of Requirements

Building products is like chasing a moving target. As soon as we nailed it, the situation changed.

We are playing a rigged game from the beginning. We play in a fast-paced environment, and nobody has set the rules.

There are so many players involved. Each one, such as the customers, is a moving piece learning, evolving and changing through time.

It's not about bad code or wrong architecture choices.

It's a change in requirements. The market and customers evolve and have new expectations.

Those expectations create debt.

Innovation Over Stability

Early startups and projects are like wild horses- untamed and unpredictable.

Your aim is not clear yet. You are putting the foundation for what may become a unicorn. As you learn from the market, you change direction. You accumulate debt as fast as you move.

It's not recklessness. It's the nature of the action you take for your life.

Your ambition pushes you to limits and boundaries you don't know.

It's not like you think about the debt. It happens as it should.

It is why you see companies scaling and not modifying their product. They have to address the problem and the choices as they go.

Slack is a perfect example.

It was, at the beginning, an app working on a browser. The app was an iframe. Slack's crazy scale needed a new strategy with deep refactoring, new design and architecture.

Complexity

I like to compare the role of a digital leader to the quartermaster on a boat.

The position is to manage the crew and steer the ship through an ever-changing maze of situations.

Navigating your project with all the constraints and choices made is a challenge. That's the product architecture.

In the beginning, the product is simple. It has one functionality and does it well. Then, you add features here and there. You start creating dependencies.

The architecture becomes more complex. Making one small change can take days. The work you were putting into designing and estimating a change is taking much longer. You need to think about trade-offs and prioritisation.

Debt is like a spider web.

It extends, and you get caught in it without anticipating it. That's the complexity of our project and something we have to live with.

---

In the second part of the article, I will develop an understanding of the different types of debt, the trade-offs, and how to manage tech debt.