Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Staff Engineer Archetypes (2020)

lethain.com

Post reply on HN
Print view View original

61–70 of 269 posts

Re: Staff Engineer Archetypes (2020)

#61

Post by eropple »

PragmaticPulp wrote: post #54
agentultra wrote: post #16

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…

> 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…

> 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.

Re: Staff Engineer Archetypes (2020)

#62

Post by mmmpop »

quickthrower2 wrote: post #50
voz_ wrote: post #10

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.

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 agre…

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??

Re: Staff Engineer Archetypes (2020)

#63

Post by ilc »

kccqzy wrote: post #13
efficax wrote: post #8

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.

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.

Solvers don't fix the problem. They tell you how to fix the problem. :)

That's how they make sure the problem stays fixed.

Re: Staff Engineer Archetypes (2020)

#64

Post by maerF0x0 »

hayst4ck wrote: post #40

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 fr…

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.

Re: Staff Engineer Archetypes (2020)

#65

Post by ble »

hayst4ck wrote: post #40

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 fr…

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.

Re: Staff Engineer Archetypes (2020)

#66

Post by maerF0x0 »

eropple wrote: post #61
PragmaticPulp wrote: post #54

Earlier quoted context omitted.

> 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…

> 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…

> 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.

Re: Staff Engineer Archetypes (2020)

#67

Post by eurasiantiger »

ble wrote: post #65
hayst4ck wrote: post #40

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 fr…

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…

Or maybe they just type faster.

Re: Staff Engineer Archetypes (2020)

#68

Post by bioemerl »

ble wrote: post #65
hayst4ck wrote: post #40

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 fr…

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…

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.

Re: Staff Engineer Archetypes (2020)

#69

Post by dogleash »

voz_ wrote: post #10

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.

>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?

Re: Staff Engineer Archetypes (2020)

#70

Post by davidthewatson »

> 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.

Post reply on HN