Great post! I've been thinking about that a lot recently and my take on it [0] is that the metric could be the iteration time. Teams that move fast can do fast iterations during development. If that's possible, a lot of tasks, also maintenance ones become much simpler.
Another point that's relevant in this discussion is that the tech debt does not appear out of nowhere and developers do not develop whatever they like. Rather, they're implementing ideas of product managers, designers and other stakeholders. If the team finds itself in a hole shortly after tidying things up it can also be because of the ignorance on the product or design side with the requests that demand unreasonable effort to implement very insignificant changes.
All in all, it looks like both terms should be used in combination, because they describe different types of inefficiencies
Another point that's relevant in this discussion is that the tech debt does not appear out of nowhere and developers do not develop whatever they like. Rather, they're implementing ideas of product managers, designers and other stakeholders. If the team finds itself in a hole shortly after tidying things up it can also be because of the ignorance on the product or design side with the requests that demand unreasonable effort to implement very insignificant changes.
All in all, it looks like both terms should be used in combination, because they describe different types of inefficiencies
[0]: https://dpetrov.substack.com/p/the-tyranny-of-the-feedback-l...