Using metrics to improve product quality

Metrics. Managers love them. Developers hate them; but why is that? In a word, "trust". If we don't make clear from the beginning the intention of these metrics, distrust and resentment of them will set in and they will have a counter productive influence as developers begin to look for ways to "beat the system". The funny thing is, whether you're a manager or a developer, we all have one thing in common. We all want to improve the quality of the product and metrics when applied correctly help us all to achieve that. So how do we make metrics work?

• Be transparent. Ensure you make clear the purpose of these metrics is to improve the quality of the product. Not to beat developers with a stick.
• Focus on product quality, not individual performance. We all share that common goal so establish and capitalise on that alignment of interest. Do measure cyclomatic complexity and afferent/efferent coupling. Don't measure "most check-ins a week" or "most lines of code".
• Create buy-in. Don't force these down. Identify meaningful metrics by utilising the experiences of those closest to the issues.

If we focus on the wrong metrics, we risk creating a culture where we write code that's purpose is simply to pass fool a rule. This is entirely different to writing clean, maintainable code which is where the real benefit is. Worst still, if metrics are used incorrectly as developer KPI's, no developer is ever going to undertake that much needed refactor of that difficult to maintain code for fear that it will hurt their "score" or "ranking". When we get to that point, it's the beginning of the end.

What other ways can you ensure metrics succeed within your team?  What metrics do you capture?