Earlier quoted context omitted.
Tripling the salaries based just on seniority seems insane. Either you started way too low, or you're going to end up paying a lot. The developers that you were able to recruit with your low starting salary are going to end up working alongside people who came for the high salaries and may very well be quite a bit more talented. This will create a lot of friction. And at the beginning, either you are keeping your pla…
> Tripling the salaries based just on seniority seems insane. That’s a little antagonistic. Your whole comment is weirdly antagonistic. > Either you started way too low, or you're going to end up paying a lot. Or 1) you start by paying what people are worth according to “market rates”, 2) at some point they break even on what they cost, 3) every year they bring in more revenue than the last and you share it with them…
Your original comment sounded like you were trying to reconcile the common HN views of "developers don't get paid enough", "big corporations are soul-crushing", and "startup equity is a scam". At the time I didn't see how it came together as a cohesive whole.
You've add some detail here about this business model, which involves giving developers commission directly correlated to the performance of projects they work on. This gives me more of an idea of what you're talking about. Commission tends to work really well when you can easily quantify someone's contribution, for example sales.
I suppose this might work alright for developers in a consultancy, although it would be hard to separate the developer's work from the work of whoever landed the sale. A developer could do a terrible job on a project, giving the firm a bad reputation down the line (although their manager might not be aware of this at the time of completion). If the project was big and lucrative, they would get paid a lot. On the other hand, a developer could do a great job on a small project, that led to a much bigger contract which that developer was not able to work on for some reason. They would miss out on the benefits of their good job.
For a product company, it sounds even harder. How do you compensate the people making internal tooling for example? How do you compensate devops people? What's the split between the developer who programmed a feature and developer who runs it in production? My suspicion is that for a product company this compensation scheme would start to look really similar to the normal practice of using market rates and negotiating for raises, since attribution of revenue would be really unclear.