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

81–90 of 269 posts

Re: Staff Engineer Archetypes (2020)

#81

Post by virissimo »

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.

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.

Re: Staff Engineer Archetypes (2020)

#82

Post by dasil003 »

vanjajaja1 wrote: post #34
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.

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

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.

Re: Staff Engineer Archetypes (2020)

#83

Post by vsareto »

sbf501 wrote: post #77
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…

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…

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.

Re: Staff Engineer Archetypes (2020)

#84

Post by denton-scratch »

opportune wrote: post #53
denton-scratch wrote: post #41

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

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

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

Re: Staff Engineer Archetypes (2020)

#85

Post by yamtaddle »

Supermancho wrote: post #44
gorgoiler wrote: post #28

Earlier quoted context omitted.

Code Wins Arguments

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

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.

Re: Staff Engineer Archetypes (2020)

#86

Post by scarface74 »

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.

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.

Re: Staff Engineer Archetypes (2020)

#87

Post by sbf501 »

vsareto wrote: post #83
sbf501 wrote: post #77

Earlier quoted context omitted.

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…

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.

Point taken. My comment is a good example of "tech privilege".

Re: Staff Engineer Archetypes (2020)

#88

Post by scarface74 »

nosequel wrote: post #14
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.

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

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

Re: Staff Engineer Archetypes (2020)

#89

Post by pc86 »

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…

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

Re: Staff Engineer Archetypes (2020)

#90

Post by tristor »

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…

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.
Post reply on HN