Ask HN: Leading indicator metric for measuring “Technical Debt”

Would love to hear thoughts on how to have a metric that acts as a leading indicator of Technical Debt in services/code we write.

Specifically, moving the metric should correlate to putting preventative measures like "writing more unit tests" or "writing alarms and debugging run-books" before developer efficiency takes a hit or the product is bogged down under sevs.

I agree that there is a correlation between the business metric, like daily active users and the Tech debt. However, the Business metric is a lagging indicator of Tech Debt so if you just use Business metric you are limited to doing "corrective actions" like a Tech Debt month after the service deteriorated.

Moving the Tech Debt metric should incentivize preventative behavior and save the sev in first place.