[PaulDavisThe1st]

> And remember, rankings don't have to be perfect, they just have to more accurate that random.

No, they have to better than both random and "everyone is, on average, and over an extended period of time contributing roughly the same". That's quite a challenge.

Do you go to customers and ask them which features provide the most value to them, and then follow the code back to the people who implemented them? Do you go to the customers who paid the most, and repeat the question to them only?

We're not talking about some award-prize ceremony speech in which we acknowledge that Dmitri and Aneka led the work to get version 8.0 which has been a huge success. We're talking about actual salaries, which are presumably linked in some way to actual sales, and I'm insisting that connecting individual developer efforts to the sales numbers is extraordinarily hard. "More" and "less" are not enough to come up with actual numbers.

[slibhb]

> No, they have to better than both random and "everyone is, on average, and over an extended period of time contributing roughly the same". That's quite a challenge.

This is something virtually all functional companies do when they decide raises. The fact that they don't do it perfectly isn't a huge problem, they just need to be more right than wrong.

> Do you go to customers and ask them which features provide the most value to them, and then follow the code back to the people who implemented them? Do you go to the customers who paid the most, and repeat the question to them only?

Does productivity equal sales? I don't think so. If someone does a good job implementing a feature that doesn't drive sales, that should count toward their productivity. Equally, imagine a task that could be assigned to anyone that drive sales: it doesn't make sense to reward the person who happened to be assigned this task when anyone could have done it.

You're demanding way too much here because you're unwilling to get "handwavy" and instead want some rigorous way to quantify productivity. Instead, embrace subjectivity! Imagine you're in charge and ask yourself questions like:

1. If I need to organize a meeting to address some problem that needs to be solved as soon as possible, who would I invite to the meeting?

2. If someone tells me he plans to quit, how much would I be willing to offer to convince him to stay?

3. If someone quits, how hard are they to replace? In terms of hiring a replacement and/or transferring their responsbilities to someone else.

I suppose there are some workplaces where it's genuinely hard to rank people. But my sense is that they're rare, small, and careful about hiring. Everywhere I've worked, this is not the case and I'm fairly sure this is the norm.

[PaulDavisThe1st]

The 2nd and 3rd questions you pose are all about sales.

If your company brings in $10M a year, and somebody plans to quit (or has quit), how much will your sales drop (immediately, and over a period of time). That's the answer to how much you can afford to offer them to stay, and that's how much you should offer their replacement. Suppose that says drop by $1M and you can be satisfied that the drop is 100% a consequence of the departed (or soon to depart) developer - that's how much value they bring to the company, and by the logic of capitalism (which I don't play by, btw), you should pay them some amount less than that.

The problem is: you can't determine the value before they quit, and you can't be sure that their replacement will provide that value after they are hired.

Look, I understand that in an organization of any size, there are likely to be slackers that feel like a deadweight, and others who feel like the contribute far more than the average.

The question is: does tying salary to this perception actually bring the benefits you think it does (which are intimately connected to the notion of incentive) ? There's some good evidence that for developers and other "head-based" employees, it does not, and that flat pay scales create an environment in which you get different kinds of benefits.

I've worked exclusively in a distributed FLOSS project for the last quarter century, so in many respects, I'm not well positioned to talk about what happens inside traditional corporations.