A lot of this gets covered in retrospectives. Making sure that you don't repeat similar mistakes over and over again and that the team is evolving rather than becoming static. I tend to focus more on how well we hit our goals (including business goals) so that will include things like, "Are we getting better at estimates?" It could also informally include, are Dev1 and Dev2 arguing less and communicating better?
I usually leave metrics to the product side. Find your version of Facebook's "7 friends in 10 days"
OP: Do NOT use bug count, for all that is holy.
Yes, it can be gamed, but if you're incentivizing developers to game your system, then you're probably using it wrong.
Total lines of code added (starting at total lines removed, then counting upwards). We want to see +150 per developer/week otherwise the TL has to explain it to the GM. We also have a manager who run a code consistency checker and flag any submits which don't conform to the standards (e.g. {} not on their own line, variables named incorrectly, etc). There are also reports that come out of the CS ticket system against each part of the system which are meant to be bug reports (most aren't) which we need to fix and close, teams are ranked against each other on fewest reports and most closed/month.
Why don't you do this during build time using build plugins or using commit hooks instead of a manager doing it?
My joke is that the code base should be getting smaller every week because we are all getting better.