Number of bugs caught in test. Number of lines of code written, fewer would be better, but it's difficult to measure this, because more functionality is often correlated to lines of code.

Number of hours of maintenance required after release. Bugs found after release. Downtime caused by code written by the developer. Amount of time projects are delayed due to the developer. Number of hours or days code is ready before deadline. Speed of the application or functionality they write. Longevity of the code.

* Bugs caught in test - testers file more bugs given the same number of defects.

* Lines of code (less is better) - People talk more, do less.

* Hours of maintenance required after release - Developers delay release excessively for testing.

* Bugs found after release - Developers look less hard for bugs.

* Downtime caused - Developers avoid working on things that might cause downtime.

* Time delayed due to developer - Impossible to measure.

* Ready before deadline - Developers test less rigorously, cut features.

* Speed of the application - Application will do less, or developers optimize beyond what is necessary.

* Longevity of code - Not strongly connected to quality, dependent more on organizational use case.

My point is not to get you to come up with new proposals, because they will likely fail too. It's to get you to realize that the entire idea of coming up with these metrics, or balance them, does not make sense. You would not say to a water colorist that you would compensate him based on how little red paint he wastes or how many square inches he paints.