I cannot be alone in feeling that titles (within "tech" in particular) are almost completely arbitrary? What constitutes a "senior", "lead", "principal" and "staff" X, respectively, has so much overlap that it really depends on the organisation. I myself have been called all of those things, but have honestly not been able to tell the difference: in some cases, I have had much more responsibility as a "senior backend developer" than a "staff engineer". I have recently interviewed for a number of roles with titles like CTO, engineering manager, tech lead etc and there is so much overlap that they seem to be one and the same. Have worked at companies on three continents, in organisations ranging from 6 people to 10k+, so have seen a few titles.
As others have said, levels and titles are generally for compensation and performance reviews. Each company has their own bespoke ladder but it generally maps to:
- L1: Intern with undergrad degree
- L2: Intern with graduate degree
- L3: Junior
- L4: Intermediate
- L5: Senior
- L6: Staff
- L7: Senior Staff
- L8: Principal
- L9: Distinguished
- L10: Fellow
Each company has their own numbers and names but it generally progresses like that. Impact and scope scales as you head up the ladder.L5 or Senior is usually considered a “terminal” role. That means all engineers should be able to get to this role. And people without the headroom get managed out if they can’t get to L5.
Staff+ is usually “special”. It means that people count on you to drive initiatives and you have something special other than just writing code. You are able to make product and business impact.
Distinguished and Fellow are very rare. Large FAANG companies will only have a handful of these engineers. It means you’ve made industry-wide impact like inventing map-reduce or DynamoDB or Kubernetes.
There's a wide variance, but there's been a lot of 'title inflation' over the past decade that has more to do, I think, with giving people incentives when they don't want to stretch the equity package any further.
Titles for ICs matter for two reasons: comp, and perf reviews. At bigger companies the amount of RSUs for Staff versus Senior can be substantial. At a startup where equity is worth nothing and salaries are in a tight band anyways it doesn't make a difference.
For perf reviews your title dictates the rubric you get evaluated against, but in fact your manager is probably trying to fit a curve and then work backwards to the rubric. So they'll decide you're a 3/4 and then pick some boxes for your weakest areas to mark you down in. The realpolitik of it is that you can do the same work or more at a lower level but get paid less, depending on what you negotiate coming in, your experience, previous roles, etc.
Once you get into VP, Director, and C level they are comparable between orgs on their own kind of ladder. There's levels of responsibility for outcomes associated with being higher in the food chain. Not to say there also isn't a political aspect, but they are broadly comparable between bigger orgs.
Titles make no sense whatsoever, you're correct, but in nearly all organizations there's a split between IC track and manager track, so the argument the OP is making is debatable but it's not absurd on its face.
Rant:
I was a systems engineer for a while there.
But not a pure S/W one. Like an actual engineer with nuts and bolts and pneumatics and amps and bolts and the like. That was the title at many many companies, it was a pretty rigid one too, despite the job function being quite jack of all trades.
But then tech decided that they wanted to use Systems Engineer too. The reasons weren't bad, I guess.
But then trying to find a job in my version of the role was near impossible on any job site.
Unix this, Windows that. Sure, I used Unix systems for my job too, little servers for controlling some mechanical systems. Not like huge racks that served up billions of requests.
And then I'd get the job spam too, as I matched some keyword threshold for the S/W type systems engineer. Always a entry level role through.
Gah! Why couldn't S/W take the title of Unix Server Engineer, or Python Integration Engineer or something just a tad more specific and not bleeding all over my discipline?
Okay, whew, rant over
At my organization you can't get a raise beyond inflation percentages unless you go up a title.
It wouldn't surprise me if it's a way of gatekeeping salaries since years of employment typically outnumber the levels of title that are achievable in one's career.
Same for "programmer", "software developer", "software engineer", and so on. People insist that there's a real difference even when I have been all those things and there was no difference.
Your job title encompasses the highest-order bits about who you are, professionally. The value is much more between organizations than within a single one.
If you plan to stay at one place for a long time, it's much less important. You have a chance to figure out how things 'really' work in practice. I know a guy who is a senior architect, and everyone refers to him as that at his company, but his actual on-paper title is something like "project technical lead". It's just not very important if you are going to stay there for 20 or 30 years and chase deep breathing metis.
I don't have the same career outlook, so my job title is important to me. I actively negotiate for it. My own title is "senior DevSecOps engineer". Criticism of the acronym notwithstanding, this paints an instantly legible set of competencies around what I do best, what I do adequately, and what you probably would get better value for money paying someone else for. I'm probably pretty good at vulnerability management and securing CI/CD pipelines. Optimizing weights on our anti-spam logistic classifier is probably not the kind of thing I can do well. Etc., etc.
Within a given company, I think these roles are well-defined. In a big tech company, a principal engineer will influence decisions at a much higher level then a senior whose isn't visible outside his team. And an engineering manager support, evaluate, represent the team, and help with goal alignements.
This is exactly why we built https://www.levels.fyi
Too often people were getting down-leveled because they didn't know any better. The level comparisons we show on the homepage compare scope and responsibilities. People frequently think levels are based on compensation but compensation is the byproduct of it.
One thing that's worth remembering is that companies - especially in Silicon Valley - use titles as a way to compare salary levels with each other.
If you are an engineering manager looking to make the case for raises for your team members one of the tools you have available is usually an anonymized survey of similar compensation levels from other companies.
You can say things like "this person is a high performer and is being paid 85% of the expected level for this title at other companies nearby - we should bump them up".
Your company may use job titles in a non-standard way, but there's probably an HR document somewhere that attempts to map them to more standard levels in order to make these kinds of comparisons useful.
I don't know how this works in other industries or countries, but I've seen this pattern play out in San Francisco Bay Area tech companies.
It's an artifact of humans being obsessed with hierarchy and pecking order.
Overall rather petty and boring.
>are almost completely arbitrary? What constitutes a "senior", "lead", "principal" and "staff" X, respectively, has so much overlap that it really depends on the organisation
Titles at least useful to understand the hierarchy, but roles truly mean nothing. Sometimes the adult in the room is a PO, sometimes it's EM, sometimes they are responsible for the timelines and "project stuff", sometimes it's a Senior Engineer. In some places a QA is effectively doing PO stuff.
Outside of the FAANG style companies where how their levels map to each other are well known, titles are only useful to compare within the same company. You can't compare a specific title between two companies as they may not even have the same hierarchy much less requirements & expectations.
Yeah. "You already know what a title is, Neo. A title is a text field attached to a pay grade."
My employer has no formal titles for engineers pretty much for this reason.
Main distinction I tend to see is just whether you're doing line management or not, which tends to be the EM track
Beyond that, agree it seems like it can just be anything in virtually any title
> titles (within "tech" in particular) are almost completely arbitrary
It wasn't like that some years ago.
Senior back in the days is probably your lead / staff of today.
The problem isn't just the companies but people and their expectations. You have people crying about not being made "senior" for having 2 years of experience and the world is blown apart now.
So is every company evil or broke or the social media culture these days expecting instant feedback etc?
You used to work 10+ years as an engineer and just that and it was fine.
Personally, I don't give two shits about my title. If I could just be "computer programmer", I'd be happy. But the org likes titles and as long as I have to play that stupid game, I try to get titles.
> that it really depends on the organisation.
This is entirely it. Titles should be consistently ordered within an organization, but they are not portable from one organization to another.
This is a lesson I’ve had to explain over and over to people at the beginning of their careers. I’ve been asked for advice about which offer to take from people thinking about leaving 10s of thousands of dollars on the table because another company will give them a Senior Engineer title and they think that’s important.
When hiring, titles are basically ignored unless the person is coming from a company like Microsoft or Google where their leveling system is publicly known.
I’ve interviewed so many “Prinicpal Staff Engineers” or even “CTO” people who would barely qualify as senior engineers at an average company. I’ve also interviewed “Senior Software Engineers” who had more experience than knowledge than anyone on our teams (and that’s saying a lot!)
Hiring managers know this, but it’s not obvious if you haven’t done a lot of hiring or worked at a lot of different companies.