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.
This is complicated during acquisitions… you have a new company coming in and leveling them is hard because it’s a mass title migration exercise, and nobody wants to be down-titled.
In the 2 examples I’ve seen gone wrong:
-the people at the parent company look at the acquisition’s team and think, “there’s no way this idiot should be a director.”
-the people at the startup think they’re geniuses because they got acquired but their tech is crap and they’re actually just 28 year olds running around without adult supervision
-the startup guys will all leave once they vest or be pushed out for being lousy
-the tech gets even more unstable because no one left knows how the code works
Failed to design Quantum Lattice Bloom Cascade algorithm in 5 minutes?
For a good interviewer these people are obvious even without any coding tests.
As a hiring manager, this is completely accurate. I don't look at your title, I look at your scope. Tell me what you did, for whom, and what was the impact. That's all I care about.
We all know that Senior Principal Architect Engineer at 3-person startup is somewhere around junior to mid-level at a real company. Whereas some poor schmuck at a larger company with a title like "Senior Engineer I" probably owns and runs more impressive systems and works with more stakeholders than that 3-person startup will see in a year.
Maybe. That's why you need to put your scope on the resume :)
I had a CTO title 15 years ago. The complexity of what we were building was a joke compared to what I own now as a lowly "tech lead manager". And in fact back then I wouldn't even be able to comprehend how complex things can get.
I can't know you ran a 30 person scale up unless you tell me. It doesn't have to be in those words exactly, usually it's tied to ARR or rounds raised or something you can easily talk about that translates across companies.
I've seen resumes with titles like "Lead Engineer" who under that title put something like "Hired 45+ people to run <huge systems> at <company you've heard of>". That person has more scope than the 30-people CTO in your example :)
PS: 30 people isn't even that many for a whole company. That's a Series A startup with early signs of product-market-fit. It's common to see a ratio of 10 employees for every 1 engineer in the company.
The rest we can hash out in interviews, reference checks, and reaching out to mutual network connections at higher levels. Nobody gets hired just off their resume.
That is to say: All line items are verifiable if we care enough. Tech is small :)
Instead you become a generalist which is only really needed at tiny organizations.
At FANG size companies have people to setup 401k and health insurance, tiny startups need 1 of 3 people to figure that out even if it just means finding a company to outsource such things it still needs to happen. Payroll doesn’t need to be a complex system but taxes must be paid etc.
Expertise gains value when it can’t be subdivided. A doctor needs to know a who lot of related skills to be a heart surgeon, it doesn’t work to split it into two less demanding roles. However two generalists can sub divide the workload of a generalist with a lot more experience because experienced generalists aren’t particularly skilled at anything.
But big companies would definitely love to have to pay a single salary for someone who does 401k and when this job is done administrates databases then in between reviews tweets searching for mentions of the company. Exaggerated example but I hope clear.
That already shows up with everything getting „Ops” obviously DevOps but I already have seen DataOps, SalesOps and MarketingOps.
No I mean
> Tell me what you did, for whom, what was the impact.
It's really that simple. Just tell me what you did at your job. What was it that you worked on. Why did it matter. Did you own a workstream (or 5), code monkey all day, own a critical service, play code janitor, ... what did you do?
This is what I did in some interviews already. But maybe I can adapt my CV a little as well.
The problem is, "scope" is often equated to "how many people worked in my empire" rather than "how much business value did my work X generate".
The two things are vastly different, and I have seen the distinction/oversimplification play out over and over in my own career as well as many others around me.
As an extreme on the "individual technical expert side", there are things out there that can pretty much only be accomplished with a few people around the world who possess the dedicated expertise. These results can't be replicated by a cobbled together team of 10 or 100 people even though the latter sounds more impressive for "scope".
Some organizations do a decent job of recognizing these different "archetypes", many don't.
When looking for a manager type, people under management are a decent proxy. When looking for the world's greatest postgres optimization expert, some version of queries-per-second is prob the metric you want.
Or realistically if I needed the world's greatest Postgres expert (and could afford them), I would go talk to experts in the field and ask "Who's the best postgres person you know?" and work from there. At that point your resume is but a formality.
In my experience distribution of engineer quality is even across companies, countries, ages and any other dimension we can come up. Certain big scale skills can really only be practiced at honed at large tech companies, but it’s always a small minority that actually make those things happen. Resume alone can be an extremely misleading signal.
Titles are fungible, but your comp isn't. Don't let a company sell you on a better title for less comp, especially when the JD or role doesn't align with the title; the next place won't give a shit what your title was if all you did was Junior-level work because you bought into someone else's narrative rather than control your own.
A few teams have a "lead" role, but its mostly ceremonial.
- 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.
But the big difference, I believe, is that being at the top of a ladder in one company may be completely different from being at the top in another one.
It's easy to be the CTO of a company of 2, much harder for BigTech. Even if the company of 2 has the same levels.
I have met people being very very proud of their title of CTO, and when I asked, their company had a handful of developers.
The idea is that command requires a separate set of skills and that experience needs to start early to have senior officers in their 50s.
In practice, junior officers are "advised" by senior enlisted on how to order people around and not taking that advice is a bad idea.
Kind of like how companies have managers and technical tracks where a line manager ignoring a senior technical person always blows up in their face.
Doesn't it mean more like it's an acceptable end, a destination - obviously not everyone's career track is to take over the company as CEO one day, but nor is it necessarily to progress to Staff and beyond.
The idea being that it's a bit of a role change, to a greater extent than the levels before it which could be seen as advancement. Or, we've long had the idea of 'technical' and 'management' tracks, the more recent (I think?) idea here being that actually maybe they're both specialist tracks you switch onto, and you don't necessarily have to do either.
But I think, outside FAANG et al., whether companies subscribe to that sort of thinking is vastly more varied (or it's more niche) than titles and 'track' splits (or lack of them) already are.
Everyone is expected to be a VP, if not you move out. But you can stay VP forever.
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.
It doesn't make a big difference to the company, but a lot of employees want these titles for ego / resume / status / recognition. And titles are free for startups to give away, so many do.
I've worked at pretty much every size company imaginable.As the top post pointed out, these titles are meaningless across smaller companies. I've been at startups where nobody had titles at all, I've small companies where anyone remotely senior as a principal. I've also worked at large non-tech companies with only 3 levels for IC, after that you were expected to transition to management.
Large, tech companies have some degree they can be compared but what these titles mean from company to company is pretty meaningless.
I work in cloud consulting (specialize in app dev).
I worked at AWS ProServe (full blue badge RSU earning employee) before working for a much smaller company. I’ve seen the leveling guidelines for both.
An L5 (mid level) at AWS had to be a subject matter expert in at least one area (development, DevOps, security, etc) and be able to lead a “workstream” of a larger project including dealing with a customer or a smaller project by themselves. That maps to a “Senior Architect” at my current company.
A senior (L6) at AWS should be able to handle larger projects with multiple workstreams and deal with more ambiguity. That maps to a staff at my current company (current position)
An L7 is usually over a practice and/or handling multiple large implementations and more involved with strategy. Imagine someone (who hypothetically - they don’t need outside consultants) was working with Netflix.
That maps to a “Senior Staff” at our company.
You might ask what about lower levels in consulting? I never work with them. The bilingual cloud architects/senior cloud architects work with them. We don’t hire anything lower than that in the US.
As a hiring manager I'll look at progression of titles *within a company*. This shows a track record of upward mobility. But if they go from "senior" in one company to "principal" in another, I find it meaningless.
That's quite shallow for those who are 'Member of Technical Staff' which does not have this which is why titles are meaningless for experienced candidates.
Someone can give themselves that title, all because they know the founders; thus it can be exploited.
So instead, I get the candidate to exactly explain to me what did they actually build / do and how much money did they make / save the organization and it must be in the millions to qualify or did they build side-projects that contributed to this or not.
In this era, "titles" aren't enough and you need verifiable proof of work with monetary returns in the millions and I favour those who just build things that make money without asking permission from a manager.
While I like this approach personally, it's worth noting that lots of companies will fire people like you say you want, particularly if their manager is threatened by them (or they're difficult to work with etc).
The "staff engineer" at some random series B startup 4 years into their career nearly always gets hired in at mid level somewhere like Meta.
What else would they be able to use?
There seems to be an understanding that happens, which means they ignore it.
I tell them what my range is. If they don't want to meet my range, then I tell them to GTFO.
Isn't that what everyone does?
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.
You can be a “CTO” of your little 5 person company - you might be leveled as an mid level software engineer at BigTech
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
its entirely possible to go through the software engineer hiring pipeline, and end up in a situation where the organization and the new employee have a fundamental disagreement about the slate of work.
somehow in the giant waterfall of money, our ability to even talk meaningfully about our work to each other got lost
If we measure principal engineers by "cross team force multiplier impact and its visibility to management" (second part being key), what kind of behaviors do we incentivize? Are there, possibly, bunches of mid-level and senior engineers dealing with extra hassles to demonstrate this impact?
My journey up from Senior/Staff was mostly on the back of proposing and then leading cross-functional projects.
Which means I was doing Principal work before being granted the title. To be honest it was (and remains) a huge amount of work and I wouldn't continue doing it if the recognition and compensation hadn't been forthcoming in the following perf reviews.
If you are doing this stuff and aren't moving up where you are then you should be going somewhere else as that is probably a very exploitive work relationship.
One case in particular, there was a re-org and the new org lacked principals but we had a common vision and a bunch of pieces in place. We needed a new vision that was led by the new principal, for obvious reasons. Whole thing was set back by a couple years while this was figured out. The existing, well-functioning pieces (with lots of users) were shipped to India teams for maintenance while the org slowly figured out facsimile pieces.
I remember that 10 years or so ago, an E5 in Google is considered a pretty prestigious position. In Amazon, L6 is such a high achievement that the entire India site had one L6 for more than 300 engineers. But somehow things started to change. Everyone expected herself to get promoted every couple of years. There was a joke in Amazon along the line of L8 is the new L7.
My guess is that two factors came to play. One is that Meta (and then the Facebook) started to promote people really fast, so other companies followed. Also managers gradually treated promotion as a tool to retain the people they need. Once that's the incentive, a long title ladder becomes a natural choice.
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.
Or your support team could wind up owning it without even knowing that they own it.
Plan for who's gonna own the product because someone will, and that task will just settle somewhere random if you don't specifically assign it.
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.
That said, in general for any given comp package, I’d want the lowest possible level I could take and get that package. That gives more upward runway.
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.
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.
Which is actually an issue in our industry, I think, and it's causing widely different expectations and skills in different companies. A "lead developer" for company A might be considered a medior at best at company B.
Product manager titles can have completely disjoint scopes of work between organizations - in one org they might be what was once systems designer role - getting requirements and writing specs, in another they might basically be doing UI or UX (even creating pages in figma), in others they are basically project managers.
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.
small companies typically go the other way, using titles to make up for concrete remuneration. This is why everyone in a startup is a VP and ICs climb the ladder to senior in a couple of years.
Another thing I've noticed happening is that if these companies grow into medium sized companies, these OG employees actually become VPs and directors whether they are qualified for these roles or not. Just by virtue of them being there first. I've worked at enough medium sized companies and have seen this at every one of them: "Why is this moron SVP of engineering?" "Well, he was employee number 5 back in the day."
A "top" position in a small company could be a mid one in a big tech but with a narrow field compared to the small one when sometimes you need to refill the coffee machine. At same time the flexibility of small one helps to solve problems of big ones.
Overall rather petty and boring.
Beyond that, agree it seems like it can just be anything in virtually any title
All the responses here won't admit that it is entirely made up, and designed to be built around a structured hierarchy which rule followers and obedient servents to the system to get closer to the $$$ printer.
It takes a lot of back-stabbing, office politics, credit stealing and dishonesty to get to "the top", which is what the replies won't tell you.
> 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.
Here is a case study, would you interview at Meta today and work under someone far younger than you and has a more 'senior" role than you? You do understand that the "title" was made up and "created" for a particular position?
Heck, you could even build your own startup and give yourself that title if you wanted to. But the majority here will not and will work for companies like Meta under EMs that have no idea what they are doing.
Therefore it is all made up. With some "staff", "leads" and "principals" are making it up as they go along and coasting as the low rankers hold the fort as the ship sinks.
entry - needs mentoring to get stuff done mid - can build the whole thing by themselves, given enough time senior - can guide entry and mod to the same overall task and break up work such that both can do it. organizes and coordinates work across multiple teams principal/staff - sets direction for many teams worth of engineers
above that stops being so meaningful, except for directing where major engineering directions go, and is kinda more of a sales job about getting a lot of engineering managers pointed in the same direction.
a lead is orthogonal a bit, but reasonably a flavour of senior. you could have several seniors but only one lead in an area, who's a bit obsessed with a topic, and has the idea of where things are going.
> Here is a case study, would you interview at Meta today and work under someone far younger than you and has a more 'senior" role than you? You do understand that the "title" was made up and "created" for a particular position?
yes? i set up projects and gave feedback for people younger than me to get promos, and they did the work well and showed that they can do that work. Just cause didnt want the promo doesnt mean they didnt show their skill. Age is just a number. The youngest principal i met is by far still the best and most effective one (other than the sandbagging senior-principal)
Each company has its own way to name things.