image from Who Profits from Creating Technical Debt?

Who Profits from Creating Technical Debt?

…And doesn’t it pay off? Let’s find the culprit together.

Before we dive in, keep in mind that this question is tricky for at least two reasons:

  1. (Mostly) no one consciously profits from technical debt.
  2. It’s not about deliberately incurring debt (for example for an MVP), which is then paid off.

However, in organizations, you often find groups that unknowingly profit from technical debt and do not repay it. Do any of the following sound familiar?

  1. Managers or Stakeholders prioritizing short-term gains over long-term stability:
    They receive bonuses for delivering projects on time and do not participate in repaying the debt due to project or company changes.
  2. Product teams rewarded based on the number of new features: They ignore technical limitations or the impact of their decisions on product quality.
  3. Salespeople evaluated by the number of customers using the system: They require functionalities hastily put together, creating problems for IT.
  4. Developers/leaders delivering projects faster but with lower quality: They are promoted to higher positions where they no longer have to maintain the system.
  5. Developers profiting by being the only ones able to repay the debt: They become heroes capable of fixing the system’s current state.

Each of these roles benefits from increasing the level of technical debt.

But How? Isn’t the Organization Worse Off?

While working on this article, I conducted a bunch of small consultations to understand different perspectives. One comment I received was:

Not true – Project Managers would profit from projects that add value to the organization.

This insightful comment highlights an important cognitive bias. The problem here is viewing the company as a whole rather than a collection of individuals. Objectively, the company loses, but subjectively, individuals may benefit. People will achieve gains as long as the organization survives, and then they might resign and work elsewhere.

People naturally focus on short-term gains. We may not care about the company’s long-term troubles as long as the current paycheck arrives on time.

As John Maynard Keynes aptly put it:

In the long term, we are all dead."

How Does the Organization Itself Keep Supporting the Creation of Technical Debt?

I don’t want to foster an atmosphere of blame-shifting. In 99% of cases, individuals are not intentionally working against the organization. Instead, the organization is structured in a way that supports negative behaviors, ultimately creating technical debt.

Usually, this is caused by faulty systems of bonuses, promotions, and other incentives:

  1. Focusing on Output instead of Outcome:
  • Optimizing for task completion rather than actual results.
  • Offering bonuses or promotions based on short-term metrics, such as the number of new features deployed.
  1. Lack of feedback throughout the process:
  • No consideration of what the newly sold features contribute to the overall product.
  • Not taking this feedback into account when calculating bonuses and incentives.
  1. Concentrating on individual rewards, not team rewards:
  • Creating competition within the team, leading to a lack of cooperation and decreased product quality focus.
  1. Promoting “heroes” who save the day:
  • Rewarding those who fix crises rather than those who prevent them from happening.

From the perspective of an Organizational Structure:

  1. Building structures not focused on the entire value stream - Causes local optimization and rewarding department work instead of overall organizational efficiency.
  2. Setting unrealistic deadlines without consulting the departments creating the solutions: Puts people in a position where they must incur technical debt to meet deadlines.
  3. Lack of information exposure about the product’s state to profit-generating structures: Structuring so that information arrives too late to influence the decision-makers.

An interesting article from HBR discusses how incentive plans contribute to increasing problems in organizations.

How to Change the Organization to Support Debt Management

Simply calling for debt reduction won’t be much of help here. You can’t change human behavior. If people profit from releasing poor-quality products and not fixing them, they won’t be interested in improvement.

What the organization can do is change the operational system to account for both short-term and long-term values:

  1. Define goals that consider long-term metrics - Everyone should understand the consequences of technical debt and prioritize sustainable practices over short-term gains.
  2. Avoid bonuses and incentives based on metrics unrelated to the entire value stream.
  3. Build cross-functional structures that naturally cooperate - Make it easier to avoid optimizing for simple metrics.
  4. Translate technical complexities into business-understandable measures - Quantify how much is lost due to poor infrastructure conditions.
  5. Provide education and training for non-technical staff - Show how the organization suffers from increasing technical debt.
  6. Encourage and reward technical debt management - The organization should have a process and plan for regular evaluation and management of technical debt.

This process is neither easy nor pleasant. Nobody likes losing bonuses when they profit from passing problems to others 😅.

How Does Technical Debt Management Look for You?

Have you ever encountered this kind of a situation? Let me know in the comments!

comments powered by Disqus