[HN Gopher] Staff Engineer Archetypes (2020)
___________________________________________________________________
Staff Engineer Archetypes (2020)
Author : arkj
Score : 168 points
Date : 2022-10-06 19:34 UTC (3 hours ago)
(HTM) web link (lethain.com)
(TXT) w3m dump (lethain.com)
| YorkianTones wrote:
| Are staff engineers needed? The role seems like a relatively new
| invention. Senior and midlevel IC engineers do the heavy lifting,
| principals set strategy and define architecture, EMs manage
| engineers, PMs manage product. I'm not clear on what the role of
| the staff engineer is and why it's needed.
| aaronblohowiak wrote:
| >principals set strategy and define architecture,
|
| staff is sometimes used on road to principal, in some firms
| there are no principals but just staff, etc.
|
| i think _generally_ the industry is doing swe, sr swe, staff,
| sr staff, principal
|
| sometimes there is no sr staff, sometimes there is no staff and
| just principal, sr principal...
| bsenftner wrote:
| In VFX and animation production there is a "firefighter"
| position similar to the Staff Engineer: a senior level
| developer unassigned to a specific project, able to float as
| needed and provide support and solutions for other projects
| that need spot senior level support. At some studios this role
| goes to sr. and lead developers whose projects are
| canceled/halted until they can be reassigned. At others, it's
| like a mini-sabbatical for sr level technical staff that would
| otherwise leave, but the company does not want them to leave.
| posharma wrote:
| Archetypes sharkitypes whatever...who cares! Identify a need in
| your organization and step up to meet/exceed that need. Done.
| Don't need fancy titles, archetypes.
| travisgriggs wrote:
| Needs a 2020 tag
| lxe wrote:
| The Solver archetype and mindset if often overlooked and
| unrewarded in large organizations where staff level engineers are
| expected to be bogged down either with "strategic" work, or other
| high level bureaucratic shenanigans. If you're a "solver", the
| trick is to meticulously gather metrics about the impact of your
| work, and always put them front and center when you communicate
| about what you've achieved.
| voz_ wrote:
| Avoid all these other types except Solver (we call it Fixer at
| FB). Anyone who calls themselves these things is weird, and will
| be hard to rely on.
|
| Disregard levels. Disregard titles. Fix what needs to be fixed.
| Unit tests, CI, docs, there's no such thing as grunt work. Real
| leadership happens in the IDE and only code matters - everything
| else is overhead.
| Matthias247 wrote:
| Only that pure code also doesn't matter if it's either not
| needed required at all due to different business/customers
| requirements or if problems could be solved easier with a
| different and easier to maintain set of code if system
| architecture and interaction between teams would change.
| jameshart wrote:
| We're talking about organizations where there are thousands of
| people all writing code.
|
| The tricky part is making all that code add up to something
| meaningful, though, right?
|
| A thousand developers diligently and efficiently working away
| in their IDEs building completely the wrong thing is a terrible
| waste, and not something that can be solved by just having a
| staff+ 'fixer' come along behind and clean up.
| quickthrower2 wrote:
| Only code matters is a weird take. Even excluding sales,
| marketing, strategy and other functions, just within
| Engineering, having people who unblock other people, deal with
| cross cutting concerns, make sure the new starter in them team
| doesn't leave because everyone else was too busy to help them,
| etc. are critical.
|
| Your IDE thing probably only applies to a 3 person startup
| where one or two of them are coding.
|
| I agree with you: fix what needs to be fixed. But that can be
| human things too, not just code.
| mmmpop wrote:
| Is it technically ironic how often that the "antisocial
| coder" who revels in their maladjustment wants to then give
| their opinions about how organizations of people ought to
| structure themselves??
| gorgoiler wrote:
| _Code Wins Arguments_
| Supermancho wrote:
| > Code Wins Arguments
|
| Unless the arguments are about "how to do the code
| _correctly_ " for some value of correct that's imagined to be
| beneficial in the future.
| yamtaddle wrote:
| Shit these days I consider writing code the failure-state
| that happens when I'm too dumb or inexperienced to figure
| out how to avoid writing code.
| chrisseaton wrote:
| > Anyone who calls themselves these things is weird, and will
| be hard to rely on.
|
| Providing technical leadership is weird and makes people hard
| to rely on?
| Thaxll wrote:
| Unit tests, CI, docs this overhead, I want move fast and break
| things.
| vanjajaja1 wrote:
| I agree that code is what matters, but whats your take on
| writing code vs influencing people who write code? Seems to be
| a trade off, but it seems to me that eventually you can't write
| code as fast as you can influence other people who write
| code...
| dasil003 wrote:
| Or worse, other programmers are destroying the value of your
| code faster than you can create it because the underlying
| vision and principles beyond your chosen abstractions is not
| clearly communicated.
| dogleash wrote:
| >Real leadership happens in the IDE
|
| lolwut?
|
| Do people actually believe these kinds of things? Like what
| comprehensive leadership happens solely in an IDE?
|
| > there's no such thing as grunt work
|
| It sounds like this messaging for people who are on a career
| track that will never not be grunt work. And even if the goal
| was to lead someone into being the best code grunt possible,
| how do you lead them to that point through only the code?
| pc86 wrote:
| > _Do people actually believe these kinds of things?_
|
| Most don't, no. But you'll definitely find a higher
| percentage of people who do at places like FB.
| [deleted]
| hideo wrote:
| I consider myself a 'Solver'/'Fixer', mainly because that's the
| title others gave me, and I mostly disagree with this.
|
| Specifically the problem with me is I don't have deep expertise
| in any area. This is fine in most cases but there are areas
| where expertise is important. And more often than not titles
| and levels are a reasonably proxy for expertise in a large
| organization. Turns out asking "who's the expert in X" really,
| really doesn't work once you disregard titles and levels.
| Disregarding titles and levels is a good way to turn
| engineering into a popularity contest so "who's the expert in
| X" becomes "who do I know best who recently said something like
| X to me"
| novok wrote:
| They exist to point out that there isn't only one way to define
| someone as staff engineer. If you don't write them out, then
| companies degrade into only allowing one type of archetype to
| get promoted, which discounts other ways of doing things,
| leading to a less efficient company. You see it at google in
| 2018: https://mtlynch.io/why-i-quit-google/ and today with the
| LPA (Launch, Promote, Abandon) cycle :
| https://nextbigwhat.com/the-lpa-cycle-at-google-launch-promo...
|
| What do people complain about at FB that they can't seem to get
| done there that seems really obvious that you should? You'll
| find similar issues. Maybe not like google, but unique to FB.
| 0x445442 wrote:
| Yeah... http://programming-motherfucker.com/
| scarface74 wrote:
| You can't disregard levels at large organizations if you care
| about your compensation. The behaviors you are referring to are
| "mid level behaviors" according to most guidelines.
|
| Coding ability only affects the leveling guideline between
| junior and mid. Everything else is about "scope", "impact",
| "managing ambiguity" and in the case of Google "writing a
| messenger app"
|
| Of course these are the official guidelines.
| mi_lk wrote:
| only code matters is a stretch but generally agree. If you can
| fix whatever shit is thrown at you, you have my ultimate
| respect
| edmundsauto wrote:
| I think the FB slogan is "code wins arguments" which is
| slightly different.
| throwaway1777 wrote:
| That's old school FB. Is it still like that?
| notacoward wrote:
| Tell me you've never functioned as a Staff Engineer without
| telling me...
|
| More seriously, please listen to what _every other_ prominent
| staff+ engineer here, in blogs, on Twitter, even within FB,
| etc. has to say about the job. There are a great many takes,
| but by far the most common thread is that the most important
| part of the role is almost never about code. Many _complain_
| about not having time /energy to code any more. The whole point
| of having this as a role/title is to give leverage to those who
| have proven they can use it for the good of the organization.
| That means maximizing the ratio of effect to code written, by
| themselves or anyone else, and there are a great many ways to
| do that. "Code is all" is the hallmark of the _very junior_
| engineer who hasn 't finished climbing that first rung yet - a
| very important rung, yes, but still only one of many. TBH it
| comes across as something between sour grapes and Tall Poppy
| Syndrome.
| icedchai wrote:
| In my last staff engineer role I spent more time writing
| "design specs" (which were rarely looked at) and doing code
| reviews than I did doing actual coding. Also way too many
| meetings. I found it pretty draining mentally.
| summerlight wrote:
| Oh no, managers in technical teams are usually doing their jobs
| not because it's fun and exciting but there's no other people
| who is willing to do those "grunt works" around people. Real
| leadership happens in the team, not code; code is just a
| (rather inaccurate) reflection of organization and business.
| It's correct that it's important to keep it close to the
| reality, but that's done by people and teams.
| virissimo wrote:
| AFAICT, the author nowhere advises anyone to call themselves by
| the archetype names, nor do I have reason to think that it was
| their intent for the reader to do so.
| skizm wrote:
| > Disregard levels. Disregard titles.
|
| Tell that to the person writing my paychecks.
| flir wrote:
| "Teacher" is one that's missing IMO.
| vngzs wrote:
| This post is a draft version of the released version at [0].
|
| [0]: https://staffeng.com/guides/staff-archetypes
| ochoseis wrote:
| I feel like the released version is a little better too. E.g.
| has the calendar graphics.
| davidthewatson wrote:
| > Right Hands often dive into a fire, edit the approach, and
| delegate execution to the most appropriate team, and then pop
| over to the next fire elsewhere in the organization.
|
| > The Solver and Right Hand bounce from fire to fire, often
| having more transactional interactions with the folks they're
| working with on any given week.
|
| It's worth noting that Ben Purgason from LinkedIn, identified
| Firefighters as stage 1 and beyond throughout his article on the
| five stages of SRE:
|
| > At this early stage, SRE is essentially fighting fires whenever
| the need arises while simultaneously trying to automate the
| process of fire suppression. With each piece of reliable
| automation written, the time saved on fire suppression is freed
| up for use on permanently fixing problems or for forward-looking
| priorities such as monitoring and alerting.
|
| https://www.usenix.org/system/files/login/articles/login_win...
|
| My observation has been that problems arise when you have roles
| that clearly default to firefighting without the larger
| organizational recognition that this is a signal that the default
| mode need to evolve or improve continuously. That is, that the
| stages beyond stage 1 (firefighting) that involve developing the
| roles, teams, tools, and ops in concert with one another are
| latent and need to scale with the organization, products,
| services, and customers.
| joshuamorton wrote:
| "Firefighting" is being used in two different contexts here. In
| the SRE document, it means literal incident response, while in
| the Staff Eng context, it means "addressing whatever the
| organizational P0 is", which may occasionally be a literal
| incident, but it may also be developing an incident response
| team, or lending a hand to a project that is behind schedule,
| or...whatever.
|
| There's always something that is highest priority, and having a
| floating person(s) who can continually identify and provide
| support for whatever that thing is isn't a sign of a
| dysfunctional organization.
| PragmaticPulp wrote:
| A lot of small and medium companies don't really know what to do
| with Staff Engineers. Not knowing what else to do, they default
| to something like the "Right Hand" archetype in this document,
| where they're reporting to someone important but lacking in any
| direct authority or accountability of their own.
|
| These positions can be very comfortable if the person isn't
| directly responsible for anything, but they can use their
| leadership-adjacent position to come in and take credit for
| successes on anything they touch. I worked at one particularly
| miserable company where the CEO's "Right Hand" engineer would be
| dispatched any time a project was running behind schedule. Lo and
| behold, the work would be delivered slightly after the deadline
| by the slightly behind schedule team, but the credit for the
| "turnaround" went to the CEO's "Right Hand".
|
| These positions can also be awful if the company puts
| unreasonable expectations on the Staff Engineer but doesn't
| actually give them the authority to execute. If you've been
| tasked with delivering a large initiative but you haven't been
| given any employees to do it with, your only option is to
| influence other teams to work on it with you. When it comes down
| to it, people are going to work on things for the person who
| determines their raises and performance reviews, not a floating
| Staff Engineer who needs people to help them.
|
| This is why "Team Lead" and maybe "Solver" are the only two of
| these archetypes that are sustainable for a company, IMO. Letting
| Staff Engineers sort of float around in the company and spread
| their knowledge sounds good in theory, but in practice you need
| to carefully assign them into the org structure like everyone
| else.
| vsareto wrote:
| These archetypes seem like they should have different job titles
| except for maybe Solver. Additionally, what differentiates a
| Staff Engineer who's a Team Lead archetype from someone that's a
| TeamLead?
|
| Overloading the Staff Engineer title with these archetypes is
| going to lead to identity confusion in the job hunting landscape.
|
| If you're searching for Staff Engineer positions by title, now
| you need to figure out if your personal archetype matches what
| they're looking for. You might be able to get it from the
| posting, but maybe not.
|
| This also confuses salary bands. You might have some really
| effective management type Staff Engineers making loads of cash
| because they're management, but someone who's just a Solver might
| be on the far lower end of pay because they aren't management.
| These examples might be reversed if the Solver is able to solve
| really hard technical problems.
| quickthrower2 wrote:
| Salary is always going to be confused world. People can often
| earn more as a graduate than a senior by moving to another
| company or country. Within an org it is hard to measure
| everyone's true contribution. People's salaries may reflect the
| job market when they joined. So someone who joined recently
| gets paid more for a more junior position than someone who has
| been at the company for years. The company needs to keep
| salaries secret to avoid people getting annoyed at this!
| Companies are now also completing for staff not only with other
| companies, but with investors! If someone is capable, they
| could go off and start their own thing too. They are also
| competing with FU money that people have built up. The desire
| to control this with titles and bands makes me laugh. Obviously
| big companies need to do this though.
| agentultra wrote:
| One that I think might be missing is _The Therapist_ :
|
| They are the glue that gets buy-in and agreement between people
| talking past each other. They demonstrate how a healthy
| organization can lead a team by setting guidelines for
| collaboration, communicating, being constructive, and removing
| barriers or silos between key stakeholders. They can resolve
| disagreements and unblock political stalemates with their
| unilateral authority and uncanny conflict resolution skills.
| PragmaticPulp wrote:
| > They are the glue that gets buy-in and agreement between
| people talking past each other. They demonstrate how a healthy
| organization can lead a team by setting guidelines for
| collaboration, communicating, being constructive, and removing
| barriers or silos between key stakeholders.
|
| That's a management function.
|
| If I took a Staff Engineer role and my job was to compensate
| for organizational dysfunction and fill voids left by
| underperforming managers, I'd be leaving that role very
| quickly. Either that or requesting a formal title change (or
| promotion) into an actual management position.
|
| Hiring a Staff Engineer when you really need better managers
| isn't a good solution, especially because a Staff Engineer
| wouldn't have the necessary org structure authority to be an
| effective manager-of-managers.
| coryfklein wrote:
| Depends on the role of management in the company. At some
| companies there is a bright line where managers are expected
| to _not_ participate directly in the technical discussion of
| how to solve problems.
|
| So say, in such an organization, two teams each with a Staff
| Engineer are taking different and conflicting approaches, and
| neither Staff has been able to pursuade the other to their
| side? Often in this scenario it's extremely valuable to have
| a technically capable third-party mediator to help bring the
| two together.
| pc86 wrote:
| > > They are the glue that gets buy-in and agreement between
| people talking past each other.
|
| > That's a management function.
|
| Not at a technical level it's not. If there are honest
| disagreements about technical direction, you need a strong
| technical voice and vision to break the logjam. That's not a
| management problem, although it certainly requires excellent
| soft skills (requisite for any good Staff+).
|
| It takes both the soft skills and the technical knowledge to
| get consensus, or at the very least, consent.
| eropple wrote:
| _> If I took a Staff Engineer role and my job was to
| compensate for organizational dysfunction and fill voids left
| by underperforming managers, I 'd be leaving that role very
| quickly. Either that or requesting a formal title change (or
| promotion) into an actual management position._
|
| Eh. You might not fit it, but I _really_ like that role. I
| don 't want to be out of technical conversations and I don't
| love reports, but I do really like facilitating a path
| forward. At the moment I'm working outside of an engineering
| function, but I do it when wearing that hat, too.
|
| _> a Staff Engineer wouldn 't have the necessary org
| structure authority to be an effective manager-of-managers_
|
| If that were the job, then yes. It is a soft-power role,
| though, not a hard-power structural role.
|
| Limited authority absolutely _can_ be a problem, but usually
| due to intransigence, at which point the hard-power elements
| of the org (who are typically limited in their available
| attention span) can be escalated to.
| maerF0x0 wrote:
| > I, on the other hand, really like that role. I don't want
| to be out of technical conversations and I don't love
| reports, but I do really like facilitating a path forward.
| At the moment I'm working outside of an engineering
| function, but I do it when wearing that hat, too.
|
| iirc this kind of role, and other glue are actually really
| great Scrum Master && Project Manager skills.
| PragmaticPulp wrote:
| > Eh. You might not fit it, but I really like that role. I
| don't want to be out of technical conversations and I don't
| love reports, but I do really like facilitating a path
| forward.
|
| I'm not suggesting that the role isn't helpful or that some
| people wouldn't like it.
|
| This is the problem:
|
| > At the moment I'm working outside of an engineering
| function,
|
| If the company needs a firefighting cross-team manager, get
| a firefighting cross-team manager and empower them
| accordingly.
|
| But hiring Staff Engineers to combat management dysfunction
| is a misunderstanding of the Staff Engineer role.
| Supermancho wrote:
| I've never seen a Therapist Staff Engineer. This seems to be
| the primary function of middle management.
| polygotdomain wrote:
| I certainly think that role is missing, but I don't think it's
| at a role of a staff engineer. In my experience, _The
| Therapist_ has the ear of a lot of senior people, and more
| importantly their trust. They understand the technical issues
| as well as the business problems, but more importantly
| understand the personalities and politics of the organization.
| These are the people who can convince people that if they give
| up a little, then they can get a lot in return. They generally
| tame strong-arm managers that are just looking for more
| headcount or more prominent projects that tend to drown out
| other projects or initiatives that are genuinely needed.
|
| Those people are an absolute necessity, and I think it's very
| tough for someone to be effective in that role if they don't
| have a solid technical understanding, but I also don't think
| that an engineer has the clout to wrangle people the way a
| _therapist_ needs to. In a small organization, maybe, but at a
| decent size, mid-sized company and larger it will need to be
| someone working on the business side, not development or IT
| operations
| hkarthik wrote:
| Agree this is a key skill and necessary archetype in large
| orgs.
|
| But I'd call this person _The Wolf_ (named after the Harvey
| Keitel 's character in Pulp Fiction.
| ChrisMarshallNY wrote:
| _> But I 'd call this person The Wolf_
|
| Does this person get to ride off into the sunset in a fancy
| sports car, with the babe from the junkyard?
| hkarthik wrote:
| I've seen the Wolf in a few companies and they are given
| some special treatment for sure. The corporate equivalent
| of the babe and the sports car.
|
| Years ago, one of them had a Macbook Pro while the rest of
| us were dealing with garbage Dell laptops that barely
| worked due to aggressive security scanners. He got his
| turned off by IT.
| tristor wrote:
| I'm pretty sure this was me when I was at that level of
| engineering seniority, but the reality was that it was a
| frustrating position to be in, because you're operating outside
| the expectations of an engineering role. I was in Eng for 13
| years, and now I'm a PM, so take that for what you will. This
| role aligns strongly with what a good technical PM does.
| kache_ wrote:
| >archetypes
|
| Staff archetypes is a meme. Here's an archetype for you: gets
| whatever needs to get done done. The idea of an archetype is
| harmful, it limits what people do and can become an excuse to not
| do hard grindy work.
|
| EDIT: On a second read, I guess you do end up doing one of those
| things for an extended period of time. But my point still stands:
| don't box yourself in
| dilyevsky wrote:
| Ok but a lot of people's thinking is memetic. I've literally
| sat in performance review meetings where this article has been
| thrown around. Ignoring what management wants you to do even if
| it's straight up cargo cultism probably wont get you very far
| beckingz wrote:
| Sounds like a right hand.
| HPsquared wrote:
| That's the rarest type, of course.
| renlo wrote:
| What about the archetype Staff Software Engineer who's good at
| creating a promo packet but not good at much else? They come into
| an org, replace some open source / well-documented well-built
| tool with an undocumented poorly working tool, then they convince
| other org members to use this new tool as they actively disable
| or undermine the existing tool. Come promo time they now have a
| line in their promo packet "built new tool, drove adoption of
| said tool to 80%". At the last company I worked it seemed like a
| good many of the staff engineers were like this, though may be
| just the symptoms of a company with braindrain.
| codemac wrote:
| Archetypes are useful in how you sell yourself. Don't forget that
| it's not what you are, just how you sell yourself.
|
| You can change between these every review cycle, job, career, all
| you want - no one in management is keeping track of your
| "archetype". They are keeping track of your impact.
|
| Lastly, you are the "person in the box" once you are senior
| enough. Take the archetypes, look at your org, and see which they
| need. Whatever is missing will be the most value to the org. How
| you see yourself accomplishing that box is the real challenge of
| executives, not this endless "what color parachute are you" self
| evaluation.
| rco8786 wrote:
| I straddle the line between Team Lead and Solver - but even just
| reading the descriptions there is a lot of overlap.
| hayst4ck wrote:
| This is jaded and angry, but I think there is another archetype
| called "the politician." They play the game extremely well,
| providing poorly thought out solutions quickly to problems they
| haven't dug into the complexity of. They lay operational traps
| everywhere in their quest to get things done fast (like directly
| embedding config data in code to avoid fixing the config format).
| Once they've picked the low hanging fruit and left too much
| complexity to maintain, they hop to another company where they
| sell themselves on all they accomplished leaving out the
| absolutely unmaintainable mess they left behind.
| maerF0x0 wrote:
| Next level politicians do a really broken implementation first
| cycle so they can deliver a solve next quarter for eye popping
| data driven results. I've personally warned people about
| terrible designs, saw them get implemented, they cost the
| company millions, but then they "improved" it next quarter to
| save the company "millions" ... They got promoted, I got called
| names like "too negative"...
|
| Great company.
| eftychis wrote:
| I am guessing most/a lot of us have seen similar situations
| (unfortunately). (Sometimes, though situations like that are
| unavoidable -- given that demos can become product overnight
| or a deadline is unattainable no matter what you shave off.
| If I had a nickel for each time I had seen any of the above
| happen...)
| ble wrote:
| I usually think of an at-work "politician" as somehow taking
| advantage of relationships or social forces.
|
| What you describe sounds more to me like the ""10X engineer""
| (with extra scare quotes for good measure).
|
| Many people have been skeptical of the idea of the 10X
| engineer. One take is that if your normal engineers are less
| than 1/10th as productive as another engineer and all of them
| are merely human beings, there might be some common
| organizational problems that your normal engineers are all
| being stymied by. Another take is that your 10X engineers can
| only achieve their high level of productivity through taking on
| more technical debt than others understand or would tolerate,
| leaving messes behind for the eventual maintainers to fix.
| eurasiantiger wrote:
| Or maybe they just type faster.
| onlyrealcuzzo wrote:
| > What you describe sounds more to me like the ""10X
| engineer""
|
| I think 10X engineer is supposed to imply the average
| engineer - maybe at the person's level?
|
| We all know there are plenty of engineers who do negative
| work, and plenty who do almost nothing.
|
| So depending on how you think of it - it might not be that
| impressive.
| bioemerl wrote:
| In the workforce - the real answer is that the 1x engineers
| really really aren't operating at full capacity. You assume
| all parties give it their all. They rarely do.
|
| Get through college
|
| Do what you have to in other to get the job.
|
| Do what you have to in order to keep the job.
|
| 10x people do some very basic things. They care. They read
| about code. They have side projects. They improve their
| skills because doing so is fun.
|
| In a company that hires "the best" and pays very well you
| shouldn't see a 1x 10x divide, assuming they hire well.
|
| In those that don't, those that only want work done and don't
| particularly care? That's where the dichotomy presents
| itself.
|
| There is nothing inherently wrong with either group. Work
| gets paid, you don't have to be a magical 10x engineer to be
| worth the salary. And there's no shame in coding as a job
| instead of as a hobby.
| CobrastanJorji wrote:
| "Hiring well" or hiring "the best" isn't a panacea. People
| change. Before I had kids, I was working hard, working late
| nights, and some of my work was all-consuming. After, I've
| definitely had periods where my main focus was on showing
| up to meetings and making sure I got at least pretty okay
| on my performance reviews, while actually focusing on,
| y'know, not work. If the company doesn't punish people for
| becoming half as productive, a lot of the folks are going
| to become half as productive, even if they were "the best"
| at some point. Especially true when morale at a company
| drops. Canceling projects, being assigned to boring
| projects (the next year will focus on Sarbanes Oxley
| compliance, guys!), having your company or work dragged
| through the news, it adds up, and people get detached.
| tzone wrote:
| If you have never seen a 10x engineer you either have never
| worked with truly talented people or you haven't worked on
| actual hard problems.
|
| There aren't just 10 or 100x engineers , there are even
| infinityX engineers when you work on actual hard problems
| because some of those can only be solved by handful of
| people.
| jedberg wrote:
| I've seen 10x engineers. They do exist. However I've never
| seen them in isolation. It's more like teams of 10x
| engineers. I've seen teams of people who just get 10x more
| work done than equivalent teams elsewhere, usually because
| they consist of a bunch of amazing engineers and are enabled
| by management to get things done.
| adra wrote:
| I'd generally agree to this. The most recent job I've
| worked at have amazing management buy-in and empowerment by
| management to just "get things done fast" that ends up
| working amazingly well because the freedom we've been given
| translates to great results.
|
| This is a little catch-22 in getting started though. A
| great team held back by management hesitation can
| demotivate and cause attrition. Management buy-in for
| ineffective teams will run faster by bypassing many org
| hurdles fall over by their own inability to execute
| solutions that pass the test of time. It seems like these
| rare "10x" teams are hard to form in companies that can't
| consistently attract and retain very talented ICs
| maxrev17 wrote:
| The 10x is a transition from knowing how to solve problems
| quickly and efficiently, to being burned out because too much
| of the solving problems quickly and efficiently. Like a
| bright burning filament bulb lol. OK I'm probably
| exaggerating but I have encountered this.
| jacobr1 wrote:
| There is also the "positive" version of the politician. They
| have enough technical credibility, social skills, relationships
| with senior management, to remove organizational log-jams.
| Other companies might hire a consultant to come and tell them
| what they already know they need to do (but can't
| organizationally agree to do) - but with this archetype, you
| can call them in and they will cut out the bullshit, somehow
| without upsetting everyone.
| jameshart wrote:
| _There are people who are bad at every job_.
|
| That doesn't mean that the people who are hiring people into
| that role _are looking to have someone do it badly_. Or that
| anyone who wants such a role is automatically suspected of
| having nefarious motives.
|
| These role archetypes are descriptions of realistic, reasonable
| expectations for high level IC roles. It's a useful, positive
| contribution that will help engineering directors and senior
| coders better negotiate clearly defined roles and
| responsibilities.
|
| It's just not _constructive_ to say 'but yeah, sometimes when
| you employ someone at this level and you don't clarify the role
| or hold them accountable, they do terrible things and it
| enables charlatans to prosper!'
|
| Sure, of course it does. But this article is a _useful and
| constructive model for helping prevent that from happening_.
|
| What you frame as an _addition_ to the article actually
| represents a cynical undermining of its entire value. I think
| that's a sad way to engage.
| bgro wrote:
| This is almost exclusively what I've encountered in most of the
| "elite" engineers. It's frustrating because they're the ones
| saying coding and job hopping is easy. They're the ones in tech
| interviews who downplay your achievements.
|
| In my experience, rather than leaving for another company
| though, they're often a C-suite favorite and get to start some
| new project (often it's whatever they want to do as long as
| it's remotely justifiable). They get it up to 80% complete so
| they can hand it off to another team to do the last 20%.
|
| Since the project is whatever they want to do, they use very
| unusual languages or design choices that the new team has to
| pick up and fix. A lot of times it's whatever the big new thing
| is. (For example, expect statements like this: "Everything is
| obsolete legacy code now that Electron exists!" "No need to
| keep this standalone offline test database, setup shell
| scripts, or maintain the environment setup guide because Docker
| will automatically solve all of these cases!")
|
| They continue getting new projects because these 1 or 2 people
| "did the project 80% complete in 1 month, and the last 20% is
| taking the handoff team of five at least 3 months to do."
|
| Bonus points when it is expanded from some sort of hackathon,
| or some fake story about how some person completed the 80%
| portion over the weekend. In the former, all the connections
| and APIs are hard-coded and faked for their demo. In the
| latter, they had actually been working on this for the past
| couple months instead of doing their assigned work which made
| their official team look even less productive.
|
| I was on the teams always picking up the last 20%, but I got
| moved onto the 80% team once. I was amazed at how much code I
| could blow through with time to spare when I didn't have to
| worry about all the edge cases and minute details.
|
| Unfortunately, I got temporarily moved onto a company-wide prod
| support team which then got cut due to covid. Hooray.
| menor wrote:
| I'm not sure if I'd name them "the politician", because I think
| they are not doing the harm consciously, but I've met several
| of them. Pair it with the "CV builder" ,that just throws new
| technologies at problems to add them to their CVs, and now your
| codebase is a minefield.
| woah wrote:
| Their crappy code might be generating millions of dollars in
| revenue while you fix it and curse their name
| sbf501 wrote:
| Since we're being anecdotal: I think that claim is jaded and
| angry, and makes me wonder what kinds of companies people have
| worked at. Honestly, I've only encountered this once or twice,
| and I've been a career engineer since 1989 at places like IBM,
| Intel, and Microsoft. Dozens of positions and groups, and I've
| never had to play politics. Maybe I've just worked at "good"
| companies (irony noted), but in my experience it was less about
| politics and more about getting shit done, and if you failed to
| get shit done, you were alerted to that very quickly. If you
| did get shit done, and got it done well, you got promoted, and
| were given even more shit to get done. Upper management at
| those big three had their game tight.
| Der_Einzige wrote:
| Intel was overran by MBA types until they got their most
| recent CEO, and it'll take years for them to undue that rot.
|
| If you worked in a software group at Intel after 2015 and
| didn't play politics, I straight up don't believe you.
| tayo42 wrote:
| im actually amazed you never ran into politics at work. you
| never needed to navigate around egos to get what you want,
| you do every thing purely on merit, every decision is only
| technical?
|
| my whole career as been filled with stuff like people forcing
| their pet projects on the company, people hiring their
| friends and dealing with their in crowd
| vsareto wrote:
| Just like there are loads of average developers, there are
| loads of average companies.
|
| You can get lucky and work at all great companies in your
| career. Most of us will not have enough jobs in our lives to
| get a representative sample.
|
| There is also a question of having different standards. Bad
| companies might just be bad for someone who has access to the
| top companies, but otherwise great for average workers.
| sbf501 wrote:
| Point taken. My comment is a good example of "tech
| privilege".
| denton-scratch wrote:
| I wasn't familiar with the term "Staff Engineer", and wikipedia
| was no help. I found this:
|
| https://careerkarma.com/blog/how-to-become-a-staff-engineer/
|
| ...which seems to be saying that a "staff" engineer is
| indistinguishable from what I'd call a senior developer.
|
| As far as I'm concerned, "staff" is people that are permanently
| and directly employed. It doesn't mean "senior". If it's found
| it's way into the cycle of job-title inflation, that makes me
| sad.
| opportune wrote:
| "Staff" has been a regular title for SV software companies for
| quite a while now.
|
| It is basically the next level past "senior". Whereas a senior
| will normally report to a line manager, staff engineers will
| often report to a middle manager and have managers as their
| peers.
|
| A normal range for a senior is 5-10 years of experience (but
| still many people will have more experience than that but not
| be "senior" depending on company), whereas staff is 10+ years.
| Obviously these are not wholly sufficient conditions but
| they're common buckets, especially for external hiring.
|
| There is some title inflation going on where staff engineers
| are typically acting more as tech/team leads as opposed to
| senior engineers. IMO it's a good title because "principal" has
| connotations of doing really big-picture stuff that may involve
| some resting on laurels. Also the bar for "principal" varies
| widely across companies - at Microsoft it's the same as "Staff"
| at other places, at some places it's like the top <1% of IC
| engineers, others are probably even more lax than MS.
| denton-scratch wrote:
| Thanks for explaining!
|
| The last time I was involved with job-title hierarchies (a
| long time ago), nobody was a programmer, everyone was an
| analyst. The people who did telephone support were called
| support analysts. I graduated to senior sales support analyst
| (roughly, doing random free work for the prospect, to close a
| sale).
|
| We assumed we were superior to "engineers": they were the
| guys that swapped-out hard disks and cards, twiddled the
| fuses to do performance upgrades, and lifted heavy boxes. We
| were better-paid. I think of them in boiler-suits, but
| actually they wore business suits like me. I liked the
| engineers.
|
| [Edit: I guess maybe the difference might have been that we
| (analysts) had degrees, and they didn't - they got lots of
| training on the hardware. The attitude "we" had was obviously
| degree snobbery. I say "we", because the engineers were
| regarded rather as I would regard a gas-fitter, by just about
| everyone.]
| pedrosorio wrote:
| > I guess maybe the difference might have been that we
| (analysts) had degrees, and they didn't
|
| Interesting nomenclature given that in many countries you
| can't even call yourself an engineer without an accredited
| degree and being licensed by the proper regulator.
| opportune wrote:
| It is kind of the opposite now, at least in the US/SV.
| Programmers are "Software Engineers" and many programming-
| adjacent roles like support are given titles like "Product
| Support Engineer"
|
| Personally I think Software Engineer is a better descriptor
| of what we do than Programmer/Analyst, though of course not
| everybody with the title is actually engineering systems.
| 0x445442 wrote:
| So from my experience that link is describing what I've known
| as a Tech or Team Lead. But the link introduces another title,
| "Principle Engineer", that I've not encountered.
| ChrisMarshallNY wrote:
| In "classical" corporations, the term "Staff" could be
| prepended to "Engineer," or "Scientist."
|
| They generally denote a management-level seniority, and they
| can be given staff, department head status, and a discretionary
| budget.
| LAC-Tech wrote:
| It's only the other month that I actually realised having these
| as distinct roles - team lead, architect - has completely fallen
| out of fashion.
| lamontcg wrote:
| I'm pretty sure I've worn both the Team Lead, Architect, and
| Solver hats at the same time.
| quickthrower2 wrote:
| At small companies you will, and you might still be just
| plainly titled "Software Engineer".
| siliconc0w wrote:
| other possible types:
|
| 0) the wizened emeritus engineers staffed with special 'futures'
| or 'next-gen' bluesky type projects
|
| 1) engineers who may not be overly technical anymore but are
| really good at negotiating the organizational hierarchy and might
| know where and how to poke and pull at the cybernetic organism to
| nudge it in a desired direction
| adam_ellsworth wrote:
| Has anyone read Tanya Reilly's new book "The Staff Engineer's
| Path"? Wondering if there's overlap in the concepts/model.
| lhorie wrote:
| A little meta commentary: I'm seeing a lot of negative takes
| using the word "they" (so presumably these are from people who
| either haven't worked in a staff eng capacity, or have, but in
| dysfunctional organizations).
|
| The intent of this article (as I understand it) was to help
| people navigate the emerging nebulous role that "staff engineer"
| was, particularly as it started to become a more mainstream
| concept a few years ago (whereas prior to it, the dichotomy was
| largely that senior was "the" terminal IC role and you had to
| transition to management past that).
|
| Many engineers on the upper side of the senior spectrum have
| clearly been operating above and beyond what is typically
| considered senior level, but not in the capacity of a typical
| manager archetype, so this was meant to help people understand
| how to identify/categorize these people as well as help people
| understand what kinds of challenges to look at after you've
| become a "full-fledged" senior engineer. Resources are useful,
| whodathunkit.
|
| My advice for those eyeing for a staff+ level would be to avoid
| making "hot take" categories, everyone can do that and if they're
| coming from a position of inexperience w/ the subject matter,
| there's a good chance it's a bad take. Instead, try to derive
| action items from each of the archetypes, and incorporate those
| into your work. A good point I heard is that no staff engineer
| qualifies as a single archetype exclusively; the role is usually
| a mix of all archetypes, with different people leaning more
| strongly one way vs another.
|
| It's very easy to make sour comments like "oh staff people just
| spend all their time in meetings, what good are they for". It's
| quite another to be that staff engineer and have to balance
| technical depth acquisition, alignment among disparate groups and
| the multiplexing required to operate at high levels at both. It's
| easy to chalk it up to politics, but it's quite another to be
| able to visualize power structures as tools, and use them as such
| to accomplish large scale engineering goals. There are classes of
| engineering challenges that only really arise at the staff+
| engineer level, and engaging with them can be rewarding in their
| own right.
| lifeisstillgood wrote:
| It's interesting to have pulled out the "Right Hand" archetype.
| Too often this distinction is ignored and _everyone_ tries to
| align to the senior executive.
|
| All the other archetypes _can_ be independent, as in the company
| can pay them to do their mission even if the executive is not
| engaged.
|
| I suspect it is time we stopped seeing companies as lead by an
| executive as the tip of a spear and more as a crowd with an
| agreed direction.
|
| Edit: I would also suggest that Staff Engineer is the next step
| on what I would call Software Literate Companies - it's not that
| we need execs who are not day to day technical supported by
| people who are. It's that we need execs who are day to day
| technical and not have ones who cannot code.
| sbf501 wrote:
| Mozilla had some interesting archetypes. I only recall two
| because I didn't work there, but they were Wizard and True
| Believer. They all seemed to be more apt archetypes than standard
| job progression ladders because they allowed for more diversity
| than just 'manager' and 'technical' paths. I applaud the attempts
| even if they do seem a tad cringy.
| efficax wrote:
| the fetishization of staff engineers is really fascinating. do
| they actually act as "force multipliers", are they really
| essential to the success of large engineering orgs? In my
| experience, they spend most of their time in meetings not doing
| much of anything at all.
| martythemaniak wrote:
| Take the top 10% of engineers in your organization. They are
| the ones where the technical buck stops, the ones with the
| deepest technical and business domain expertise, the ones that
| define and drive the hiring process, the ones that drive
| changes that impact many teams, the ones that set the cultural
| tone for the rest of the engineers.
|
| It doesn't matter what you call them, they've always been there
| and always will be. Unless your engineering org is not run by
| engineers, in which case, you should join a company that has
| staff engineers :)
| larve wrote:
| Are these terms and names all about "marketing"? Yes of course,
| people have doing the tasks described without being asked for
| it, but being able to have a salary run above "senior", as well
| as terms allowing you as a develop to play the bigger game of
| corporate environments, is tremendously helpful.
|
| As a senior engineer, or just "software engineer", you can be a
| brilliant architect, but if noone sees that outside your
| immediate team, and the only way for you to get bigger impact
| is to become a manager, with no time for actual code, then your
| impact will be minimal.
|
| Positioning yourself as staff engineer, and selling yourself as
| "architect oriented staff engineer" to the different managers
| and leads whose buy-in you need to do cross-team architecture,
| is a force decoupler for _you_ as a technical person.
|
| I'm a fundamentally technical/code monkey person, I love
| writing and shipping code. But I'm in a position right now
| where, in order to get my _technical_ goals accomplished, most
| of my work is managerial. Once I was able to frame things that
| way (I could write code all day long, and never would I be able
| to achieve X, but if I play the game of calling myself
| principal engineer and leveraging that "marketing brand", then
| I actually can), all the remnants of apprehension I had kind of
| fell away.
| mikefallen wrote:
| Second this, also stemming from this tend to fall behind
| technically speaking on the "bleeding edge"
| kccqzy wrote:
| I think only the Solver type from the article acts as a force
| multiplier. Have a strange bug that you have been trying and
| failing to solve for a few days? They will probably fix that in
| a few hours and unblock you immediately.
| ilc wrote:
| Solvers don't fix the problem. They tell you how to fix the
| problem. :)
|
| That's how they make sure the problem stays fixed.
| nosequel wrote:
| > they spend most of their time in meetings not doing much of
| anything at all
|
| This is largely dependent on the company in my experience. I've
| been a Staff at one company where I had to actively protest
| meetings. I would get in trouble for not showing up. I had to
| point out several times that 1-2 hours a day of non-meetings
| was not enough to be effective no matter what level a person is
| at.
|
| At other (typically smaller) companies, I do feel like Staff
| engineers can really have a multiplying effect. Based on the
| OP, I personally fell into "The Solver" category and would
| bounce around helping out teams who were stuck on something
| particularly troublesome.
|
| > are they really essential to the success of large engineering
| orgs
|
| I don't about know this one. In a large org, I was at my most
| ineffective. I do think they are essential to small-to-mid
| sized engineering orgs though, even if it only means they help
| out by knowing all the ways *NOT* to do something.
| scarface74 wrote:
| At smaller companies titles really don't mean anything. Often
| it's just the person who lasted the longest or what a new
| employee negotiated
| tunesmith wrote:
| Speaking only for myself, I'm the one they ask when there's a
| problem no one else on the regular team can solve, and I don't
| have someone technical "above" me to ask for help. I can only
| collaborate with people and drive the investigation and
| communicate the results. So that's sort of the Solver/SRE role.
| I don't know how to calculate "force multiple" for that
| scenario because in the absence of me solving it, the teams
| would basically limp along without a solution without fully
| understanding the negative impact.
|
| I'm also the one that sets certain best practices in code
| repositories, and I've learned that identifying a best practice
| and assigning it to someone else to introduce doesn't work very
| well. At those times I have to dive into the code, restructure
| things, and then present, so that the other coders can actually
| refer to it as an example. This in addition to helping team
| members know what is in-bounds and out-of-bounds for their
| story, and helping with code reviews. This is roughly the "tech
| lead" role. This has some sort of force-multiplier impact just
| by doing things like guiding the metaphorical ships away from
| the metaphorical icebergs.
|
| Finally, there's the classic "architecture" role, where we
| identify tech paths for the org in general. Recognizing when a
| well-targeted effort can replace an inefficiency with something
| smoother. Like I had to take it upon myself to set up
| elasticsearch and kibana correctly, and structuring the code to
| report the correct dimensions. Or structuring how our graphql
| queries worked so they didn't pound our graphql server. Or
| placing an in-memory cache on one layer of servers (this
| basically saved our launch). That's also stuff where it's hard
| to calculate "force multiplier".
|
| So I dunno. I'm talking about an eng organization of 50-100
| people, so maybe that's not big enough to be valid for your
| question. But the point is that while the role is necessary and
| is a "multiplier", it's difficult to calculate because it's not
| as simple as just being 5x or 10x faster than another developer
| for a well-defined task.
| ok123456 wrote:
| Lake Woebegone Effect. They like to think that they're force
| multipliers too.
| marssaxman wrote:
| I can't recall "staff engineer" being something people even
| talked about before ~2 years ago. It's strange to see this idea
| come up and become taken seriously, seemingly out of nowhere.
| chrisseaton wrote:
| > It's strange to see this idea come up and become taken
| seriously, seemingly out of nowhere.
|
| Nonsense it's as old as the tech industry, and the defence
| industry it grew out of.
|
| The name comes from the military, where it's even older.
| cannam wrote:
| > Nonsense it's as old as the tech industry, and the
| defence industry it grew out of.
|
| I was curious about this, because I also think of the staff
| engineer as a newish thing, and I don't believe I've ever
| actually met one.
|
| I searched my old email for the term and found that the
| first reference I have was in January 1996, in a HotWired
| HotFlash newsletter:
|
| "Java - so-named because it evokes liveliness and speed -
| is the brainchild of Arthur van Hoff, a senior staff
| engineer at Sun Microsystems. He's the HotJava engineering
| lead, has designed most of the Java applet API, is the
| implementor of the current Java compiler, and is the author
| of the book "Hooked on Java." Get the scoop behind the
| hype, when Arthur van Hoff joins us in Club Wired on
| Friday, 12 January, at 12 p.m. PST (20:00 GMT)."
|
| After that there's really nothing until the term starts
| appearing in LinkedIn notifications around 2010. I guess
| that just means it wasn't used in the circles I moved in,
| so only became visible to me when I joined LinkedIn.
| chrisseaton wrote:
| What were influential engineers called in the companies
| you were in before?
| alex-mohr wrote:
| Member of Technical Staff, or MTS
| chrisseaton wrote:
| So that's exactly the same thing just a slightly
| different wording?
| roflulz wrote:
| AMD and Intel and old semiconductor companies have always
| had titles like - "Engineer 1" "Engineer 2" "Senior
| Engineer" and then -> "Member of Technical Staff" above
| that. (Search MTS, SMTS, PMTS etc. on LinkedIn to see a
| million of them)
| marssaxman wrote:
| The term may well be as old as the tech industry, but I
| have somehow spent all 30-odd years of my career in said
| industry without hearing it discussed, until somewhat
| recently. I wonder what has changed.
|
| I don't think of the tech industry _I_ have been working in
| as being related to defense much at all - I trace my
| computing roots back to the home computer era of the '80s.
| Perhaps there have been parallel streams which are now
| mixing.
|
| On the other hand I have never cared about titles, so
| perhaps it's been there all along and I just didn't notice.
| 0x445442 wrote:
| Yeah, I've been a software engineer since 1996, the first
| ten years in the defense industry and I never heard the
| title before a few years ago.
| chrisseaton wrote:
| > without hearing it discussed, until somewhat recently
|
| Maybe you're now reaching that level yourself so now
| interacting with those people?
|
| Like saying 'how come nobody's ever discussed prostrate
| exams until I got to my 40s'.
|
| > I don't think of the tech industry I have been working
| in as being related to defense much at all
|
| Microprocessors come from defence, as does Silicon
| Valley.
| rusk wrote:
| The term seems to be quite new, but the concept itself is
| quite well worn
| simonw wrote:
| Right. The problem this is solving is age-old: how do you
| maintain a career track for your best performing engineers
| without forcing them into people management?
| cebert wrote:
| This was a great read. I think there may be a 5th archetype for
| individuals who help enable others with "glue" work. This work
| can easily go unnoticed, but can have a dramatic impact on
| individual and team productivity.
| [deleted]
| biscuits1 wrote:
| But what's your blast radius?
| lamontcg wrote:
| I'm more of a explosively formed penetrating round capable of
| cutting through heavy layers of reinforced technical debt.
___________________________________________________________________
(page generated 2022-10-06 23:00 UTC)