Communicating the business value, or value to the customer, of technical problems is the key to getting time allocated to solving them. A common blocker some people have here is a fixed mindset (“we would like to, but we just aren’t allowed to fix this”). Remember that in any organisation, people make decisions — decisions are about trade-offs, and decisions can be influenced, overturned, and changed. More importantly, organisations evolve— the way decisions were made yesterday might not be the way they get made tomorrow!

Before you attempt to use the framework I’ll present, for every Technical Debt issue you have, ask yourself: is there really a problem here? It’s likely not worth paying down unless:

  • It improves the speed or quality of output e.g. reworking that build configuration will cut our release times in half, allowing us to deploy twice as often.

  • The cost of delay is urgent e.g. if we don’t fix this right now, it will directly impact X customers/Y% profit/Z% revenue.

Last updated