[erikpukinskis]

> young people are easier to exploit and abuse under the pretext of "saving money", but why the fuck would anyone ever want to run their company on that basis?

There are two ways to get more from your developer team: quality and quantity.

Quality means you pay your people more and more as you grow. Grow from 10 to 20 over 10 years, while retaining most people and tripling their salaries.

For that to work:

- your revenue per employee must grow substantially

- you need managers who are flexible, because you have to adapt your workplace to your employees needs rather than just hiring new people when they turn over

Those are difficult things that not every owner can bring about in their company.

The other approach is quantity: grow your dev team from 10 to 100 to 1000. For that to work you need:

- Employees who can follow instruction without worrying too much about whether the tasks make sense

- Employees who just want a standard job and don’t need much customization over their career

- Efficient hiring processes, centered on a repeatable, consistent employee profile (not necessarily the most capable profiles)

- Caps on wages

The quantity strategy doesn’t require finesse. In fact it works better without it. You make coarse, aggregate decisions and let people turn over as needed. The turnover “cleans” the talent pool of people with special needs, which is crucial for the system to work.

The quality strategy requires really smart management which is very hard to hire.

[woah]

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 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.

Giving employees equity is a much better version of what you are trying to do and I'm puzzled as to why you didn't suggest it.

- Employees get it 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

- It's not based on some kind of vague aspiration to be a good boss, it's a solid, well understood form of compensation

- No new employee is going to resent a lower-skilled old timer for their equity- they earned it.

[erikpukinskis]

> 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.

[woah]

I wasn't trying to be weirdly antagonistic.

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.

[erikpukinskis]

> How do you compensate the people making internal tooling for example?

You need to place them in your business model.

What are the tools used for? What would happen if the tooling didn’t get built and your colleagues used off the shelf tools?

That will tell you how much your team is worth.

Most people seem to throw up their hands at this point and say “it’s hard, and imperfect” and they stop working on the business model.

But any model is imperfect. Even the sales person you mentioned, who earns a flat commission on sales... they could be costing the company more than they’re bringing in, if their sales are forcing developers into crunch, or if their customers churn, etc. The point of the model is not to mirror reality perfectly, it’s to give you numbers that can guide your negotiations, as I said.

Just because it’s unusual to think about how developers fit into your business model doesn’t mean it’s impossible or it shouldn’t be done.

[rl3]

The funny part about the Quantity strategy is that it eventually turns into such an unmotivated and directionless bureaucratic hellhole that often those same companies create teams or even startup-like subsidiaries following the Quality model.

Ironic that, in order to achieve a modicum of quality, many large companies must insulate anything potentially valuable from their true corporate environment.