Hacker News Reader

Comment by nemetroid | Hacker News Reader

If I understand correctly, "staff-plus engineer" means "staff engineer or above".

Ok, what's "staff engineer"? Reading the title, I thought it would be about managing staff in addition to engineers. That's clearly not the case.

On https://staffeng.com/, there is a further clue.

"The transition into Staff Engineer, and its further evolutions like Principal Engineer, remains particularly challenging and undocumented."

It would appear that "staff engineer" is a hierarchy level below principal engineer.

I've been a software developer for damn near 20 years, and I don't know what any of this is. Is there a flow chart with positions labeled that explains all the "engineer" modifiers?

Realistically, Staff Engineer is a higher level engineering title given out to Individual Contributors (non-managers) to give them career paths outside of management. This is designed to solve the issue where very senior engineers run out of growth room and are effectively forced into management against their will and with occasional disastrous results. There are often a few titles around “Staff” too, such as principal or architect.

Think of them like an architect who codes a bit more.

Staff Engineer is the level above Senior Engineer - a pretty common title at FAANG-like companies.

Here is a good chart: https://staffeng.com/levels.png

Ah so the technical track equivalent of the first real manger grade then.

YMMV, at my company senior SWE is parallel to the first manager grade.

When I started at Google I asked what Staff Engineer means in an orientation meeting and people just laughed at me for not knowing. It's weird how people just assume you know some things that are specific to a few Silicon Valley companies.

That’s weird. When I asked they showed me the job ladder definitions that explain the expectations of a Staff SWE.

The exact job title sequence varies a bit, but a useful division I have seen is: first you're told what to do. Then, as a senior engineer, you're told what problem to solve and what you do is up to you. Then, as a principal/staff/etc. you're expected to decide which problems to solve.

Usually there's a pecking order loosely based on the historical Bell Labs hierarchy.

"Staff" is usually a notch below a principal. Usually a principal is expected to demonstrate technical leadership and comp. In some companies I've observed there may be a narrower funnel to principal and another notch where you get more stock or compensation.

I guess depends on the company? Google staff is a good principal at msft

Edit: in Google principal is above staff too, it's just that msft partner is Google principal, and msft principal is Google staff. lol

It's above senior but before principal. It's not rocket science!

(Maybe if you work for SpaceX ....)

That verbiage means that principle engineer is staff engineer by another name.

It's different depending on the company.

https://www.levels.fyi/ has a breakdown for some of the largest companies but I typically think of it as:

Eng -> Senior -> Staff -> Principal -> Distinguished

with my simple explanation being:

Eng - Able to contribute to the team

Senior - Expert on the team

Staff - Expert in your organization

Principal - Expert in your domain

Distinguished - ?? - Seems to be that you damn near created your domain. I only see these at the largest companies and a lot of times it's folks that have created popular programming languages or frameworks that the company themselves use.

Senior: we need to give them a promotion, but with no new responsibilities.

At many companies that's how you could define all the roles!

It more like "I need a promotion to make sure my compensation keeps up but with no new responsibilities!"

Distinguished means expert in the field. The distinguished engineer I knew who worked at Cisco contributed to the TCP/IP protocol and also basically built their first router.

Wait, Cisco stole it's first router, with the founders being forced to resign from Stanford as part of how the criminal charges got dropped.

Or are you talking about the Stanford Blue Box?

I am referring to Bill :)

On a side note, maybe the reason why every major company here has accusations of stealing ideas is that it's much easier to accuse someone than it is to actually take a real risk and build a successful product and business around it... I struggle to think of someone good who doesn't also have an unwarranted accusation against them (Carmack being the most recent example).

Outlawing non-competes made this Valley, and people here largely value freedom of innovation and execution over rent seeking of someone else's mind and ideas. Culturally speaking, this is the West Coast hacker ethos to a tee. Bringing suits, regulations, and lawyers to the party will only lead to our demise.

Accusations?

They openly stole Bill Yaeger's work, and never denied it. Bill wasn't an early employee of Cisco.

We're not talking about non-competes here, we're talking about taking source code and board designs verbatim and just swapping out the copyright assignments and adding "Cisco". All of this pontificating about trying tear people down who dared to take a risk is really gross in that context.

Yikes. Where can I read more about this? I wasn't able to dig anything up myself readily through online searching. If this is indeed the case, then you are absolutely right, and I would even fully redact what I said.

Edit: Yes, you're right, what a sad story :( and of course it is largely covered up to the point where people can easily be mistaken about it.

Staff engineer means “you are now or have at some point in the past been an indispensable senior engineer at a fashionable tech company (this company inclusive)”.

Principal engineer means “you’ve made a lot of money, so you don't need to work for money any more, but we’d like to have you around so that our staff engineers have someone to look up to”.

This is obviously an incomplete/slightly tongue in cheek definition. The people playing these roles, of course, have a lot of “real” work to do. But there are a lot of senior people who are highly productive without these titles (like yourself, it seems).

Therefore, there’s a bit of an insecurity people carrying these titles are prone to, since it distinguishes them (and usually their salaries, to a highly significant degree) from their colleagues with equivalent years of experience and technical talent. Hence the websites you describe, where people try to make sense of the divergent path they find themselves in.

The titles themselves have been copied from Google, I believe. You can view them at https://levels.fyi

And then after those comes "Distinguished engineer/Engineering Fellow", which basically means: "You are famous enough that we pay you mostly to get a shiny halo effect from employing you. If you also solve some actual problems, yes please." People like Guido van Rossum and Simon Peyton Jones would fall into this bracket.

>Principal engineer means “you’ve made a lot of money, so you don't need to work for money any more, but we’d like to have you around so that our staff engineers have someone to look up to”.

Having been a "Principal Engineer" at a large tech company, that wasn't my full experience. Yes, the pay was great, but the role was more about driving large, multi-team and discipline projects. Client, server, security, etc. all at once.

Coasting was absolutely possible, since none of my managers (of the three I had there) had similar levels of engineering experience nor did they seem particularly interested in anything except whether things were on schedule or not. In that time, I did have face time with multiple folks at C-level and EVP level. Those folks actually did get it and understand the value of the work, it was the middle management that had the gap.

I'm sorry that I came off as belittling these roles. They are valuable, and I didn't mean to imply that coasting was a norm. The principals and staff engineers I've known have been brilliant technical minds.

I was attempting to describe how somebody with 20 years of quality IC experience (OP) could have steered inadvertently away from the Staff+ path. I admit that I didn't do Principal justice, I was merely trying to distinguish it from Staff (since they're fairly similar job descriptions).

To redo that attempt: Staff+ opportunities go to people with leverage ("indispensable senior engineer", "made enough money to retire early") and interest (choosing to continue working, choosing to take on the title), who are working in the subsection of the industry that chooses to cede leverage to engineers.

There aren't a lot of them to go around, compared to the number of qualified engineers, so a lot of the initial qualifications are circumstantial. I don't think the fact that they're circumstantial (everything is circumstantial, after all) takes away from their ability to drive big positive change in an org, and the pride one should take in that. Somebody has to do it!

Hah, I didn't take offense. I've seen and worked with quite a few Principals where I questioned what they actually did. Lots of them produced many documents and zero results and coasted based on that.

It depends who you ask.

The commonly held belief is that it is the advancement of the tech track ladder. So that you can have more responsibility but without becoming a [people] manager. So in this pretend world, staff plus engineers can dictate technical and architectural direction, and perhaps corral resources, of the company without being a manager. You are expected to make decisions that can affect everyone "under" you. For example, you might dictate (either by coercion or persuasion, depends on the company as much as your own style) migration to React or some other crap, from whatever current crap you are using. Or decide code style, and write or cause to be written, enforcement tools for such.

But more cynically, and as I believe, it's a way to pay long time employees, that hold critical tribal knowledge, more money. The title has become pretty disconnected from authority/responsibility, even at Google.

If you search for [principal engineer], you'll find some different thoughts on staff plus leveling.

It's quite common terminology, so I'm pretty surprised after 20 years you'd have no idea. You must be in a pretty insulated bubble.

> You must be in a pretty insulated bubble.

Maybe. It feels more like I'm outside the bubble though. I've never worked for a SV-type company or big tech. Through my career, I've worked at small companies or those that aren't primarily tech. None of those had any of these titles. And I really think that represents the majority of companies outside "the bubble".

> For example, you might dictate ... migration to React or some other crap, from whatever current crap you are using. Or decide code style, and write or cause to be written, enforcement tools for such.

Or, y'know, make design decisions about the actual system your team is building? And collaborate with other teams on integration between systems. Those are the main ones.

> But more cynically

More? haha

> make design decisions about the actual system your team is building?

that would simply fall into the realm of senior.

> And collaborate with other teams on integration between systems.

That might be senior as well. Depends on how much work you need to impose on the other team, I suppose, and/or the scale of the integration.

Reply on news.ycombinator.com