Not a CTO, but in an architect role and spend my life cleaning up tech debt or building guard rails so it's harder to accumulate. The most important thing is t

Not a CTO, but in an architect role and spend my life cleaning up tech debt or building guard rails so it's harder to accumulate. The most important thing is to teach decision makers (be they product or other senior engineers) that tech debt is a downstream result of the decisions they make. That's as simple as keeping them accountable for their actions instead of hiding the mess under the rug. Example: If a colleague uses the word 'later' in a product discussion, pretend they said 'never' and speak up if it sounds weird. "We'll get the new feature working with our most popular product areas and circle back for the others later." "The feature is ready on time, we'll fix those P3 bugs later." If you don't call out the use of later->never here, they'll get away with it and you'll accrue tech debt for no reason. If people want to defer part of their implementation plan, that decision needs to be on the books somewhere with their name next to it. If management doesn't see it, it isn't happening. My most frustrating problem with technical debt is how difficult it is to shoehorn this bookkeeping into whatever process management or task tracking system the company uses.