Manager vs Staff

The main difference is that the Engineering Manager's job revolves primarily around people, and the Staff Engineer's job revolves around technology.

A manager role is a good fit if you want to grow people and are ok with having less time (or no time) to code. There are some great answers here: Staff IC to EM-1: Should I make the transition?

On deciding between the two paths: How to make decision on Staff IC vs Manager Roles?

is there a pay difference?

Generally no. However, the promotion path is generally easier as a manager compared to an IC, since you just need more people to report you to become a senior manager.

I think your interpretations of the Staff Engineer and EM roles are pretty accurate. EMs do indeed take on a subset of Staff Engineer behaviors and then tack on the massive role that is people management. They're 2 very different jobs. From my experience, there's around 20% overlap, and we talk about that in-depth here: [Masterclass] How To Work Better With Your Engineering Manager

Why do people choose to be staff over manager, expect for passion to stay IC (not manage people)?

Many reasons:

• They want to stay technical and write code
• It's safer in bad markets like this one (if you can write great code, you can always add value to a tech company)
• They don't want to do people management for whatever reason (they hate it, they aren't good at it, often both, etc)

Also, is there a pay difference?

In almost all good tech companies nowadays, there isn't a pay difference between Staff Engineer and EM. This is because becoming an EM is not a promotion but rather a lateral move.

In bad companies however, the IC track often ends at senior and you have to become a manager to keep progressing up the career ladder and making more $$$. In these companies (of which there are still many as this is traditional thinking), there is a huge pay difference.

To highlight the #1 reason you might not want to be a manager: you are essentially starting over from 0, learning from being a junior in many areas:

You have to learn how to resolve conflict on your team, with other teams, and influence and motivate people who each are motivated by different things. Additionally questions like what should we prioritize now, how should we do things both physically and mentally are up to you. Expect they also are not up to you 100%, so there is a fun game where directors and executives are changing their mind on what to do above you, and you need to be a giant shock absorber to provide a reasonably constant experience for the team. At first all of these ideals will go terribly backwards and you’ll have to repair the damage and figure out how to improve asap.

If you have been building a lot of people and relationship skills you may be doing a lot of this already. But it is different to lead with out authority when you aren't accountable vs you are. When you are a manager/director etc your title is a shield not a sword: you still shouldn't shout orders at people, but rather inspire the team to move in a unified direction, and then when things go wrong jump in to take responsibility for the issue and correct it at a system level.

And the point is no one really is there to make sure you succeed at your completely new role. As a junior engineer you have a mentor to endlessly answer your questions and hopefully a supportive manager, and your whole team will be full of folks ready to help. Here ideally yes you can find mentors as well, but your manager 100% will not have time to talk through everything you need to learn on the people/relationship/influence side: in my experience you have to figure it out without lots of direct support by learning on the fly, failing, and going again.

You’ve already gotten a lot of great input. I will share my experience going from a mid-level engineer to “level 0” people manger, to “level 1” people manager, then back to IC at staff level.

These aren’t very similar roles. At Amazon, there is not a Staff level. L6 is senior engineer, L7 is principal. L6 was when many engineers didn’t see a path to L7 as an engineer, or wanted a change of pace, and moved to people manager (SDM there). Amazon doesn’t have a hybrid IC/manager role, but Meta and Google (and likely others) do. They call this Team Lead Manager (TLM), and generally give someone fewer reports than a dedicated EM. This is often a “test the waters” role. I guess some people might stay there for a long time but every TLM I’ve known has moved to a dedicated “org leader”, meaning engineering manager, or have moved back to full-time IC work.

I will describe my conception of the difference: As an engineering manager, you try to remove administrative, and occasionally technical, blockers from your team so they can do their best work. You support their growth, but this isn’t always technical coaching. Often this is OK, because growing above mid-level is often more focused on soft skills, which a manager better have a good handle on. An EM spends a ton of time in meetings that have no one else on their team in them. Managing up to high levels in the org, justifying team focus, need for HC, selling a roadmap, etc. Managing laterally to bargain with other teams for who does what work, when it will be done, etc. Sometimes EMs will review a design, but rarely as a sole reviewer. A manager does a lot of work, but it doesn’t look like engineering work. They point people in the right direction, then try to get themselves and everyone else out of the way. I say they “lead from the back”, because they are not doing the same work as the people they support.

As a staff+ IC, assuming no people management, the way you support the engineers you’re responsible for is very different. There’s more direct input to code and design, there’s more work on actual technical process and tooling because they should know what parts of the process are painful, often participating in the dev process themselves. They design larger systems, or support others who do so, even if they won’t be involved directly in implementation. When they are managing up, it is often working to get people in the right place to get something done, or providing perspective on the technical state of systems and where investment is needed. If they are running a project as a lead, they may be talking about dates and progress, but that’s often not the main focus. For managing across teams, it is normally being a facilitator. Instead of debating who does what, they help teams understand the best technical approach and let that guide the decisions. They often hear more real feedback from other engineers that a manager may not, and ideally can champion fixes for these things.

In terms of “why”: for me, I was burned out on my leadership making awful decisions, and protecting my team from them. I was over getting HR directors involved in poor practices in rating employees, etc. I was spending all of my time trying to salve self-inflicted wounds, not helping my team achieve bigger things. I wanted to be reviewing designs and code as a primary part of my job, not an ancillary, unappreciated part.

I say all this, and will probably manage people again at some point. The time is not now.