Read Time: 6 minutes.

Hey,

This week, I have accumulated debt as I didn't plan the recording of my episodes of the Digital Leadership Decoded Podcast. On the other hand, I discussed technical debt, bringing me to the current post. It's important for any business analyst, product, design and leaders to understand the meaning of it and how to deal with it.

Remember that you can give me feedback anytime on the newsletter here, and you can participate in the Reverse Podcast here​

Thanks for being part of the journey!

---

What is Tech Debt, and Why it is Important to Digital Leaders, Product Managers and Stakeholders - Tech Debt Part One

​Read the web version here​

Tech 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 tech issue. Whatever people think, tech 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 tech team and strategy.

A Tech Debt Story

The product team wants 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 turns to the engineering team to explain their plan. They want an exercise: estimating how long it will take to make the roadmap a reality.

The tech team analyses the strategy and explains their concerns. In their first analysis, they see the impact on one product's area, which has technical debt.

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

Release the Kraken!

From that moment, the tech and the product team 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 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 tech debt.

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

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

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

What is Tech debt?

Tech Debt 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:

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

I want to explain the importance of debt for everyone. Debt occurs when you think about product conception. I have a strong belief that product and design have a direct impact on debt in general.

Debt can't be a concept owned and 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 debt 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 debt. There is a causation and correlation between decisions and debt made during their development.

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

In the framework of a digital leader, debt 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 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 general debt, not tech debt.

Why is Debt inevitable?

There are many factors resulting in debt:

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 debt. It's about choosing the type of debt we want.

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 debt.

If you are wondering when it happens, do you remember the last discussion on features? Do you remember when the sales team pressured you with the latest feature of a competitor?

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 is a moving piece that is learning, evolving and changing through time.

It's not about lousy 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. Scaling to millions of users needed 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.

​Read the web version here​

---

Tell me what you think about this topic, and send me any questions you have:
​In the meantime, as we discover this topic together:

• You can access my website and productivity system here​
• Sign up to participate in the Reverse Podcast here​
• Let me know what you think about the newsletter and how to improve it here​

Thanks for being part of the journey!

Phil

---