[Aurornis]

> because instead of paying for delivered value,

This argument falls apart when you consider that some projects have zero or negative value. Developers who work on these projects still get paid and we obviously don’t have to write a check when we make a mistake that costs the company money. Nobody actually likes “delivered value” compensation except under hypothetical circumstances where they imagine it can only increase their pay.

The hiring market is a market. Supply and demand drives compensation.

Delivered value isn’t one of those forces driving supply and demand. It sets the maximum an employer can pay someone and still get an ROI, but that’s it.

> Turn the tables, if a dev in India, Romania or Mexico is delivering the same value as one in the US or UK should (s)he be paid any less ? Why ?

Because it’s a job market and you’re bidding for candidates against their other options.

If you’re house shopping and you find an identical 3 bed, 3000 sq. ft. house in all of those markets, would you expect to bid the same for it? Of course not.

The sooner we accept the realities of job markets and supply and demand, the sooner this all makes sense.

[paulddraper]

> The hiring market is a market.

Yes, and when you are hiring remote, the market is "everywhere."

No need to divide that market up by people living in a city, people owning a sports car, people with large amount of medical debts, etc.

[drubio]

OP's line of thought is pretty clear with the other line:

"bidding for candidates against their other options"

Then he goes on about projects having negative value and also paying employees until value is delivered.

His model is to exploit every possible loophole to make it all work and shift the most risk from management to employee.

Yes, assuming it's all legal (which it often isn't, pushing the limits like this)

Where should the line be drawn ? Pay based on what car I drive because it's less|more expensive ? What school my kids go to ?

I'm almost waiting for salary adjustments base on diet! Hell why not, veggies 'are less|more expensive'?

[adolph]

> This argument falls apart when you consider that some projects have zero or negative value.

Null hypothesis would be that on average the null/negative value projects would be evenly distributed.

[yjftsjthsd-h]

> This argument falls apart when you consider that some projects have zero or negative value.

...Then why is the company running that project?

[Aurornis]

Are you really asking why companies take risks on new projects that might not work out? Or expecting that companies can perfectly predict which projects will succeed?

Look at it this way: What if the developers were only paid after the product broke even and starts "delivering value". You think you're going to get a lot of developers signing up to work on a new project that might only pay them if they stick with it for a few years and it succeeds due to reasons that include things out of their control (like sales cycles, market moves, etc.)?

[topaz0]

Replace "delivered value" with "expected delivered value" and the argument goes through mutatis mutandis. Of course there are uncertainties in the value of unrealized work, but the company is paying because they think the expected value of the work is higher than what they are paying in wages.

[throwaway11460]

So if the developer makes a mistake that lowers the delivered value, who pays? E.g. slower than promised development, things that were promised don't work at all or cost more for less results, etc.

[topaz0]

Seems to me you've missed the point of the "expected value" part, throwaway.

[throwaway11460]

Did I? So developers should be paid the expected value even if they do not deliver, is that what you're saying?

[yjftsjthsd-h]

> Are you really asking why companies take risks on new projects that might not work out? Or expecting that companies can perfectly predict which projects will succeed?

Uncertainty is fine; is mean that if the expected value[0] is below zero it's a terrible idea to do it.

> Look at it this way: What if the developers were only paid after the product broke even and starts "delivering value". You think you're going to get a lot of developers signing up to work on a new project that might only pay them if they stick with it for a few years and it succeeds due to reasons that include things out of their control (like sales cycles, market moves, etc.)?

Empirically yes; what you've described is close enough startup employees with low cash and high stock payments.

[0] https://en.wikipedia.org/wiki/Expected_value