Publish the One Metric That Matters
For any capability there are usually only a few metrics at any time that reveal whether the capability is sufficient for its purpose. For example, the temperature at which a fire retardant will ignite is the key metric for the retardant. As another example, the percent of tests that pass is a key metric in assessing if a microservice is sufficiently complete—assuming that the test suite is sufficient; thus, test coverage is another key metric.
Such key metrics are the ones that one should pay closest attention to in order to stay focused on outcomes. They are the metrics that should be at the top of one’s dashboard.
Sometimes a metric is not numeric. For example, consider the microservice mentioned above. If the testing approach is based on API-level tests or behavioral tests, then there is probably no numeric coverage metric. However, there could be a binary metric stating whether someone in a suitable role has reviewed the test coverage and assessed it to be sufficient.
Once a capability has been achieved such that the metrics are sufficient for success, then those metrics cease to be informative, and should be replaced with other metrics. This is basically the Theory of Constraints: once one overcomes one obstacle, another is revealed, until finally the last one is overcome. The key metrics are the ones that currently constrain us.
We often refer to the most constraining metric as the one metric that matters (OMTM), from the book Lean Analytics. In practice there might be a few key metrics, but the idea is to focus on a very small number of metrics that are constraining you.