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.

  - 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

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.

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.

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

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.

Because a manager at a structural engineering company is essentially acting as the equivalent of what a Product Manager or Forward Deployed Engineer is in the tech industry, because they are expected to be a technical domain expert and own delivery.

Meanwhile, for most software companies the underlying codebase isn't want generates revenue - it's the codification of business logic that does. Additionally, companies tend to have a separate Princiapl Eng to Distinguished Engineer/Architect track that outranks EMs and is in direct contact with leadership.

> Is it this MBA idea that management itself is a profession, rather than being 'a higher level thinker than the others'

Most Engineering Managers and Beancounters aren't MBAs - no company wants to sponsor an employee at a PTMBA which can cost upwards of $250K now.

Yes, just like an Office Hierarchy there's an expectation that they respect the Rank - based on the caveat that the Officer/Manager doesn't confuse Rank with Authority.

Also, to clarify some previous assertions, VP title is often needed to empower a given member of staff to sign contracts on behalf of the company in certain jurisdictions or configurations.

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.

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.

You can be a “CTO” of your little 5 person company - you might be leveled as an mid level software engineer at BigTech

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

I'm not saying that to be snide. When you come from a academic CS setting like university, there are so many new things to learn in industry that after 5 years you could still be completely unfamiliar with a lot of things.

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.

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

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.

Failed to design Quantum Lattice Bloom Cascade algorithm in 5 minutes?

EM is a terminal position that does not own the product roadmap (Product Management) nor the underlying implementation (Staff/Principal Engineers).

They primarily own delivery and execution because orgs can't be bothered to hire program managers anymore.

If you are great at managing upwards and ensuring delivery by hook or by crook, you will make a great EM. But the next jump after EM is extremely difficult because you are competing with Principal Engineers and technical-minded PMs making a lateral move and cofounders who are being managed out by the board; and dealing with micromanaging CTOs or CPTOs.

Not really.

Staff Eng and above will end up making similar to an EM including bonuses and has much more job mobility. You have to remember that most EM roles only open up once you hit Staff, so you are basically taking much more responsibility and longer hours for a marginal salary impact.

Engineering Manager jobs are hard to come by and your job security is actually less than an individual contributor, because even if an initiative was delivered late due to no fault of your own, if sales is braying for blood in order to protect themselves after failing to meet quota, it's the EM's head that is offered on a silver platter.

The reality is, there are very few EM and above jobs, and job security is tough - if I have to choose between firing an EM or a SWE, I'd fire the EM first because I can always find another replacement or split their responsibilities across multiple individual contributors and the PM.

If an EM is laid off or fired, it's extremely difficult to find another role, and it truly is a terminal position. Why would I hire a laid off or fired EM or Director when I can promote internally or hire someone from within my network?

Additionally, back when I was an SE, if we had a deal go bad in order to protect our ass we'd blame the EM so that we can have a head on the platter to hand our CRO, unlike a seasoned SWE who can push back and argue PM requirements were unclear and PM can argue that sales+product was aligned.

For a good interviewer these people are obvious even without any coding tests.

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.

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.

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.

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'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.

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.

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.

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.

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.

I've never heard of something like that. Usually the requirement for being director level manager of engineers is to at least have managed people as an EM for several years before.

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?

Instead you become a generalist which is only really needed at tiny organizations.

Was it the devs fault for shipping code with a disastrous edge case, or the EMs fault for over- allocating work, resulting in less-refined code and a minimal review process that let the defect slip into production? Just as an example.

There's a lot of nuance but here's a simplistic overview: a manager tries to land a big project for their team, which lets the team stretch their abilities and grow, which over multiple successful deliveries results in promotions / raises for everyone involved AND the cachet to ask for bigger projects (and more headcount!)

The manager's role is the hustling and jockeying in landing the project, ensuring their team is executing and getting any mentorship needed (directly or indirectly) and protecting them from disruptions ("shit umbrella") -- which includes managing everything around the team including stakeholders and dependencies and escalations -- and then making the case for promotions / raises / PIPs based on their performance.

I've never been a manager, but having been involved in all these aspects, I can tell you none of this is easy. All of these can get very contentious, even in the best-run of companies; in the rest, a lot of pathologies spring up (like politics and empire-building) that cause even more nastiness.

So it may seem like they're taking credit for your work, but that's literally part of the arrangement, and it's only unfair if you're not seeing any upside. If you feel that way, this is 100% something you should bring up (very tactfully!) in a 1:1 or (even more tactfully!!!) a skip-level.

Isn't that what product/project managers and architects do though?

Other comments describe EMs as just HR mangers

> If you can't make that decision, are you really the EM?

You'd be served well as an EM by this part of the Serenity Prayer:

"God, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference."

Depending on your organization, odds are high that AI use is one of the things you cannot change. Perhaps not even something you're ought to change. If your team is delivering x% more, "it makes my job x% more difficult so don't do that" won't fly neither upwards nor downwards.

> If AI produces code that no one knows and is hard to maintain

I think you're making an assumption here that the main problem with AI use is necessarily quality.

OP wasn't even talking about AI producing bad code, just that it creating more code, and enabling more things to happen. More things going on at the same time, means you'd have more friction points and more things that can go wrong. Whenever those happen, the EM is pulled in.

You attend meetings, negotiate deadlines, evaluate people, navigate project minefields, take decisions or force people to take them,... and the technical aspects are quite minimised.

Depending on the company this is not an upgrade, it's a lateral move. I have people under me who earn more than me, and I agree with that.

The job it's not easy, it's different. Spending 5 hours on meetings it's easy, but exhausting. Giving credit to your people but taking the blame (which is what should be done) it's easy, but demoralising. Not having a peer group of people with whom easily socialise makes the job feels lonely, when you talk with other managers it's 99% work related, and you can't make your people like you as a person.

Most days I'd love to have a clear objective.

One of the worst is the strange feeling that you have because you've studied for a long time some skills, and worked using them, and now those are hardly used. You need to use a set of skills that you haven't trained for, and haven't used as much (depending on your personality/skillset, of course).

Being a manager is not for everyone.

Sure, but now competitors are shipping like crazy (at their EM's sanity expense?). What to do?

> AI is voluntary

Until the company mandate. And also there 10 other EMs that I am competing with on my org tree alone, and their teams are all AI-heavy. Is that really a matter of choice?

The question really is why does American tech organise itself this way, a completely different way to other professions?

> The EM role only exists to hire, evaluate, promote, and fire SWEs

I can see why some people would find that unfulfilling. I work in one of those other professions and if I did just the hr bit I would be bored out of my mind! Do SWEs value the input of their EM? Does it really add value, or a bunch of busy work?

What does a manager even do in this world where they are non technical? I have never managed a large sw team tbf, but in smaller teams I did manage I had to do project management stuff. In my normal profession I manage a large team, but one of my big roles is being there to advise technically and make the big decisions. I can see why people find these EM jobs boring, you must have to invent things to do!

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.

Once you get to leadership you're giving credit where it's due and soaking up the loss.

Sometimes, it can look like management is doing very little because you only see the tail end of their outputs to the team.

I love engineers and I love tech. I still code daily but I'm not the guy that delivers at the pace of some of the amazing engineers that I had the privilege to work with. I love putting others ahead of myself wherever I can and it's never cost me anything, so I'm not afraid to do it again. I love telling the engineers how what they do actually matters because they're too focused on the work to sometimes see why changing goals doesn't mean their work and efforts were wasted and I also love shielding them from the corporate mess upstairs (that I somewhat masochistically don't even dread being part of)...

So, yeah, I really love my job and if one of my guys (or gals) wants that too, the more of a joy it is to me to mentor them into that process.

The massive shortage of software engineer talent over many decades has created a situation where any work that a SWE doesn't like to do is carved out into its own role so that the SWE's job description stays fun and attractive.

DE, DS, BI, SDET, SRE, QA, FDE, SE and to some extent even PM are all roles that emerged from the boring stuff that SWEs don't like doing.