Live data from Hacker News

Staff Engineer Archetypes (2020)

lethain.com

31–40 of 269 posts

Re: Staff Engineer Archetypes (2020)

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

Re: Staff Engineer Archetypes (2020)

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

Unit tests, CI, docs this overhead, I want move fast and break things.

Re: Staff Engineer Archetypes (2020)

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

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.

Re: Staff Engineer Archetypes (2020)

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

Re: Staff Engineer Archetypes (2020)

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

The term seems to be quite new, but the concept itself is quite well worn

Re: Staff Engineer Archetypes (2020)

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

Re: Staff Engineer Archetypes (2020)

#37
post #35

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.

The term seems to be quite new, but the concept itself is quite well worn

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?

Re: Staff Engineer Archetypes (2020)

#38

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've never seen a Therapist Staff Engineer. This seems to be the primary function of middle management.

Re: Staff Engineer Archetypes (2020)

#39
post #3

>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

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

Re: Staff Engineer Archetypes (2020)

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