I agree that was typically also something that came in at senior level.
Maybe it's a regional thing? I'm in the UK. I'd say it was fairly standard here for a junior to be someone in the first couple of years on the job who was still learning the ropes and probably couldn't do much beyond very basic grunt work without the assistance of someone more senior. Losing the "junior" label came when you got beyond the near-full-time hand-holding and started doing routine stuff independently. The "senior" label came when you could do the less routine or more difficult stuff mostly independently as well.
What does this have to do with what roles are available in an organization?
It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.
> It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.
There are 2 distinctions and that's what might be confusing. 1 is your experience/level and what you're referring to. The other is the roles an organization offers.
I might have 50 years of experience but if the other roles are taken by more qualified people in THAT organization I can take a normal engineer route. Doesn't have to be senior. It doesn't make myself not qualified to even be a CTO elsewhere.
The roles are fixed. It has to do with budget, balanced, etc. Having all seniors might mean fights and everyone wanting to contribute and pull the project in different directions. A good balance is needed. A senior heavy team might not be good just because you can.
I understand (and agree with) the distinction you're making. An employee's level isn't necessarily the same thing as the level an employer needs for a specific role. The latter sets a desired minimum for the former. And realistically the former usually implies some kind of desired minimum for the latter if only because working at a much lower level than you're capable of will reduce compensation and slow career progression.
Where we perhaps disagree is your final paragraph. The roles might be fixed but there is no rule that says they have to be. Usually things like budgets and the work that needs to be done that are fixed for the team as a whole. An employer might have multiple hiring options available that fit those constraints - for example hiring a smaller team of more senior developers or a larger team with a wider range. My argument above is that if you can hire a smaller team of good senior people then this is often cost-effective.
I don't really recognise the picture you're painting of a senior-heavy team being prone to conflict. A big part of that ability to operate autonomously that I suggested characterises senior developers is learning how to communicate and collaborate effectively without needing constant intervention from above or heavy formal development processes.
What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors. The team doesn't reach consensus and get behind its choices collectively. However it also doesn't have the stronger leadership and safety rails that less experienced developers might need to be effective. I agree that situation is bad but it's not what I was advocating before.
> My argument above is that if you can hire a smaller team of good senior people then this is often cost-effective.
> I understand (and agree with) the distinction you're making.
Isn't this contradictory?
That's the trap we're stuck in. I remember Amazon HR saying their Senior titles are the equivalent of Staff Engineer titles elsewhere.
You can hire a highly experienced small team and pay each of them more. They don't all have to be "senior" in title and responsibility. They're just engineers. Fixed budget divide by the number of people (roughly) has nothing to do with titles. It only does according to some system where compensation is tied to titles.
You've said you understand the distinction but then some sentences later have just walked it all back.
> What you described seems like what happens if you want a senior-heavy team, hire people who aren't at that level yet, then still manage them as if they were seniors.
I repeat, you're after an experienced/skilled team - not senior-heavy. E.g. you may need someone highly experienced in React and Rust with 50 years experience. It doesn't make them senior. Working autonomously doesn't make you senior.
I agree that was typically also something that came in at senior level.
Maybe it's a regional thing? I'm in the UK. I'd say it was fairly standard here for a junior to be someone in the first couple of years on the job who was still learning the ropes and probably couldn't do much beyond very basic grunt work without the assistance of someone more senior. Losing the "junior" label came when you got beyond the near-full-time hand-holding and started doing routine stuff independently. The "senior" label came when you could do the less routine or more difficult stuff mostly independently as well.
What does this have to do with what roles are available in an organization?
It means an organisation that wants to hire a senior-heavy team can now do so. That wasn't realistic for most organisations a decade ago because there weren't enough seniors to go around.