Unless you know what to improve, every change you make is just shooting in the dark. This is why feedback loops are so important - the faster you know if something works or not, the sooner you can point your efforts in the right direction. This is applicable to both changes in software delivery processes, as well as changes in the code.

Here are a few metrics that can be a good indication of levels of tech debt and the overall health of the software delivery process:

Deployment Frequency - how often are changes delivered to live. More frequent deployments mean smaller units of change. Smaller units of change mean it’s easier to find out what’s wrong when something goes wrong, reducing downtime due to problems. Deployment Frequency is also a good indication on the maturity of automation used, meaning less resources used for tasks that can be automated.

Failure Rate - how often code changes cause a failure on live. Every failure costs money.

Change Lead Time - how long does it take, on average, for a change to be live, from start of development to successful deployment. Increasing Change Lead Time can be an indication of unmanageable tech debt.

Deployment Lead Time - how long does it take, on average, for committed code to be deployed to live. Efforts on automation and maturing Continuous Delivery capability will decrease deployment lead time, which will in turn decrease Change Lead Time. Lower lead times mean faster innovation cycles, and better adaptiveness to changing market.

You can compare these with, for example, code coverage: with unit test coverage going up, failure rate should be going down and change lead time should be stable even as complexity increases.