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.
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.