[jackhiggs]

I'm an Engineering Manager for a large company and have been for a number of years. For our large team we will rank the team based on perception of managers. After that we will then manually collate coding stats from all repos we work on. Unfortunately for the consensus view here and in the article, you get a 100% hit rate on who you think poor performers are and the lowest coding contributors.

For top performers it's more nuanced. In general they will be top of the contribution stats but sometimes if they're doing R&D or hard work then the stats are not very meaningful. But that's why we don't rely on them.

So metrics have their place to inform and color existing perception. But they will rarely change perception completely.

[LaGrange]

> Unfortunately for the consensus view here and in the article, you get a 100% hit rate on who you think poor performers are and the lowest coding contributors.

This is circular logic. If you measure that "coding contribution" nonsense, people's "performance" will be perceived based on that, _especially_ by their direct managers.

[AgentOrange1234]

I’ve seen cases where folks completely checked out and were contributing nearly nothing, making no commits, writing no code, and faking it at standups. Simple metrics can help surface cases like this.

I agree that it’s something a manager could over-index on. I’m not sure how to avoid that beyond adopting a mindset of “this is noisy data that sometimes gives you important insights.”

[lowbloodsugar]

Amazing. You just proved her point with data and then drew the exact opposite conclusion.

[aswerty]

Qualitative and quantitative approaches together inform us best. Probably not the most eye opening of statements.

But I think as you indicate, qualitative generally paints the picture, and quantitative validates it.