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.
> 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.
> When hiring, titles are basically ignored
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.
I think that engineering at a large organisation and engineering at a startup are two completely different disciplines with very little crossover.
Interesting, you've got it absolutely the wrong way around.
> Interesting, you've got it absolutely the wrong way around.
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.
> That's why you need to put your scope
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.
I agree. What counts as a positive signal for "scope" really very much depends what you're hiring for.
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.
That may be your anecdote but CTO at a 30-50 person scale up would typically have much more management/accounting/signature/high-stake conversation/... experience than a senior developer at google.
Yes. Which is why it's important to put scope on your resume.
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.
An unverifiable line item on a resume gives you real insight on an individual's experience and skills? I think your system is flawed.
It gives me more insight than a blank resume with just job titles.
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 :)
But that's nothing to do with the comparison he made, which was "at 3-person startup"
When you swap between 9 hats, you don’t get meaningful experience at any of those roles.
Instead you become a generalist which is only really needed at tiny organizations.
Big organizations need generalists too.
Generalist means something very different for big orgs.
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.
I would say I look at it from a different angle, big companies can afford specialists. Startups cannot afford specialized employee for database administration or setting up 401k.
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.
That shows an ability to figure out what needs to be done and do it, regardless of whether it fits the formal job description. That can be an invaluable skill in an organization of any size.
It's the story of foxes and hedgehogs... Both have a time and place. Sometimes you need people who can aggressively put out fires, and sometimes you need people with deep focus for the long haul, who aren't overly distracted by the heat.
It’s a valuable attitude, but not a particularly valuable skill.
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.
Well, what do you even mean by "put your scope on the resume"? Do you mean literally "Scope: blabla" for each occupation? Or do you mean something more implicit?
> Do you mean literally "Scope: blabla" for each occupation?
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?
Ah OK, gotcha, thanks.
This is what I did in some interviews already. But maybe I can adapt my CV a little as well.
There's a lot of cogs at big companies, but the impact of the entire company is huge. Startups usually have small impact. Usually at these big companies there's quite a few atlases holding the entire world up.
Sure also in big companies there are plenty of places for low performers to survive by owning some very small and rigid scope that doesn’t require any real end-to-end thinking.
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.
The engineer at the startup may have a broad scope of responsibility and ownership, but also might be working on relatively small systems that have not needed to scale yet.
- [deleted]
[dead]
This is why I align on comp ranges rather than title. I've been a "Lead" where all I contributed was a new imaging pipeline and introducing NAT to the product line, a "Manager" of a failing company where I had no managerial authority or direct reports, and a "Senior" at a SV firm where I actually behaved a level above a Senior Engineer - owning outcomes, doing research, mentoring juniors, building relationships across silos, governance councils, etc.
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.
I've worked with several "Directors" that all had between 0 and 3 reports. Vanity titles make people feel good and look nice on a resume, but that's about it.
"Lead" is a funny one, because its just not a level that exists where I currently work.
A few teams have a "lead" role, but its mostly ceremonial.
100%
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
In pretty much any software startup acquisition by a much larger company, even if they do technical due diligence up front they have to assume that all the code will need to be rewritten within a couple years. It's good to keep a few key technical resources around during the transition period but otherwise a high attrition level is acceptable.
>> I’ve interviewed so many “Prinicpal Staff Engineers” or even “CTO” people who would barely qualify as senior engineers at an average company
Failed to design Quantum Lattice Bloom Cascade algorithm in 5 minutes?
More like: Couldn't cite anything they accomplished and had no real responsibilities.
For a good interviewer these people are obvious even without any coding tests.
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:
Each company has their own numbers and names but it generally progresses like that. Impact and scope scales as you head up the ladder.- 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: FellowL5 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.
You're describing a very small number of companies that all copied each other's systems. The idea of a terminal role, for example, is pure Facebook. These do not apply in general across the industry except where managers from those small number of companies came in and shoved them in before they were fired.
In all fairness, a LOT of this was copied over from the military. From ranks to "High Year Tenure" (aka "Up or Out") nothing here is particularly innovative.
Amazon had the concept of terminal role (SDE2, but I’ve heard it has changed) long before facebook existed.
In my experience a lot of tech companies, at least in the Bay Area, have all copied this system.
I believe L5 was Google's terminal role at one point (over a decade ago) - not sure if it's changed since then.
It became L4 ~5-7 years ago, but who knows these days.
Terminal roles are definitely not a Facebook concept originally … Microsoft has had it for at least 20 years.
I'm guessing the terminal role is the 64 Senior? That's nearly everyone on my team. Someone has to retire or die to get a shot at Principal.
> L5 or Senior is usually considered a “terminal” role. That means all engineers should be able to get to this role.
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.
In my experience, it's the highest point you can reach before you have to deal with politics on a daily basis.
This does remind me somewhat of military command structures with L1-L5 being enlisted ranks and L6-L10 either being NCO or Commissioned depending on your view of how much gatekeeping is involved.
Western militaries have a parallel commissioned officer and enlisted command structure where an O1 (junior officer) is technically senior to an E9 (senior enlisted NCO) and can order them around.
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.
At Microsoft I would map your L6 to Principal, and L7/L8 to what we call "Partner". I'm a Principal, but I'm definitely not an 8 out of 10 yet.
> Each company has their own numbers and names but it generally progresses like that.
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.
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.
> At a startup where equity is worth nothing and salaries are in a tight band anyways it doesn't make a difference.
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.
They matter within a company for the reasons you cite. They mostly don't matter between companies however.
You don’t think companies look at your past titles when you apply for a job?
The title only so matters to the extent the company is a known entity.
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.
They may, but the amount of information they're getting is low.
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.
> As a hiring manager I'll look at progression of titles within a company. This shows a track record of upward mobility.
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.
> 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).
Titles are what “salary comparisons” go by when HR “compares” compensation between employees and “competition.”
What else would they be able to use?
> What else would they be able to use?
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?
I was promoted to senior software engineer three times in my early career. They just tossed out the title as a freebee more-or-less, and the hiring companies told me I was too young/inexperienced for it.
There seems to be an understanding that happens, which means they ignore it.
Why do you think that? Senior, staff, principle levels are pretty standard across the industry, even if some companies call them different things
This is definitely not true. It’s all dependent on the company size.
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.
I'm guessing you've only worked at very large companies, specifically tech companies then?
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.
They're somewhat standardized in Big Tech in that people have worked out how to map titles across these companies. But that accounts for a very small fraction of the total industry.
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.
Titles mean even less across organizations. Any interviewer worth their salt is going to hire you and level you based on how they ascertain the level of scope , impact and dealing with ambiguity you dealt with.
You can be a “CTO” of your little 5 person company - you might be leveled as an mid level software engineer at BigTech
metis?
- [deleted]
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
this is not at all restricted to your case. try 'distributed system engineer' or even 'software engineer'. for the latter, one is an engineer of software, and the other is one that engineers with software. both perfectly valid jobs. it doesn't help that the interviews for the latter adopt the questions and expectations of the former, even though they are different jobs.
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
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.
> I cannot be alone in feeling that titles (within "tech" in particular) are almost completely arbitrary?
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.
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.
in canada theres a meaningful difference. Engineers are either EITs or have a professional stamp
It really is arbitrary; I've never really been called senior or whatever, but apparently some people with 3-5 years of experience are already called that. It feels more like politics than a proper scale.
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.
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.
Maximally cynical take, tongue somewhat in cheek:
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?
Sort of?
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.
It sounds like you were one of the actual Principal Engineers, then. In my experience, there are some who had presumably done some of that in the past but now had to maintain their position by generating "cross-team impact" which was mostly just a PITA to actual practitioners.
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.
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.
Firstly, I love levels and thanks for 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.
I just got a new job, hired as level 5 with official title Software Engineer (Mid-career) although my boss tells me I'm Chief Engineer. All the level 2 people on my team seem to be Senior Engineer or Lead Engineer.
I always think of the Gervais principle when it comes to titles - that they really just exist to provide illusory advancement and to get some of the minions to lord it over some of the other minions while the folks at the top of the organization benefit.
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.
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.
I went from Programmer to Staff, moved to Senior, jumped again to Lead, then only "Developer" promoted to Senior.
Each company has its own way to name things.
Engineering titles at least have a few things that are nearly universally shared (such as actually needing to code, expecting to mentor).
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.
>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.
> 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.
Titles are really a trap cannot reveal the real work, everything it's related to the size of company, type of organization and sector.
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.
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.
>> use titles as a way to compare salary levels with each other.
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.
> 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."
This brings back memories of the candidate who demanded coming in as a high level engineer. Their argument was they were currently a CTO. Of their 2 person company. While they were still in college. And they were only borderline hireable for our entry level role.
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."
It's an artifact of humans being obsessed with hierarchy and pecking order.
Overall rather petty and boring.
My employer has no formal titles for engineers pretty much for this reason.
Titles are meaningless. Many tech ICs at top companies have more influence and responsibility as well as pay than managers at low tier companies.
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
I am also not surprised that many P.E. have become Political Engineer as opposed to Principal Engineer.
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.
It’s how good you are at politics, that’s it. Big modifier if you’re tall and attractive.
Wait until you meet a VP in finance.
Titles are arbitrary (as in people with different titles can do similar work), but compensation is tied to a 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.
> 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.
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.
i think i could reasonably drscribe a difference.
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)
It's all about perception. People love fancy titles, even though it's ultimately meaningless. I worked with several "directors" that made much less than I did as a staff+ level engineer.