Live data from Hacker News

Staff Engineer Archetypes (2020)

lethain.com

41–50 of 269 posts

Re: Staff Engineer Archetypes (2020)

#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 job-title inflation, that makes me sad.

Re: Staff Engineer Archetypes (2020)

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

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.

Re: Staff Engineer Archetypes (2020)

#45

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…

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.

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

Re: Staff Engineer Archetypes (2020)

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

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.

Re: Staff Engineer Archetypes (2020)

#47

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…

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.

Re: Staff Engineer Archetypes (2020)

#48

Earlier quoted context omitted.

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.

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

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

Re: Staff Engineer Archetypes (2020)

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

Re: Staff Engineer Archetypes (2020)

#50
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 agree with you: fix what needs to be fixed. But that can be human things too, not just code.

Post reply on HN