Using production metrics as a whole is very stupid and a good way to get devs to optimize for the metrics rather than quality work. A contemporary example would be a company that promotes for "impact" (i.e. launching new products) which is a great way to have a bunch of failed products that nobody maintains!
The trick is to align the metrics with company goals. It's not easy, but not impossible either.
For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).
Obviously your customer support needs a different metric.
Ye and you end up with blame games and hot potatoes being passed around.
Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture.
Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.
