Ageism has always baffled me. In my pre-funding pursuits, I've always dreamed of hiring a team composed of top-tier talent. That typically means people who have been in their respective industry 20+ years. I'm in my early thirties and there's no one on my hire list that's younger than me. That isn't to say I wouldn't hire anyone younger than myself provided they've the skill—I absolutely would—it's just that age and experience (and thus skill) tend to be highly correlated.
Presumably the motivation for the most common form of ageism is that 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? It makes very little sense.
> 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.
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.
> 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.
> 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.
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.
Young people are an excellent fit for technology jobs. They are quick to pick up new tech, enthusiastic, energetic, open minded.
They're less likely to own a house and have a family to support, are hungrier for experience and learning curve, so can work for less money. More willing to settle for stock options that may or may not pan out some day. Can relocate at a moment's notice.
Cons: very few. I would just say, today's young people, at least here in the U.S., seem not to have been trained to write and speak proper English. Their knowledge of history is shallow and they are lacking in some of the skills that my generation grew up learning -- fixing cars, wiring a light fixture, fist fights, cooking and cleaning. But some of them are backfilling from youtube tutorials so it works out.
> Young people are an excellent fit for technology jobs. They
> are quick to pick up new tech, enthusiastic, energetic,
> open minded.
I just wonder much we really gain from all these new languages and frameworks. Do they actually help or are we just spinning our wheels? These days the majority of us work as web developers – our job isn't much more than pulling data out of a database, generating documents, and sending them over the network. We've been able to do that for decades.
There's nothing that baffling about ageism. Corporations are like Skynet in the sense that they have a life of their own. They will do their best to drive away 40+ people and seek out H1Bs and anyone else they can exploit at low wages for long working hours. If they get even 50% of the quality, they're happy with that. Companies don't really want insightful people who will question anything, not outside of management anyways. Meanwhile, they will act all politically correct and virtue signal endlessly. Management views developers as a commodity resource, like fuel, or a truck. They use them up and buy more.
can you append a random querystring to the url or something? i'm on mobile where the full url isn't immediately visible in the browser, and i found the link quite confusing, as i assumed i was already on the front page.
I don't interview anyone over 40. Period. Reason is very simple. By that time they're bitter from some past work experiences and have figured out now a bunch of ways to look busy at work. They also likely have more demands coming from family if they were brave enough to try marriage in the "gig economy" we all live in now. It's great that there is a service out there for those who were never able to save enough to retire before they got replaced with younger more energetic and cheaper labor. At 52, I feel lucky every day that I now have a job in management. Not nearly as interesting work as what I did technically ten years ago, but I'm also making almost three times as much money, and who knows how much more than than one of my former colleagues who is in his 70's with a PhD from a top 10 university and is working at Starbucks to help pay his daughter's $45,000/yr. tuition!
Could not agree more. Experience is hugely valuable. Unfortunately, the way a lot of smaller less-funded companies like ours work is that we take the "brilliant ideas" from someone else (often university research but also sometimes insights gleaned through in-house interview process) and implement them for our customers. The vast bulk of our contribution is what you might call "scut work" (often the kind of thing that gets farmed out to grad students and post-docs on the academia side when they want to build a working prototype) and faster rather than smarter is what enables us to compete most effectively with the rest of our market. I wish it weren't this way. I'd still like to be doing technical work myself, in a more carefree and supportive environment, with all the protections that union members in other trades (like law enforcement and primary education) appear to enjoy. But it seems that the technology sector the world over is moving more and more in the direction of "at will" employment where everyone (except when it comes to affirmative action for certain protected classes) has to fight for their own survival until they get too old to put up much of a fight anymore. "Capitalism is cannibalism" is what one of my first supervisors told me right before I got laid off in 2002, and from where I sit today, I feel like truer words could not have been spoken.