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.
Re:What it was like working for Gitlab
by throwaway11460 on Sunday February 11, 2024 @01:25PM
(#39337123)
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.
Seems to me you've missed the point of the "expected value" part, throwaway.
Re:What it was like working for Gitlab
by throwaway11460 on Monday February 12, 2024 @03:00AM
(#39342579)
Did I? So developers should be paid the expected value even if they do not deliver, is that what you're saying?
The chance that they won't deliver factors into the initial expectation and is reflected in the hiring and salary decision. You can evaluate this chance both globally and for an individual by considering their interview, past experience, recommendations. Presumably if a developer is routinely not doing their work, the employer will revise their expectation downward, and ultimately stop employing that developer if they are a net negative. I see no problem here beyond the inherent uncertainty that comes with working in a complex world where your knowledge is incomplete.
Re:What it was like working for Gitlab
by yjftsjthsd-h on Sunday February 11, 2024 @04:21PM
(#39338853)
> 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.
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.)?