Below Water Level

Reframe the Question

The secret is in stepping away from using the label “Tech Debt”. As labels tend to do, this one takes all nuance away for an informed discussion.

The real question is, what is it that our customers care about?

Most of the time when I am asked this question, the assumption seems to be that we have to choose between new feature, value prop additions versus tech debt. That is only half the issue. Does that mean customers do not care about getting value faster, cheaper and with high quality? If any of faster, cheaper and higher quality are true, then there will be situations where we need to address obstacles to speed, cost and quality. These obstacles we end up calling out as Tech Debt.

If we unpack tech debt as obstacles to speed, cost and quality, it turns out that its a false choice. We do not have an option but to address these.

Why do we end up in this situation?

The question we need to ask ourselves is, why is it that we end up in situations where we accumulate these obstacles to speed, cost and quality and then lump them all together into Tech Debt?

If we accept for a second that customers do care about these, then how come these do not figure in the outcomes that teams are working towards?

Mostly, it happens when teams are hard-segregated into PM vs Engg with different outcomes or when the teams are disconnected from outcomes and the purpose(which customers care about).

How do we address the root cause?

The prerequisite here is that first, the “whole team” and not just engineers or PMs or designers need to care about customer outcomes. As long as PMs are tasked with revenue goals and engg is tasked with uptime, quality and cost goals, there will be this conflict. The segregation of concerns will result in problems of cost, quality and speed to be lumped into a useless term like “Tech Debt”.

At that point, the power dynamics between the teams and not customer value, will determine what finds its way into the roadmap. The team, as a unit, needs to be responsible for “Seeing The Whole” so they consider the system-wide impact of new feature changes and the long-term health of the system. The need here is of balance.

Conclusion

With these principles, we can hope to achieve some semblance of aligned execution, reducing conflicts and priority thrashing, tuning to customer value:

• “Whole Team” goals
• Equipping the team with “Seeing The Whole” lens
• Championing Balance amongst the outcomes, to make progress on new value, cost, quality and speed outcomes.

Solutions such as innovation sprints, clean-up quarters and 30%-debt-reserve capacity are all still attacking the symptoms of the underlying issue of misaligned goals, absence of purpose and loss of customer focus.

This is easier said than done of course. It has to start with acknowledging the problem and stepping back to discover what the organization values and the rediscovering purpose at the heart of it.

Once this is done, downstream activities such as designing the org, creating the incentives and aligning the goals will be easier and fraught with less friction.