At my company todays staff engs do what yesterdays senior engs did. It’s a game managers play to retain good talent and give them better salaries. On one team I know of almost half the team are now Staff.
Things change when you get closer to Principal (two levels higher) but at the staff level, despite what might be on paper, they’re just senior engs that negotiate well
(I’m speaking as someone on that track, so am as guilty as the next)
Where I work almost all capable engineers are Staff Engineers. Based on the rubrics provided to make sense of our responsibilities we need to “initiate work that has org-wide impact”, “influence the company’s technological direction” and drive large scale multi-team projects.
Looking at my change lists from last year, I made a bunch of new models in our backend and wrote a few pages in React. Added monitoring, alerting and shipped the product pages. You know, your typical “software engineering” work.
What’s amazing is that I keep getting “exceeds expectations” ratings for this work because I ship things PMs want.
The hard part is self review time where I put my fantasy novel author hat on and spit out some bullshit on how my React components changed the technological direction of the company. Maybe this skill is what makes me a Staff Engineer!
> What’s amazing is that I keep getting “exceeds expectations” ratings for this work because I ship things PMs want.
This is surprisingly underrated, I know a lot of senior engineers that struggle with it. The best thing I ever did for my career when I started professional software development was realize that my manager and my customers did not care about tech stack choices, or perfect software. All they cared about was that it shipped, and in a reasonable time. They could handle some bugs as long as I fixed them.
I still have to tell some engineers with 10-15 years experience to stop navel gazing over the tech choices, and get the damn software out the door already.
> I still have to tell some engineers with 10-15 years experience to stop navel gazing over the tech choices, and get the damn software out the door already.
This may be an unpopular thing to say, but at most companies, you should have less senior engineers than that doing nearly all of the "get the damn software out the door already" work. The 10-15 years experience people should really be doing work with broader impact than that. And this isn't to downplay the importance of that just-get-things-done role at all! It's critically important. But it's a ratio thing; most companies should have a lot of earlier career folks implementing things and a few later career (or just very high achieving) folks setting technical direction, discovering and advocating for new projects, yada yada yada. I think the truth is that lots of places have this ratio out of whack with respect to the actual availability of impactful projects to work on. If there isn't enough work for folks at Staff level and above beyond just knocking out crud apps, you've got a mismatch.
We subscribe to this philosophy on paper and it works out pretty poorly. The best managers and teams are the ones that manage to subvert it.
There's a pretty wide variation in efficacy at doing the mainstream work. It's good to retain and reward the people who are good at it, so that they make up a higher proportion of the ones doing it. Otherwise you're constantly throwing away good people and replacing them with new hires of lower/unknown quality, just because you don't have enough "strategic direction" type work to promote them.
Yeah... I guess it depends on the person. I personally felt like "just get the work out the door" lost its novelty / interest for me after about five years doing it and that I spent the next five years becoming increasingly unsatisfied with my work after that. It is more satisfying for me to have more scope over larger projects. But not every place has that kind of work available. But "just crank out the bread and butter work instead" is not a solution either, because like I said, I find that unsatisfying. So if there isn't "strategic direction" type work, for some people the choice isn't between "throwing away good people" vs. keeping them doing the bread and butter work; they are going to seek greener pastures for the kind of work they prefer doing either way. There are other people who really enjoy just knocking things out no matter how long they do it, and I agree with you that many organizations would benefit more from having lots of that kind of person.
I left my past company in part because all they cared about was shipping by some ridiculous time frame.
While it certainly helped my ability to look good to PMs and other programmers, it made for un-scalable, un-readable, and un-maintainable code. My company lost tons of developers due to the constant punting of code debt. It might be easy to say push back on clients but the dev team rarely had that ability unless it was a nice client. Ugh, so glad I found a better company.
Change your team or company every 2 years. Always pick greenfield projects so you can feed your tech stack curiosity. Code usually starts to rot in 18 months mark.
Nobody cares about high quality code in a corporate environment neither should you. They're going to toss your code out of the window when some MBA from McKinsey & Co. comes and do "cost structuring" for your corporate.
Keep your craft for your open source projects if you _really_ want to do it. It's your code and it really matters to humanity if you make something good in th open.
I think there's an important distinction between ridiculous and reasonable time frames. If you're forced into releasing bad code because of an arbitrary deadline, then that is a problem. But I see plenty of the opposite, where programmers are so focused on perfecting their code that they fail to realize that software which never ships isn't software, it's just art.
It really isn't hard to ship perfectly good code relatively fast. I think most times when people have trouble getting code out the door without causing serious tech debt, it's because they've gone down the premature optimization rabbit hole and introduced a lot of unnecessary complications anticipating some future that doesn't yet exist.
> You know, your typical “software engineering” work.
“Typical” work, done well and on time with good production reliability, is often hard to get.
Perhaps it’s a sign of your seniority that you think that’s all typical. I’ve seen people release buggy code with no tests, metrics, or monitoring and think they were finished with it. That gets fixed when the more senior engineers step in and demand higher standards.
It’s sad that the baseline for quality in the software industry is so low, but that’s how it is.
In my previous job, I progressively realized that:
- I had been acting two levels above my paygrade for several years;
- everybody assumed that I was two levels above my paygrade;
- considerable turnover in managers (on average, without changing team often, I changed manager about 1.2 times per year) meant that nobody realized that there was a problem;
- attempting to actually get to the next paygrade brought a reaction of "well, if he's not at the next paygrade, there must be a reason, right?"
Clearly, the ladder was broken. That's one of the many reasons for which I eventually left that job.
I has this happen to me. My org had a set of promotion opportunities that went to a cohort of engineers who'd also been gamed into working above level but for a longer time.
All my feedback was along the lines of "you're great, but next time"
When I, and about 15 others left over the same two week period as the results of those promotions were made public it was a BIG shock to the biz. Sadly I hear they are just blaming culture at the lower levels rather than the HR team who do this.
If your HR team is deciding engineering promotions, stop looking for the problem; you found it.
HR is welcome to attend/audit the process, give statistical analysis, check for biases, advise on how to handle underperforming employees, give compensation band advice, and execute the promotion decisions the technology group decides. But if they’re the ones deciding, you need to change your company (or change companies).
We'll that's already happened for me. But the issue at core was that HR controlled the pace of promotions etc. But it didn't likewise keep control over the work that would be pushed onto people.
> on average, without changing team often, I changed manager about 1.2 times per year
I had a three year period where that kept happening. I was already doing the job of my former boss, but their boss kept switching out and the new guy didn't know who I was and I had to prove my worth all over to them. Happened three times during that time period.
After pushing for two review cycles to get a promotion and being told "not yet, maybe next time", I finally left.
I won't waste my time on that again. If my manager gets swapped out on me there's a decent chance I'll start looking to leave too, because as you say, the ladder was broken above me.
If I have to prove myself to someone all over again, I might as well switch jobs an get a raise while I'm at it.
HR is of the universally mistaken belief that a 2% raise is all anyone should get regardless of market conditions. The only way for managers to retain talent is then to promote people and dilute whatever title structure your org has.
During my brief stint as a manger, I quickly learned that the money for promotions comes out of a different "pot," and that the most highly respected managers were not timid about dipping into that pot. All of the engineers at the highest level at the time, worked for one manager.
That understanding changed how I thought about my own career development after I moved back to an IC role.
Curiously, when I look at new companies I always check for manager tenure. My experience is that new managers often don't understand these organizational quirks and have a difficult time navigating the internal politics and processes.
It can also go the other way. I found at established companies new projects often had new managers (not sure why) and also got a lot of the positive focus in the org, and had more resources as a result, which lead to better retention and raises and more headroom if there were issues like missing deadlines.
In my own case, I simply realized that I could be an OK manager, but was never going to be a great manager. And an interesting IC position came along within the same work site. I was actually promoted out of management.
Pay allocation isn't rational from the ICs point of view. For handwavy business reasons that sound stupid and no one cares about, you have things like separate budgets for "extra money spent due to promotion" vs "extra money spent due to retention raises" so if you want to retain someone and can't get sufficient money from the retention pot, you are forced to dip into the promotion pot.
From an ICs perspective, I think the takeaway is that getting promoted is almost never the wrong move and should be done as soon and as aggressively as possible, otherwise you're probably leaving money on the table.
Even in the rare event that you manage to get promoted beyond your level of competence and are now struggling to avoid being fired for performance, you just move to another company with your shiny new title and enjoy a higher total comp there than you would have gotten without promotion anyway. It's pretty hard to go wrong.
Usually you have a pool of money to split between your reports, playing with say a 2-6% raise for them. If you have an underpaid report you try to favor them, that kind of thing.
If you get someone promoted, they get bumped into a new salary band, and thus get a larger raise — and this is outside the above pool.
In a nutshell, there's one budget for annual salary increases, and another budget for pay increases that result from promotions and competitive counter-offers. These budgets may be controlled by different people.
Companies that have a lot of money, tend to manage that money by dividing it up into different "pots" that are controlled by individual managers. This is just a straightforward way of managing a business, but what's not obvious at first glance is that moving money from one pot to another is hard. If a higher power has decided that the merit increase budget is 2%/y, that could be hard for an individual manager to budge. On the other hand, if you promote someone, you get the full 2% of your new budget in the next annual cycle, so your salary budget has increased by more than 2% for that year.
Another thing is that if you bump a junior up to senior, and that person leaves, nobody will bat an eye at replacing them with another senior.
What I did as an IC was that I articulated my interests to my boss in fairly plain terms. I asked: What's the process for moving up a level? What do I need to do? What goals can we put on my performance review? A lot of people are timid about this, especially as the answer might be No. One of my friends was told by his boss: "You are topped out at your level." Ouch. What I can't tell anybody is what risk they're taking by adopting any particular approach.
I don't think I engaged in any skullduggery or politics. I am in fact enthusiastic about the business, and committed to improving my own knowledge and work. Something I've told my bosses, which is completely sincere, is that I have a lot of mental flexibility, and am happy to be guided by what they think is the best for their department and the business.
It might be that my experience as a manager gave me some cred, since it was clear that I understood the process from both sides of the table.
> One of my friends was told by his boss: "You are topped out at your level." Ouch.
It might be hard to hear but this is a very good answer from the boss. Your friend was told to start looking for a new job if they want to move up rather than waste their time grinding away at their current job. Much better than being sold false hope.
Indeed, my friend talked to his financial advisor, bought a sailboat, and went down to a 4 day week. Also, org charts get rearranged once in a while, so his new boss may have had a different idea.
not really, the basic mechanics for most companies are
1) The CEO was consulted on a particular comp plan for the new year with budgets for promotions/new hires/retention etc.
2) The CEO was almost certainly given a "generic" plan that the investors of the company + whatever data the HR team has indicates is warranted.
3) The CEO has to decide between going to bat for the employees with the investors (his boss), pushing back on HR with no data, or just accepting it.
Unsurprisingly the CEO always takes option 3 - everyone is breathing their own exhaust on what a good raise for the year is and the investors will often present a generic comp plan. You'll usually hear things like "we pay the median" or similar to justify this, but the root cause is always the same, bad data driving bad decisions.
Also note that generally these comp plans are made regardless of role. Engineering being more cyclical tends to have rapidly increasing comp on the up-cycle and struggles to match this model. On the flip side we all may be great full that HR doesn't mark comp to market.
This will vary from company to company - In some companies the CFO was selected by the board to keep finances in order as the CEO is not trusted, in others the CEO will defer this to the CFO by choice or through collaboration, and some CFO's will probably do not much more than do what the CEO tells them to.
Because of the interchangeability of titles for the same work, I find it's better to get hired as a sr. dev. Then prove that you can actually do the same work as sr. staff engs then get fast-track promoted twice with accompanying increases that are easy to justify once you have a track record at the new company. If I find that I can't contribute good ideas because of title, then I'm not at the right company and should move on.
I'm not sure I've ever seen org, no matter how well-intentioned, that titles weren't done primarily for retention. They are valuable but don't cost money.
This is so true. Companies wouldn’t offer promotions if their competitors didn’t do it too. It’s a structured way to pay people more over time as they add more value to your business rather than having them leave for the competition.
This whole recent 'staff engineer' bs is just a made-up concept to get some conference slots, write a book or two and basically talk about talking about working? I mean We've had 'staff' level engineers since forever and now someone comes along and tries to create like this aura around it and formalize what it actually 'means' to be be a staff engineer. You get to read interviews from other 'staff' engineers telling you how to properly 'staff engineer'. I mean get over yourself, you're a senior individual contributor with more responsibility. But you know, if you're not a 'staff' engineer, what are you doing with your life, right? Are you working hard enough? Do you even care about your potential? Buy my book to unlock your true 'staff' potential.
I'm a staff SWE at Google, and while there are tons of resources and community for managers of all levels, there isn't really much of a community for senior+ ICs and TLs who don't manage.
I think this is a great development in terms of building norms and community around this very common and crucial role. I've been fairly insulated from a lot of the politics, but I'm starting to realize I need to learn a few more skills in that area.
I'm also a staff SWE (not at Google) and I find it hard to believe there are no resources for senior+ ICs in a place that's supposedly engineering-driven. I've been bombarded with 'leading without authority' and 'influence'-like trainings since forever in my current workplace...
At Google these trainings are almost exclusively for managers. They used to have a quarterly class for non-managers but it was always oversubscribed.
Managers have a network: lots of manager-focused meetings, trainings, perf rating calibration sessions, etc. Even if they don't work on the same projects they'll have much more interaction than ICs and TLs have which each other. ICs and TLs who work on different projects have to seek each other out, and there's no official forum for this.
leading without authority is literally a course on Google's internal training site. You can just sign up for it. I did. It was good. Later I lead a session on it, which was also fun.
The resources are certainly there at Google, but you do have to dig them up yourself. If you're a manager you're required to do them.
You've ironically proved my point - there may be resources like this, but they require much more effort to access. Furthermore, like of a mandate means that those who aren't required to take the class may not even be aware that it exists.
If you're a manager who hasn't taken Managing Within the Law or whatever, you may get in trouble, but as an IC you don't even get the option!
I don't see how this proves your point. It's like saying there is no way to get an education because no one forced you to go to university.
You can go on grow and search for "classes on leadership" or whatever else you're looking for and it will appear. It's not like you have to guess the title ahead of time. Grow is quite literally a course catalog.
Well I'll be sure to get promoted twice in order to qualify! At that level they're probably paying you upwards of $1M/year, so they'd better support you
Staff Eng is a name that the industry has coalesced around to describe a certain kind of role, and as time gone on, the industry has become more aware of.
The basic difference is only about %10-%15 of ICs are staff or greater and are engineering leadership. A staff eng in many cases is closer to a manager without people management or a PM than a typical engineer who should be spending %50-%90 of their time writing code or similar. Staff engineers also tend to work not just within their team, but are engineering leads of projects that involve multiple teams.
Some staff engineers can spend more time than typical writing code, but %80 of most staff engineers are typically not. The %20 that are still writing a lot are still usually some kind of engineering leader in their project, subfield or similar.
I wasn't really looking for an explanation, I've been doing this for a while so.. thanks, I guess. But it seems you're quite knowledgeable. Why not put this to good use and sign up as a guest on some of the staff engineer podcasts to talk about how to talk about working and cross-team synergies? I'm also curious about various flavors of staff engineering. Like senior staff for example. Do senior staff engineers wear patches or shoulder loops?
In my company staff engineers are the highest level of non-manager engineers excluding principals. It's a position above team leads reserved for engineers whose role is basically leading in stack and architectural choices that the various team apply. A staff engineer e.g. may research and implement some new i18 library that solves major pains across the org.
Stadf engineers generally require good engineering and coding skills and large domain knowledge that engineers working on few projects do not possess.
But it's also a promotion path for seniors whose job hasnt changed much in years.
Staff is really in a different level. You don't have local/team level technical challenges anymore, but more changes that run across teams and that affect multiple teams.
You need to be both technically adept, and people adept, and have some experience in multiple+ year projects or transitions and have seen both successes and failures over time.
Companies that don't cater to them in some way, (i.e. give them freedom to operate), but leave most tech. decisions to management, end up in a bad place in the long term. Most career managers are removed from day to day coding, especially at the Director level, and often miss the small details that could derail a project.
My take: Staff is seeing a resurgence, as a lot of companies are moving away from 'Team Lead' positions, which is half IC half manager positions. They see that it might be better to have a pure manager and pure IC roles, but you want to have the deep expertise of the team lead level engineers, hence the titles of Staff and Principle, which have been elevated recently.
As in always, in some companies this is another inflated title, and in some it is actually respected and has more responsibilities. It all depends from company to company.
I had never even heard the term "staff engineer" as an apparent career milestone (assumed to be ubiquitous by the author or by others as you point out) until I picked up the book Staff Engineer: Leadership beyond the management track. It is curious to me placing so much emphasis on a title. In my first company, staff software engineer was the entry level position. It went staff engineer -> engineer -> senior engineer and then split off to principal architect or principal engineer.
We have such a "community" at my org, it is well intentioned but there's a lot of navel gazing. Linking to random engineering "leadership" blog post on slack and such.
I don't disagree with you that there is title inflation and a lot of self promotion going on, but we do need a term to describe an eng. who reports directly to the C-suite to do high accountability work with no "above my paygrade" limit (or excuse), and is not part of the main hierarchy in that he has no other eng. to answer to nor had to spend his time managing juniors. We legit need a term for this person, as it's an organizational need.
Titles are often relative to an orgs size. At a 4 person company I was a director in my twenties. At a 10,000 person company I was a staff engineer in my 30's. At a 150,000 person company I was a senior software engineer (i think? i don't think I ever knew my title, the titles of the people I worked with, or my managers title). I've had a "worse" title at each job while each job was a significant step up from the previous.
No, both are correct. Goldman, like all finance firms, have universal corporate titles that exist independent of job function. Associate, VP, MD. Those titles apply to tech, to traders, to HR, anything. There's a separate job description (ie, VP, forex trading systems design). Being named a "Senior Engineer" is a separate title. You won't be named Senior Engineer unless you've been a VP for at least 10 years.
I got an interview request from GS for a "Managing Director" position and I was really confused at first because I'm clearly in the IC track. From what I could find it seems equivalent to a Staff role.
The groups I've been in within Google are generally much healthier when there's a mix of L6-L9 SWEs complementing the eng managers / directors. It's something that I fear is being lost as the company grows and adds new layers of management, which seems to have the effect of centralizing authority away from the ICs.
I have personally become quite tired of "staff" engineers at my company. They get paid a lot but not only do they not actually code or fix bugs - they don't even make good design decisions or good calls. They are absent when needed, can't drive projects to completion and punt tough calls over to senior engineers who actually understand the system.
The only reason said senior engineers are not staffs because the staff engineers have been gatekeeping to maintain an aura of selectivity.
That sounds like a bad situation but as to your first point, code is toxic effluent so if your more senior engineers seem to be writing less code, that’s the wisdom of experience.
Less code is not less lines of code. What I mean is that they write less as a percentage of the total amount of code/configs to be written. Most of the actual work is done by non staffs.
This is usually true just as a function of what the job is, for better or worse.
I'm a senior eng on track to staff, and the fact is that code is rarely a scalable enough output. Often the problems I'm solving are hard enough that they take a while to investigate, so if they have ultimately easy solutions, it means I write a one change a week or something. And in a lot of other cases, I'm doing something "the first time" and then making sure that everyone knows how to do the and process. So I'll write code once, but it'll be used as an example by tens of other engineers.
The thing that I work on where I write the most code (a cleanup of tech debt) won't really help me get to staff unless I scale up the approach, which would require me to shard the work out among a bunch of other people. Because of the scale staff eng works at, writing code becomes less integral to the job, and often a somewhat negative signal.
While true, the onus of making tough calls should be on the person with the title.
Less code is a proxy for not really understanding the ground reality. Often staff engineers end up with hand wavy designs with no clue about how it would get executed. They get defensive/frustrated when some senior engineer points out a flaw in their plan.
To be an effective staff, the staff has to be in the trenches, lead by example. Not by writing a few docs and brushing off their hands.
> Often staff engineers end up with hand wavy designs with no clue about how it would get executed. They get defensive/frustrated when some senior engineer points out a flaw in their plan.
This sounds like you've described an Architect (circa ~2003), rather than a Staff engineer of any standard. Perhaps your company has a serious engineering leadership problem. I'm sure this problem is common at many companies but I'm not sure this can be generalized to the Staff title.
To me it’s about giving advice and sharing experience. A senior engineer or tech lead might have a problem and I give more context, and talk about similar situations I’ve seen in the past or put them in contact with another team, but they make the call since it’s their team and their responsibility. Might be seen as “punting”, or as trust and empowering.
Is there anything resembling consistency on level titles across the industry? That certainly hasn't been my experience; in my bit of AWS "staff" refers to L5 employees, ie good graduate level or lightly experienced. Below that is associate (L4), and above is senior (L6) and then principal (L7). I gather Google (and possibly others) insert a staff level between senior and principal - but for the life of me I don't understand why they would choose that label.
From what I've seen, there's indeed very little consistency in titles, if any. As you mentioned, a few places consider senior to be higher than staff, some have a distinction between senior (SWE), staff and senior staff, and some don't have staff level at all. Even among those companies that do have staff level following Google's hierarchy model (this seems the closest to a norm if there's even such a thing), the actual cross-company "value" of that title might only equate a L5. Then you get random weird outliers like Uber's L5B level, which, for all intents and purposes is a "staff" level (in terms of responsibilities and comp) except the title itself.
I suspect we're in the midst of a standardization around higher levels.
I, too, had seen "staff" as being both above and below the more-common "senior", depending on the company. In the last couple years, though, I've been hearing it more and more exclusively as being between senior and principle (and being the first step that is unambiguously on the path towards principle instead of management). The term "staff+" is one I've heard from a few sources over the last year to refer to the purely-IC roles above senior/lead.
I didn't know what to attribute this standardization to, aside from the industry as a whole evolving. The original post points to some possible causes: a book named "Staff Engineer," several conferences, and a few communities based around it.
The "Staff Engineer" book (and there's a website too) was where I first saw / heard "Staff+". I think a big part of that project is an attempt to define and disseminate well understood terminology for this. Which I think is a good goal.
I have essentially zilch preconceptions of what "staff" should mean in this context. Why would it make any more sense between "associate" and "senior" than between "senior" and "principal". What does the word even imply? I never saw it before google so I think of it as a very senior role, but the word itself remains an empty vessel for me.
Staff means you work for the company. If you go to a movie theatre and want to find the bathroom, you'd ask the staff (i.e. employees). There's no particular context to staff that doesn't also come with "employees." It's neutral, unexceptional, and it's agnostic to one's place in the hierarchy (the theatre owner and the ticket attendant are both staff).
So to me, it makes sense to place it below senior. Staff is a neutral modifier which does not imply a set level of experience (both trainee and veteran are staff). Senior is a modifier which does imply experience. Junior implies a lack of experience. So, staff would logically fit between junior and senior.
I don't see how your second paragraph follows from the first. Everyone works for the company, from the most entry level all the way up to the CEO and is thus "staff", and there is thus no indication in that sense of the word as to what its level is. So in a title it must mean something different than just "works for the company".
> Everyone works for the company, from the most entry level all the way up to the CEO and is thus "staff", and there is thus no indication in that sense of the word as to what its level is.
Absolutely. It has no bearing on seniority, and because of that I'd assume a neutral level of seniority.
>So in a title it must mean something different than just "works for the company".
I mean, that's what this whole discussion is about. In the context of the English language, this is a rather new usage of the word, and I'm trying to illuminate how its use is changing. I totally accept and appreciate that language is constantly evolving — I'm not sticking up a fuss and calling this wrong — but I'm trying to answer the question of what the word implies.
As mentioned elsewhere in this thread, this largely seems to be initiated by the "Staff Engineer" book[0], and I take at least part of his marketing is creatively "misusing" a word, or redefining a word, in order to distinguish his brand.
No I don't think it's the book / site at all, this title as "one above senior" predates the book by a very long time; I've been looking at job postings and it is pervasive and not at companies that just started using it that way within the last couple years.
The "it's a neutral word so it should be a neutral level" idea is clever but I don't think that's where this word usage comes from. I think it seems like it might have something in common with titles in media companies. What is a "staff writer"? Is that a fairly senior position? I dunno.
At my last job Staff was higher on the ladder than Principal. That's not super common, especially among startups that model after FAANG ladders, but it seems like it's somewhat more common among older companies (that is, I've seen it enough that I don't think it's a wild outlier when it happens).
in my bit of Non-AWS Amazon, L5 is definitely a career position so “lightly experienced” is not necessarily the case. I worked with L5s with 10+ YOE who actually were a critical to the success of a project.
It depends how you want to grow, and where you want to spend most of your time. (Scope of influence).
IMO years of experience is not the right way to determine who belongs at a level. I've seen an effective L5 with 2 "years of experience" (AKA 2 years out of school) and with 10 years of experience.
People develop at different paces and focus on their career to varying degrees. This discrepancy can be possible for a variety of reasons:
- Different amounts of focus on career development
- More success/effectiveness in focusing on career development
- Luck of being in the right or wrong place at the right time
- Development of other skills that are unrelated to what makes someone a successful L5
I realize after I type this that this does not really address what you said - I don't mean to nitpick your use of the word "experience", and as you can tell I do agree with what you're saying that L5 can be career/terminal position.
When people say staff, they typically mean google / FB staff. Or apple's ICT5. Levels.fyi is a good translator of what the equivalent term is at a company.
The short answer, in my experience, is 'no'. For a company-to-company level comparison, levels.fyi is usually what I use to try to infer title usage. But, even within a company, responsibilities for high-tier IC levels can vary dramatically between teams.
We've actually worked on some standard definitions for software engineering job levels based off of leveling rubrics we've collected from across the industry. We wrote a little bit about the scope / responsibility designations at each level here: https://www.levels.fyi/blog/swe-level-framework.html
Hi, one of the founders of Levels.fyi here (appreciate the kind words)! The question we try to answer with our leveling comparisons is “What level would I transfer into if I were to switch companies?". To answer this, we collect company leveling rubrics from employees and crowdsourced transfer mappings, and use it to match levels based on similar scope and responsibility.
There are also a lot of factors on an individual case by case basis that go into leveling including: interview performance, tenure in level, and scope of work, which is why it won't always perfectly map 1:1 for all cases and hence why some levels are wider and overlap into more levels at another company. And beyond that, leveling is a living and breathing thing within any organization and may be in flux at any given point in time. At the end of the day, the site is meant to serve as a rough guide for where you may be placed. Also note that the leveling boxes actually have no bearing on compensation.
- title change ( I (entry level) -> II -> Senior -> Principal -> ...)
- internal ladder descriptions (someone who worked at at least 2 FAANG companies can trivially figure out what maps to what, the titles & on-paper responsibilities are pretty standardized across most FAANG)
That's why ex-BigTech groups are so valuable: not the shared trauma of having seen a great project turn into a corporate frustrating slug, which is often why good people end up leaving, nor the shared experience of building certain rare, hard-to-appreciate tools, although that one is precious — but as a community of experienced professionals. Some merge into private groups, but they always start as private-by-necessity clusters and rarely pierce that veil.
It's not that bad. It's very simple actually - your title means something in the context of your company but that same title can mean something very different in another company. I don't think it's problematic.
The biggest most financially impactful mistake I’ve made in my career was telling HR at a small company that I didn’t care about titles. Been trying to break out of unsatisfying underleveled roles for years as a result.
oh no - I agree with you, yet this is very important. You see, in many USA companies, for decades now, people are asked to do work that is outside their job description, answer emails at all times of day, night and holidays, while health care benefits, stock options and other direct compensation are carefully withheld. It is the title that gets the compensation, not the person. This discussion appears "Kafka-esque" because it is inconsistent. To say that it is meaningless misses important parts of the context.
I really dislike traditional hierarchical organizations. They lean too heavily on the idea that somebody with a big title should be telling everybody else what to do. But actually, the people with the smaller titles know more about what's going on day to day and therefore have a better perspective on how to solve the problems. They just don't have the experience to transmute that perspective into the right action.
I gave up the opportunity for Staff/Principal Engineer titles because large organizations are an organizational clusterfuck hellscape and you can't see the right changes from the top. They give you one of those titles and then they take away the teams you should be working within. As a more lowly engineer in the trenches, I can see all the day to day problems and get the right people involved in the right solutions. I have to kick and scream a lot because I don't have power, but at least I know what's really going on.
As long as Staff Engineer is considered just another Master-level position (like Master Electrician or Master Plumber) it has its uses. But this trend of tech navel-gazing (your own conference, your own book, your own blogs, your own slack channels) just leads down the path to silos. Let go of the trappings and just dig into problems and help the junior people find the right solutions. The more you build up the juniors, the better everything gets (within engineering; better code can't fix stupid business decisions)
> So I took the question to the #staff-principal-engineering channel on Rands Leadership Slack, a little nervous that everyone would say “Uh, no? Competent people never feel like that. Oh, you sometimes do? …Interesting.”
I've been on the Rands Leadership Slack since the earliest days. There are some good parts, but you really have to work hard to separate the wheat from the chaff.
Most big channels are dominated by people who seem to have unlimited time to insert themselves into every single conversation. They give advice whether they're qualified to or not. There's a lot of uncomfortable tension among some of the regulars who are more interested in outcompeting other people's responses rather than having a group discussion.
Some of the community celebrities are only popular because they're active in the Slack all day long and will provide a semi-friendly response (with heavy use of emojis) to every discussion. It feels like a popularity contest, or at least that's how some people are treating it.
It's also the most rules-heavy Slack or Discord I've ever seen. Too many of the users think it's their duty to police everything in the Slack, including how other people are using it. If you start discussing something and the conversation involves an adjacent topic, be prepared for an influx of people demanding you move the conversation to another channel dedicated to that topic (of which there are thousands). Move the conversation to that channel and it will die, because few people are interested in joining hundreds of channels to micromanage every little topic.
There are occasionally gems to be found there, but it felt like grueling work every time I tried to participate or ask questions. Asking questions requires a huge amount of pre-defensiveness to fend off all of the people taking the worst possible interpretations. Contrary to the name, the audience is largely ICs, not managers, and they'll gladly explain to you that leadership and management are not the same. While true, conversations dominated by ICs tend to have a very IC-biased mindset, meaning any managerial questions you ask will be met with a "customer is always right" mindset where people think it's the manager's job to accommodate the IC employee, regardless of the issue.
I still check in occasionally, but it basically feels like LinkedIn in chat form unless you can stick to a few hidden channels with good signal to noise ratios.
I'm still looking for some sort of Staff Engineer type of community, but I'm afraid it will be impossible to handle publicly with open invitations. Too much attention from the people who have free time, not enough attention from the people busy doing the work.
That seems overly harsh. Yes, there are a few people like the ones you describe. But there's also a lot of valuable discussion going on, especially in the channels around management (perhaps not so much in the channels related to the IC track).
I think it's impressive rands has a management writing career without anyone cancelling him for writing Jerkcity (a strange and sexually explicit chat log webcomic).
Although, is his advice good? The main one I remember is "free electrons" which isn't even really advice, but an attempt to make the reader feel good by tricking them into thinking they're a 10x engineer.
Personally, I dont see Staff Engineer being above or below Senior Eng. They are a person who helps teams and individuals better themselves, acts like a coach, mentor, but also has the wisdom and experience to code, review code, architect solutions and the soft skills to manage people and politics.
I've had mixed experiences working with staff engineers. Some of them are great. Others seem to think having a "staff engineer" title means whatever they come up with is always correct; and when I point out problems, they double down and refuse to acknowledge they've made a mistake. :( So, I think the growth of these titles is a dangerous trend, unless there are effective mechanisms to keep staff engineers accountable for how they use their authority.
So what’s the line in a typical software org? I’m a senior engineer currently, and am looking to move up to Software Architect as a career path. Is it instead more reasonable to see it as Senior -> Staff -> Principal -> Architect? Do I have this wrong mentally?
I haven't seen the architect title in the normal ladder in a very long time. Usually it's reserved for specific key contributors like co-founders or key players that need to be retained above all else
Things change when you get closer to Principal (two levels higher) but at the staff level, despite what might be on paper, they’re just senior engs that negotiate well
(I’m speaking as someone on that track, so am as guilty as the next)