"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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Well, even if the author does provide a definition elsewhere, I think the problem is in part that advice is only applicable for organizations that agree with that definition.
I think the actual implications of a "staff" or "principal" job title vary meaningfully between organizations, and worse can shift when there's a shakeup of senior leadership.
Staff actually may be a different level depending on company you’re looking at. There may not be one standard definition (though there may be generally agreed upon responsibility). See IBM for example, Staff is the second level: https://www.levels.fyi/?compare=IBM,Google,Facebook&track=So...
My guess: Someone who is not into management (or not good at it) may be powerful when they work on a problem but naturally narrowly focused — management can help them prioritize, see the bigger picture, and shift their focus when needed. Autonomy and independent critical thought are important, and so is relevance to business priorities.
My interpretation of "growth" in that context is "incremental progress towards the next promotion or performance rating bucket". And it doesn't say that it doesn't happen without feedback, it effectively says that regular feedback helps it happen faster.
They probably don't mean "incremental progress towards a better job elsewhere", and yet that's the real fast track (though somewhat less so at the >=Staff level).
"Growth" in this context means impact to and relevance within the organization. It's mostly a leadership thing.
Essentially, you don't need to micromanage the work that Staff+ Engineers do, but it's critical to stream information to them throughout the week and sync with them once a week to align and calibrate.
If you do this consistently week over week, that engineer will flourish within the organization. If not, they'll continue to work within their domain until they see no more growth opportunities and then they'll leave.
Source: I've been a Principal Engineer for about four years and didn't really grow under some managers who left me alone. Once I found a manager that consistently invested in me I really thrived, and now I'm a Senior Principal Engineer and feel more comfortable in my current role than earlier.
Sorry, but what is a senior principle engineer? My understanding is that as far as engineers go principle is the top level - a true technical authority for an organization.
It just means that the managers in the company like you. In functional companies, that makes you a better engineer or EM. In dysfunctional companies, probably not, unfortunately.
> Your product manager appreciate your work. Your engineering manager is engaging the team. Your peers enjoy working together. Your users love your product. Your business loves the adoption.
What company did he have in mind when writing this? And where can I apply for a job?
They are HR designations to shift salary ranges for senior engineers.
Tech skills top out at senior level, but companies want to be able to pay some senior engineers more than average. Without affecting the senior level range.
It’s also form of title inflation and way to seem like advancing in career ladder.
Some companies have to have a growth track, so it’s a way to give senior level people some form of goal to attain. It’s mostly HR process than any engineering principle.
Do you not think there's any difference between a senior who might be working well at a high level but just within one company, and a senior who might be doing work at the very top of their entire field worldwide?
Sure, there are different calibers of senior engineers, some are better than others. Some are better leaders, some are better writers, some are better instructors, etc.
But, principal, staff, lead, and senior are all pretty much the same tech skill level. Promotions to higher levels are mostly based on subjective attributes, like leadership qualities, personable qualities, innovation qualities, etc.
It’s mostly HR process to keep more rungs in individual contributor career track. Way to retain high performance engineers in the career ladder, and show that there are more opportunities for advancement.
> But, principal, staff, lead, and senior are all pretty much the same tech skill level.
I don't really understand that... you think someone at the level of a distinguished engineer, maybe something like a Turing Award winner or someone who has invented fundamental concepts in the field, is 'pretty much the same tech skill level' as someone just promoted from mid-level developer doing routine development work?
I also don't see why it's 'title inflation' to recognise the difference between those two?
58 comments
[ 2.6 ms ] story [ 121 ms ] threadOn 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?
(Maybe if you work for SpaceX ....)
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.
Or are you talking about the Stanford Blue Box?
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.
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.
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.
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
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 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!
Here is a good chart: https://staffeng.com/levels.png
"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.
Edit: in Google principal is above staff too, it's just that msft partner is Google principal, and msft principal is Google staff. lol
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.
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".
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
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.
Think of them like an architect who codes a bit more.
Obviously I'm not in the bubble that uses those titles but an author who has an entire domain called staffeng.com should have a good definition.
It's basically the track with the same job-level as management but different responsibilities.
Also this post may be helpful: https://www.levels.fyi/blog/what-are-career-levels-ladders.h...
For some rough scope and responsibility at each standard level, click on the cells here to get an idea: https://levels.fyi/standard/
For example:
"If you aren’t giving them weekly feedback, you’re delaying their growth."
What? Like I'm not capable of improvement whitout my managers approval? What is even "growth" in this context?
Essentially, you don't need to micromanage the work that Staff+ Engineers do, but it's critical to stream information to them throughout the week and sync with them once a week to align and calibrate.
If you do this consistently week over week, that engineer will flourish within the organization. If not, they'll continue to work within their domain until they see no more growth opportunities and then they'll leave.
Source: I've been a Principal Engineer for about four years and didn't really grow under some managers who left me alone. Once I found a manager that consistently invested in me I really thrived, and now I'm a Senior Principal Engineer and feel more comfortable in my current role than earlier.
At my company Senior Principal is like a Senior Director, and the IC track continues past that. Here's the list for IC / Management tracks:
Software Engineer
Senior Software Engineer / Engineering Manager
Staff Engineer / Senior Manager
Principal Engineer / Director
Senior Principal Engineer / Senior Director
Engineering Fellow / Vice President
We all improve faster with effective feedback loops.
What company did he have in mind when writing this? And where can I apply for a job?
Tech skills top out at senior level, but companies want to be able to pay some senior engineers more than average. Without affecting the senior level range.
It’s also form of title inflation and way to seem like advancing in career ladder.
Some companies have to have a growth track, so it’s a way to give senior level people some form of goal to attain. It’s mostly HR process than any engineering principle.
It's not the only way to do things, but it's quite possible to have role and skills for a staff engineer be a strict superset of senior engineer.
You are right. But if the pay keeps going up (and responsibilities too), there are many people who are honestly happy with that deal.
Do you not think there's any difference between a senior who might be working well at a high level but just within one company, and a senior who might be doing work at the very top of their entire field worldwide?
But, principal, staff, lead, and senior are all pretty much the same tech skill level. Promotions to higher levels are mostly based on subjective attributes, like leadership qualities, personable qualities, innovation qualities, etc.
It’s mostly HR process to keep more rungs in individual contributor career track. Way to retain high performance engineers in the career ladder, and show that there are more opportunities for advancement.
I don't really understand that... you think someone at the level of a distinguished engineer, maybe something like a Turing Award winner or someone who has invented fundamental concepts in the field, is 'pretty much the same tech skill level' as someone just promoted from mid-level developer doing routine development work?
I also don't see why it's 'title inflation' to recognise the difference between those two?