Not that I believe that you can boil down productivity to a single metric, but I've often found one of the best proxies for productivity is the number of automated tests added or modified. It's one that can be gamed, but absent that, it comes pretty close to capturing the amount of work that a programmer has completed since more complex features require more automated testing. It's also pretty easy to pull from CI build results, along with how often a developer was breaking and/or fixing the build.
Combine that with a code review process that will surface commits with excessive or insufficient tests and it was one of a couple ways I validated my feel for the work of my direct reports when it came time to fill out reviews.
Why the number of times that I break the build should matter in any case?
I think that I break the build several times per week because when I test the application using F5 in visual studio it doesn't do a full build and so the tests may not compile.
Furthermore, even if they compile they may be broken.
This is the primary purpose of the build system, to run the tests and to fail when something is wrong so I don't have to spend time running tests on my machine.
Once they fail on teamcity I fix them.
And I will be very surprised if anyone of my colleagues complains about it given that only I use my feature branch.
Breaking your feature branch isn't breaking the build anymore than breaking the build on your local laptop is. "Breaking the build" means breaking master or a release branch. Those are the ones that inconvenience others and limit response time to critical production issues.
Combine that with a code review process that will surface commits with excessive or insufficient tests and it was one of a couple ways I validated my feel for the work of my direct reports when it came time to fill out reviews.