Staff Engineer Communities
noidea.dog
noidea.dog
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)
That understanding changed how I thought about my own career development after I moved back to an IC role.
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.
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.
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.
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.
It really depends on the company though
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.
CEOs are facilitators. Maybe this is a case of startup culture seeping in but there is always a firewall between the CEO and the rest of the c suite.
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!
“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.
Junior -> needs monitoring ~weekly
Senior -> does eng work reliably and on time, can lead a junior or maybe a few but doesn't have to
Staff -> leads Seniors (plus maybe some juniors directly)
Grandparent is mentioning that in their org there are plenty Staffs that do not lead anyone.
They are written to make a case for not prompting people. They are not guideline
No words for an insight as incisive as this.
Insightful - thank you
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.
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.
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.
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.
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.
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.
- 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.
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.
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).
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.
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 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...
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.
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.
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!
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.
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.
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.
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.
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 only reason said senior engineers are not staffs because the staff engineers have been gatekeeping to maintain an aura of selectivity.
No wonder people end up quitting so often.
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.
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.
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.
It depends how you want to grow, and where you want to spend most of your time. (Scope of influence).
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.
(P.S. I know the creator of levels.fyi is here on HN, thanks for creating levels.fyi and for everything you do!)
- salary bands (+ stock awards & bonus. i.e "TC" bands)
- average seniority
- 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)
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.
Hope this helps!
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.
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.
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.
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.
It’s a shame, really.
Author and commenters can't even agree or understand what their job even is about.
There'sso much emphasis on meaningless labels today, and very few definitions if any.
And people naturally wonder.
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)
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.
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.
SE, Senior SE, Staff, Sr Staff... OR SE, Senior SE, Principal, Sr. Principal...
I have not seen many orgs have staff and principal. Architect is not that common.