| > 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. > 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. Sure, but they’re paid on performance not “talent”. Work is not a talent show. The people getting more money have successfully deployed projects worth much more than their salary. That’s why their salaries were bumped. If this new person can do that they’ll earn the same salary. > And at the beginning, either you are keeping your plans of an eventual 3x salary secret from employees, in which case it can not motivate them, you are promising it to them which as an employee I would view with great suspicion, or you are writing some kind of agreement about it which seems like it has all kinds of problems. Seems simple enough to me. You do the math on how much revenue you think your work has brought in. I do my
own math, and we negotiate a number every few years. > Employees get [equity] when it's cheap and it literally represents the value of the company that you were hoping to give them in the form of higher salaries Revenue-aligned compensation is very different from an ownership share, both materially and in terms
of what they represent. > It's not based on some kind of vague aspiration to be a good boss Paying people according to their contribution to the business model is neither vague nor aspirational, although it does require you to have a business model that includes your workers. And equity calculations in my experience are pretty vague and aspirational. Not sure what you’re indicating at here. > No new employee is going to resent a lower-skilled old timer for their equity- they earned it. I’m not sure if what you’re describing is based on my actual advice or a misunderstanding so I’ll let you chime in if you think there’s still a resentment issue here. |
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.