[HN Gopher] Staff Engineer Communities
___________________________________________________________________
Staff Engineer Communities
Author : mudro_zboris
Score : 87 points
Date : 2022-01-23 16:33 UTC (6 hours ago)
(HTM) web link (noidea.dog)
(TXT) w3m dump (noidea.dog)
| thrwn_frthr_awy wrote:
| 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.
| tootie wrote:
| At Goldman Sachs, being named Senior Engineer is like receiving
| a knighthood.
| chrisseaton wrote:
| Huh? I thought it was the over way around? Almost everyone at
| Goldman Sachs is a Vice President. Being just a senior must
| be extremely low down?
| bgirard wrote:
| I think you're right according to levels.fyi: https://www.l
| evels.fyi/?compare=Goldman%20Sachs,Google,Faceb...
|
| 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.
| decebalus1 wrote:
| Is it just me or...
|
| 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.
| ardit33 wrote:
| 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.
| bmitc wrote:
| 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.
| QuercusMax wrote:
| 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.
| decebalus1 wrote:
| Do you even 'staff' engineer? :))
|
| 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...
| QuercusMax wrote:
| 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.
| lokar wrote:
| There are organized programs and support at principal
| hiptobecubic wrote:
| 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.
| QuercusMax wrote:
| 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!
| etse wrote:
| By resources the parent comment seemed to emphasize lack of
| "community", and not training.
| lr4444lr wrote:
| 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.
| syspec wrote:
| 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.
| novok wrote:
| 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.
| bertil wrote:
| 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 a shame, really.
| AitchEmArsey wrote:
| 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.
| mdm12 wrote:
| 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.
| lhorie wrote:
| 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.
| sporkland wrote:
| levels.fyi has pretty accurate mappings between them.
| toephu2 wrote:
| Who determines those mappings though? The guy who created
| levels.fyi? and based on what?
|
| (P.S. I know the creator of levels.fyi is here on HN, thanks
| for creating levels.fyi and for everything you do!)
| 72f988bf wrote:
| It's pretty straightforward, especially for the first 4
| major levels:
|
| - 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)
| ragona wrote:
| AWS has very wide bands in L5 and L6. L5 is not Staff level,
| but L6 starts moving into it near the top of the band.
| Insanity wrote:
| 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).
| ford wrote:
| 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.
| codemac wrote:
| levels.fyi tries to quantify it.
| fishtoaster wrote:
| 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.
| splonk wrote:
| 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).
| novok wrote:
| 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.
| throwarayes wrote:
| 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)
| Yoric wrote:
| 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.
| lumost wrote:
| 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.
| analog31 wrote:
| 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.
| lumost wrote:
| 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.
| nine_zeros wrote:
| Can you summarize the various "pots" and what makes the
| best sense for ICs?
| ragona wrote:
| 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.
| hiptobecubic wrote:
| 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.
| analog31 wrote:
| 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.
| yehNonsense0 wrote:
| isbvhodnvemrwvn wrote:
| HR doesn't make that decision, the upper management does.
| lumost wrote:
| 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.
| karmakaze wrote:
| 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.
| tootie wrote:
| 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.
| msoad wrote:
| 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!
| elnygren wrote:
| Out of curiosity, where do these ratings come from? From the
| PMs? Or do you have EMs who just listen to the PMs in these
| things?
| msoad wrote:
| "The committee". Directors sit on it. I have lots of good
| relationships with most directors in my org.
| twblalock wrote:
| > 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.
| H8crilA wrote:
| The thing is that:
|
| 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.
| msoad wrote:
| Yeah. As I said the rubric makes it look like every staff
| engineer must make Kubernetes run in a WebWorker or
| invent git in each quarter.
|
| They are written to make a case for not prompting people.
| They are not guideline
| 0xbadcafebee wrote:
| 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)
| nine_zeros wrote:
| 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.
|
| No wonder people end up quitting so often.
| jeffbee wrote:
| 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.
| nine_zeros wrote:
| 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.
| joshuamorton wrote:
| 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.
| nine_zeros wrote:
| 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.
| tobyjsullivan wrote:
| > 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.
| jacobr wrote:
| 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.
| srj wrote:
| 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.
___________________________________________________________________
(page generated 2022-01-23 23:00 UTC)