Correct, we do not tell the devs these are being measured
If they are important enough to measure, why not hard force them and focus on the remaining metrics instead?
And
“Use these as a springboard for deeper analysis of devs”
These are only used as high level metrics to guide further analysis, we are keenly aware of the faults of these metrics - but the alternative of no-metrics or worse, “gut feel”, is slow and riddled with more problems.
It doesn’t mean a dev is bad, maybe it means there’s some tooling failure, or organisational problem, or personal problem they need help with. These metrics give visibility into anomalies, and their imperfect nature doesn’t mean they are useless.
There’s also like 20 more metrics but I’m on my phone and couldn’t recall them all right now
Also I don’t know where all of this nonsense about “forcing” to run CI/CD before branch merges and “slap on the wrist” - all our devs can run the test suites locally in docker and inside their IDE, nobody is forced to do anything in the pipeline severs, and also nobody gets a slap on the wrist for CI/CD failures, actually I like to see larger changes with more failures because it means the dev is trying and I consider this normal behaviour, your incorrect assumptions about our test environment and how we interpret these metrics sound like you’re projecting.
i.e. you are not a competent manager by the usual understanding of «competent».
The metrics actually showed no surprises when I saw them, had I been asked to name the worst 5 devs, I would have named the same people that the metrics would have highlighted.
I raised this suggestion with management, but since we had a handful of devs who were drastically underperforming we decided to help them out first with increased mentorship, in order not to embarrass them in front of their colleagues.
I don’t know why you’re assuming the worst and malicious intent, it’s a great place to work, especially when we have a good vibe and all enjoy working together.
I think what contributes to this positive environment is not employing developers who instantly assume malicious intent, and aren’t paranoid about being discovered as incompetent. These people are usually the ones most opposed to metrics, and also are the ones who the metrics show are the worst performers. Instead of objectively assessing the facts they attack the messenger, full of emotion and vitriol because of their insecurities and inabilities.
There are many factors that go into firing a dev, if someone needs help we mentor them and grow them, but if someone has a bad attitude, assumes the worst and is full of negativity, then we are very quick to fire them.
Maybe your company is still a great place to work in spite of that. Or maybe it's only a great place for you to work, and your colleagues would feel differently if they knew about this. I can't say for sure because I don't have any further insight into your company. But that's also not the point about why it's unethical.
Nor is it having a 'bad attitude', assuming the worst, or being full of negativity to be opposed to the secret use of metrics in this way.
I see the metrics as a chance to provide visibility and support, you see it as a way to “manage” the devs. I see a chance to help, you see tyranny.
I see my viewing of my own metrics as a chance to introspect with an open mind and a willingness to see fault in myself and improve, you see an abuse of authority and a land grab to get ahead.
Then you say “I’m not assuming the worst, or full of negativity” when clearly you are, you just demonstrated it.
So like you, let me fall back on the ethics argument:
I think it’s unethical for a software manger not to take machine collected metrics and to manage on “gut feel” and intuition, just as all gut feel and intuition are not explained as rationale to all decision making (thus are also “secret metrics” - i.e. collected without transparent knowledge of all reasoning)
I think it’s unethical not to have secret metrics and inform every person of every thought and data point you have, so there aren’t any secret measures. (You better call your bank, your insurance company and loan companies and marketing companies who are all collecting secret metrics on you, in the sense their rationale, data points, and algorithms are not 100% open and are therefore secret)
I think it’s unethical to distribute reports that might demoralise some devs without helping them out first, especially if we know some of these reports might look unfair, and we are only using them as springboards for further investigation, like I have mentioned many times in this thread.
I think it’s unethical to complain about ethics and not address any of the points in the above discussion with objective facts.
But ethical things are ultimately subjective, so our conversation ends there, we will have to agree to disagree.
What company are you working for? Human "resources" department, I guess?
Looks like a place to strongly avoid because of very bad ethics and culture!
Your bank is scoring you by machine, so is your insurance company, and loan companies, are their algorithms 100% open and publicly available? No. Because they are secret metrics. Your bank knows more about you than you know, and so do the loan companies, I know, I used to work there. The datasets the loan companies have are insane, I could see if you are in financial distress or not, the value of your house, whether you were a “complainer” or not, your favourite music, whether you’re a foodie or not, and heaps, heaps more, I think 250 attributes on each person in the USA at one company.
What difference does it make if some metrics are collected by machine and not fuzzy, vague, human intuition? I think it’s an improvement.
Yes the metrics inform the seniors decisions partially like I said above, and yes they are taken with a grain of salt, like I said above, they are inputs for deeper investigation, that’s it.
Here’s an example that happened just the other day: I noticed heaps of CICD failures for one dev and I reached out to him. He told me he couldn’t easily run the test suite, so I spent an hour peer coding with him and showed him how to use VSCodes debugger.
1 day later he called me up and told me that “using the debugger was a life changer” and he was thrilled to be working so quickly, the faster feedback cycle from code->debug had restored his enthusiasm for work.