Technical debt is frequently thought of as being a code or executables. If so, is this hard to fix? What drives technical debt?
A leading candidate as the source of technical debt would be bad processes. Let’s say your team conflates “estimates” to be “commitments”. Clearly this worse case scenario can easily drive many bad hurried decisions across many facets: requirement definition & approvals, design of architecture, classes, system/database/messaging interactions, documentation, installation practices, and so on. These are the easy ones to deal with as most are under developer team control or influence.
If you consider the greater organization, the problem become much, much harder to correct. It can take weeks to get executive, sales, marketing, support, legal, or operations teams to come together just for a meeting! Getting everyone to agree on the definition & substance of changes just increases the solution timeline even further.
At the end of the day, the delivery team is left holding the bag. We have to deliver a solution, but have little influence on the overall schedule or scope of the changes or its delivery process. It is imperative that the dev team eliminate as many obstacles as possible to ensure the best use of very limited resources. The dev team, and only the dev team, can correct their situation. It is imperative that improvements be done on a continuous basis.
The reason I bring this up is to offer perspective. Some of the “hard” technical problems dev’s face aren’t so bad after all. Trust me on this, dev problems are much easier!