[hn_throwaway_99]

This gets spouted all the time on HN, and I find it rarely to be true, or at least a gross oversimplification.

In my experience what usually happens is a programmer's "worth" is hugely dependent on the scale of the organization, moreso than nearly every other individual contributor-level role, which means that smaller orgs have an extremely difficult time competing with larger orgs.

For example, suppose at some company there is a business process that generates $1 billion in annual revenue, and a programmer has implemented something that can increase that by, say, .2%. So the programmer's "worth" in that situation is 2 million dollars.

A much smaller company only does $10 million in annual revenue, so the commensurate .2% improvement is only worth 20k.

This is a gross oversimplification, of course, but it really gets to the heart of way the FAANGS can pay such huge salaries and suck up a lot of the best talent. It's not that all the other companies are being stingy, it's just that in many cases they can't pay a programmer anywhere near what a FAANG can because that programmer just can't generate that much business value at a smaller company.

[lostcolony]

It kinda goes the other way too though, no? A business generating $1 billion in revenue might have 10k employees. A smaller company doing $10 million in revenue might have 100. The commensurate value of a given employee is not that different.

And the number of employees also affects the types of efficiencies you can introduce; the likelihood of finding something that will increase revenue at a higher percentage for a large company is drastically lower than the likelihood of finding something that will increase revenue at a higher percentage for a small company. And that's if it's percentage based in the first place, rather than fixed savings.

Anyway, relatedly, it has more to do with the fact that a lot of the leading tech companies have a high amount of revenue -per employee-. That is, revenue/employee = big number. There's a few different reasons for that, but that's the main thing. Per the example above, it's really more like a company doing $1 billion in revenue has 10k employees, and another doing $100 million has 5k employees. Obviously the former has more to spend on employees, as they're generating more with fewer.

[repsilat]

An annoying and more complicated (but perhaps not less accurate) heuristic is that the revenue of the company is related to the sum of prior work. For a product company, the number of features drives use more than the rate of new features being added.

Under that model taken as-is there are some interesting features:

- The company could fire all the engineers and coast if the product is "done". Mostly reasonable, though products are never done.

- More "solve for the equilibrium", engineers are paid for the present value of their contributions rather than some proportion of current revenues. Depends on the company either being well-funded, paying in stock, or being able to take on debt. Again, rings true-ish? Hard to measure so obviously expected present value will differ greatly from the actual value.