Lines of code is just an example (as are your other metrics). But the thing is that metrics without context drive poor decisions. And lazy managers will often r

Lines of code is just an example (as are your other metrics). But the thing is that metrics without context drive poor decisions. And lazy managers will often rely on metrics as a poor proxy for actual performance when they don't have the time or skill or empathy to actually get to know their subordinates and their work well enough. It happens all the time already, not just in coding teams but also in marketing, national politics, etc. Evidence driven decision making is wonderful when the evidence is actually meaningful. But the onus is on you to prove that your methodology is sound enough to do so, rather than just providing other poor metrics that are easily gamed by devs and/or misunderstood by managers. Just as a counter-example, in the teams I've been in, typically many people will be asked to review code, but the bulk of the work is done by peers. The senior reviewers will wait until a few others have already requested changes, and then give the final approval with minor changes. Does your tool account for that? I dunno. I'm sure it could, but teams are full of everyday idiosyncrasies like that. A good manager is already aware of that because they take time to understand the team dynamics and each person's duties, strengths, and weaknesses and adjusts accordingly, placing the person before the metric. They are able to look at data when they need to, but also use their soft skills to improve morale and performance in various ways. It is a skill set like any other, and metrics are only a small part of that.