Hacker News Reader

> and the staff engineer track. It sounds like you simply want to do the latter - so no, there is nothing wrong or unusual with what you are wanting.

I could be wrong but it sounds like the OP doesn't even want to be a staff engineer (if my understanding of staff engineer is correct).

https://davidxiang.com/2021/01/19/staff-software-engineer-re...

I'm pretty sure you're still expected to guide other engineers (co-workers/teammates), speak almost as a buffer with management, etc.

If you want to be heads down coding and not dealing with people, I don't think staff engineer is the right track?

Staff engineers are not a monolith. Software engineering is a huge discipline. There are staff engineers out there that do more architect/solver types of work.

https://staffeng.com/guides/staff-archetypes

In any case, leadership skills tend to go with the territory.

> Staff engineers are not a monolith.

In my experience, all it takes is your organization to go through one "re-structure", you randomly get a new manager one day, and they have a different expectation on what staff engineer means/should do.

Next thing you know, you're being expected to stop architecting so much, spend more time mentoring interns who have never coded before and got hired randomly because ______.

I wouldn't roll the dice that your job description/definition/expectations stay the same team to team, manager to manager, org to org, etc.

I'd avoid "dancing" for the extra raise or whatever comes with being a staff engineer versus a regular senior engineer if you don't like dealing with people/having a lot expected out of you from a communication, presentation, human interaction standpoint.

I recently went through a "re-structure", and the result was a massive layoff, including Staff-level engineers. So I don't find that as a particularly compelling argument, your job description is never safe anyways.

That's not my experience. Granted, I've only relatively recently reached staff level, but I've been working with other staff engineers (and higher) for a rather long time, including through some re-structuring. Their role seems to have stayed similar, and they still "architect".

But more generally, I think what you describe can always happen, whether you have the "staff" label attached or not. Especially when you get a new manager or management chain, they can always have a different idea of what you should be doing. If anything, I feel that as a staff level engineer I'd have more pull in resisting those changes (if unwanted) than otherwise.

Yeah I don't know when Staff SE became pitched as this lofty leadership position like this, but first half of my career in multiple companies this was basically just next step up in IC positions after Senior SE, not leadership. Principal then after that.

When does IC (individual contributor) go from "how efficient/effective can you make the other ICs on the team?"

I've seen ICs who say "my purpose isn't to code, it's to increase the efficiency of the other ICs on the team who do code, which makes me a 10x engineer, despite not coding, because I increase each team member's individual productivity which is collectively more than I could output individually myself"

Companies I've been in would call that out as technical leadership track, typically architect and above, but sometimes principal.

It really varies from role to role -- staff engineers/principals/whatever nomenclature used can be just another manager/director or a pure dev with light mentorship/heavy resource for helping with hard dev problems and designs and anywhere in-between.

Also regarding nomenclature of the titles -- its all over the place in the wild some places call jr's "staff software engineer" sometimes its seniors or principals.

I think you're understating your point. Most of what the OP mentions are generally expected of senior engineers or even mid-level engineers, though circumstances may vary.

> I don't like having to check on others to ensure they're working as they should.

This is impossible to avoid in most professional settings outside of entry-level.

> I don't like hiring people and doing interviews.

Interviewing is often a core expectation for engineers.

> I don't like having to worry about "capacity" when getting a new project.

Senior engineers almost certainly have to worry about whether there's capacity to take on a new project.

> I don't like doing performance reviews and making sure that people's "efficiency" is as high as.

This can mostly be avoided for ICs, until you get to a fairly high level (i.e. staff).

> I don't like having to supervise every proposal going out to make sure our marketing department didn't promise some technical heresy.

Standard senior engineering expectation.

> I don't like giving people "shitty" tasks to do (because there will always be some).

Prioritizing and assigning tasks are generally expected of senior or even mid-level engineers.

> I don't like sitting with someone for a couple hours to explains how I'd like things done

Standard senior engineering expectation.

> or having to fix something they've done wrong.

Standard expectations for most engineers.

> And of course I don't like being in endless meetings.

Meetings are also unavoidable as you become more senior, even as an IC.

Where did you learn about this "staff engineer" track?

I have worked at two Fortune 500 tech firms. They had separate career tracks where one was people management focused and the other nominally technical. At both firms the technical track was more like "technical management". None of the folks with high-level technical titles were committing code or doing hands on-technical work. The only difference with line management titles was less personnel responsibility. That is, on the technical track you would not generally need to deal with things like disgruntled employees, giving performance reports, sick time, etc.

IOW, the technical track was a lot like being a tenured professor at a major university. You have intimate knowledge of the research happening and you help may design the experiments. But you are not the one who sits down and runs the experiments.

I do not think the OP would be happy on a technical track in a major company, at least not as I have seen those tracks work. Rather, they would need to work with their line and project management such that they level out at a title where project leadership and decision making is not expected. Maybe that is what you mean by "staff engineer track." You get a Staff Engineer title (or Engineer 3, or Prinicpal or Senior - titles vary so much) and never get another promotion while still collecting merit increases and bonuses.

> Where did you learn about this "staff engineer" track?

The consensus around what a staff engineer is is mostly captured here: https://staffeng.com/guides/

There's minor disagreements, but it's a good start. Ignore the book unless you feel compelled. It's a nice site to use to make sure we're all using the same terminology.

Worked at a consulting firm with just under 1k employees, when I started they only had like 40.

At one point they had a meeting about creating a "technical track". I was in this meeting because I was interested in it. We went around for a while but they basically came back a couple weeks later saying that they don't have the resources to commit to having this track, and admitted they don't really know how it would be sustainable with our business model at the time, nor did they have anybody on the team who had experience with maintaining that kind of track and so it was killed.

We did have the "stronger engineers" who occasionally may still get paid/compensated at a manager level even if they stayed at a slightly lower level not requiring management, but that was about it.

They were also our "big hitters" when it came to putting them on the highest priority projects, and while by nature of consulting most of us were skilled in many different stacks, these people had a specialty that if a project came by that needed that skillset and was high visibility or priority, they were first pick to be on it.

But you had to start managing if you wanted to continue to move up there. I actually ended up leaving because of this, even though they were honestly a great company.

There are a ton of small/midsize startups that also split the tracks these days, at least in the USA