[johnrob]

Fundamentally, are performance systems done objectively or "on a curve"? Meaning, if 100% of the engineers are operating at say Staff Engineer level, do they all end up with that title? Or does the Staff Engineer title really come down to some sort of percentile in a stack ranking?

[geofft]

For almost any company, if 100% of your engineers are senior, you're overpaying for talent (and probably burning out some talent, too) because not all the work that needs to be done is senior-level work.

This is not the same thing as 100% of your engineers being good, by any means, so it's not quite a stack ranking problem. In particular you can solve it by hiring good junior people, as long as you're not overstaffed (and if you are overstaffed, you need to find a way to figure out who to get rid of, other than getting rid of all the junior people).

[wpietri]

> not all the work that needs to be done is senior-level work

Personally, I'm very suspicious of this theory. Whenever I've worked with a team that's all pretty senior, we work to automate away the boring stuff.

[geofft]

Is automating away all the boring stuff actually the highest net business value approach you can take?

It might be necessary to let people do it to retain senior people and keep their morale up, and I've certainly seen companies be successful by letting good people overengineer things simply because it lets them attract good people and have them around when they're needed, so if that's your strategy, go for it. But you might be better off having a person with market salary $X spend a week doing something they don't yet find boring (and will learn from so that they can become senior) than having a person with market salary $2X spend three days automating and writing tests for their automation.

And there are a lot of interesting real-world problems (as in would-produce-business-value problems) that can't be automated, like gracefully remediating a legacy system where each user was able to get their own weird requirements supported. In the process of getting all the users onto a system you can automate, you need actual human time to work with each user and understand what they need out of your API surface, and while having senior people available is necessary for the complicated cases, it's unlikely to be necessary for all of them (and again, the ones that senior folks would find boring are good opportunities for junior folks to gain experience).

[wpietri]

You seem to have two arguments here: training people up and short-term economics. The former is irrelevant to your point. Yes, if you have junior people, it's good to find things for them to do that are at their skill level. But that doesn't mean that there's no high-skill way to do the same work.

I don't think the short-term economic perspective really means much in the long term. Sure, if you spend $6x automating something a junior person can do for $5x, then your apparent extra cost is $x. But that's only true if a) the problem never comes up again, and b) no problem particularly like that one comes up again. Given the history of our field, that sounds like a poor bet to me.

[Cookingboy]

>if 100% of the engineers are operating at say Staff Engineer level

Then you need to re-evaluate your definition of "Staff Engineer" at your company. Those titles are all relatively defined internally in the first place, just like junior/senior/staff/senior staff.

There is no industry-wide benchmark for those levels, so an internal curve is the only system that makes sense.

In the imaginary case where everyone in the company is a super high performer and everyone is equally as good, then it's not crazy to do away with those titles entirely as long as that's the case. But obviously that scenario won't last long as the company grows, and that's why titles/levels are gradually introduced.

[vonmoltke]

> But obviously that scenario won't last long as the company grows, and that's why titles/levels are gradually introduced.

For better or worse, Bloomberg does not have this. There are no formal levels or titles for ICs, despite having thousands of them. I thought it worked fairly well there.

[kelnos]

If everyone actually is operating at a high level -- or at least enough to make a curve difficult -- keeping people under-titled is just a great way to allow your high performers to become discouraged and leave the company.

[pbecotte]

Titles, in my mind, reflect duties and responsibility rather then level. Not everyone can be in charge of the same things and have leadership responsibilities...therefore they cant all be staff engineer.

They CAN all be top performers at their responsibility list...

[wpietri]

To me, "in charge" is a dominance relationship. It imposes artificial scarcity. Leadership and responsibility, on the other hand, aren't zero-sum quantities. I think one of the best things you can do with junior people is to find things for them to lead on as early as possible.

[babesh]

Salary isn't the only thing people covet. Titles and responsibilities are also coveted since they increase future earning potential. When people don't feel that they can get them, they leave.

[User23]

Neurotypical humans all crave social status. The higher expected future compensation is a nice bonus, but it's the status that draws people to higher titles.

[munchbunny]

if 100% of the engineers are operating at say Staff Engineer level, do they all end up with that title? Or does the Staff Engineer title really come down to some sort of percentile in a stack ranking?

If you actually have 100% of engineers operating at the Staff Engineer level, then it is what it is. However, the only case I can think of when that should ever be true is when you can count your developers on one hand. Once you grow any bigger, it's just not an efficient use of your money or the engineers' time to have that much experience concentration (as opposed to talent concentration, since more junior people can be talented too).