There are lots of reasons that TD happens but regardless of what they are, the easiest way to deal with it is to be open with each other. If the COO made a bad

There are lots of reasons that TD happens but regardless of what they are, the easiest way to deal with it is to be open with each other. If the COO made a bad call on something, tell the technical team and work out the best way forwards. Same if a Contractor wasn't as good as you thought or a new framework promised lots but wasn't actually good at some of the detail. When you can be honest about mistakes, tech people are generally more pragmatic than non-techies might assume. In the other direction, I clearly communicate the "cost" of short deadlines or the need to finish something that is in a bad state so that the decision can be made with eyes open. If a quick fix now leaves us in a poor state to add new features then the CEO or whoever can accept that so that when they ask for something new, "sorry, system is too brittle". In reality, there are many reasons things get rewritten so I also try and assure my devs that we don't live with these things forever, eventualy we remove the problems and create a load of new ones! I've rewritten our basic system 3 times in 5 years and only one of those was mainly down to tech debt (although we took the opportunity to update to latest tech etc.)