[ardillaroja]

I think the analogy may still be useful/interesting. It's just that with financial debt you have borrowed money, with technical debt you have borrowed time. Financial debt reduces the efficiency of future available money (interest payments), technical debt reduces the efficiency of future dev time.

I agree with your point that technical debt is a lot harder to identify, the way to pay some of it off may not be obvious and taking on that debt is not usually a conscious decision.

Sometimes you'll cut a corner to get a prototype done or hit an important deadline and there it seems more of a clear trade off, time now for pain later. But, as you say, the creeping (and inevitable?) technical debt of aging projects is less obvious. More like maintenance costs for assets and investment in rust proofing?

[watwut]

An individual engineer can know whether this cut corner is nicety, something with mild impact or something that will stand in away. CTO does not and should not make these low level decisions. Managing fuzzy information is the key to managing technical debt.

Not all technical debt is result of time pressure. A lot of it is lack of knowledge/experience (doing something new), organizational mess, maverick coder, competing visions among coders over architecture, confident senior with influence that is forcing others to produce bad code, demotivated coders, incentives etc etc.

Deciding whether this specific cut corner is not so much CTO job, big picture is CTO job.