I would actually be OK with it, as long as I can objectively say that even though someone is slacking most of the time, he/she is very productive in short bursts, so the overall productivity is on par with the team average.
The problem is that if you don't have an objective approach to evaluating productivity, all sorts of biases come in, e.g. if I see someone coming to the office at 11am and leaving at 4pm, I would subjectively rate their productivity lower, even though objectively the results might be the same as for someone who comes in early, and leaves late.
Even if you've tied team compensation to the results of the company, you still have to decide how it will be shared among the team members. So how do you go about compensation, bonuses, etc.? The same for everybody?
This doesn’t solve the issue of individual team member performance evaluation, even if it improved the overall performance of the team, you still wouldn’t know who are under and over-performers.
Yes, the extreme cases are easy to spot, but the nominal cases are not that minuscule, more like one developer being twice more productive than the other, which, I feel, should be recognized and rewarded accordingly.
Measuring against estimates incentivizes over-estimating, especially if the team is small, and team members know roughly who will do what during the estimation process. Big complicated tasks also tend to be under-estimated, so they would be avoided, because they would usually influence the perceived productivity negatively.
I would like to find a feasible approach to productivity evaluation using the output only (PRs, reviews, basically all the data points the article mentions), because I feel that’s the only way of creating an environment, where team members can proactively take a bit more time when it benefits the end result, without fearing any negative repercussions.
It seems to me there are two sides to engineer's performance: the ability and the productivity. Ability measures how complex tasks can an engineer solve and how well can he/she execute, and the productivity measures the actual amount of work done. Able programmer is not necessarily productive, and productive programmer might not be able to do tasks of high complexity.
As a technical lead, I feel that I'm able to judge the ability of individual team members, but I'm having a hard time objectively judging productivity. Simple count of PRs doesn't really tell the whole story, and some tasks look simple in hindsight, when in reality it took a lot of effort to find a good solution. There are also a lot of other complications I'm not going to dive into, but the end result is that it's hard to have an objective productivity evaluation based on the engineer's output only.
I'd be interested to know how other people evaluate individual productivity?
They also discuss a case, where a user uninstalls Zoom, but does not remove the web server, remaining forever vulnerable, because the fix from Zoom will not reach them. That explains the Apple involvement.