[slibhb]

Saying that people should be paid according to experience, ability, and effort is absolutely not the labor theory of value.

The idea that contribution "can't really be measured" is a cop-out. Contribution can't be measured perfectly but it can be estimated with some accuracy by people who are involved in day-to-day work. "Some accuracy" is really all that's required: as long as contribution is correlated with compensation to some extent, you have a functioning meritocracy.

> The variant here where everyone gets the same, generous piece of a pie seems refreshingly simple and honest.

I bet it works great if you have a small team, are extremely picky about hiring, and quickly fire bad hires. Otherwise it will be awful.

[dgb23]

The problem is that in the end, power, negotiation and social currency often dominate over merit (such as effort, experience etc.) when it comes to compensation.

Even if you actually do measure and agree on metrics, then the measurement can easily become the goal for those who are not intrinsically motivated. Work ethic can't be taught by dangling carrots in front of people, because acquiring the carrot becomes the goal instead of moving the cart. This can be detrimental in a highly collaborative workplace.

Having a flat, generous salary might solve this problem, because you filter out carrot hunters and get cart movers.

> I bet it works great if you have a small team, are extremely picky about hiring, and quickly fire bad hires. Otherwise it will be awful.

Finding the right people to work with is difficult regardless. The same worker can be miserable in one place and flourish in another.

[PaulDavisThe1st]

> Contribution can't be measured perfectly but it can be estimated with some accuracy by people who are involved in day-to-day work

This is handwaving in the extreme. Anyone involved in software development knows that a single line of code can be critical to success or failure, as can a blob of 100k LOC, so product-quantity metrics are of almost no use. The "estimate" you're talking about generally comes down to general "feelings" about who works hard, which have repeatedly been shown to be poor metrics for actual contributions.

[slibhb]

Life is full of handwaving. In almost any workplace, it's very simple to know who's doing the work (and it's usually a shockingly small number of people). It's the idea that we can reduce this to a mathematical formula (the opposite of handwaving) that's odd.

> The "estimate" you're talking about generally comes down to general "feelings" about who works hard, which have repeatedly been shown to be poor metrics for actual contributions.

How has this been "shown"? Anyway, you're begging the question that there's some way to determine "actual contributions" that we can compare to "feelings".

If you actually work with a group of people on a daily basis and can't rank order them in terms of usefulness, I find that astonishing. And remember, rankings don't have to be perfect, they just have to more accurate that random.

[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.