Live data from Hacker News

Staff Engineer Archetypes (2020)

lethain.com

171–180 of 269 posts

Re: Staff Engineer Archetypes (2020)

#171

Earlier quoted context omitted.

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…

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

I don't think there's anything wrong being this 1x engineer. In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance.

Re: Staff Engineer Archetypes (2020)

#172

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.

Wat? The Wolf was a classic solver. Also see Mike from BB/BCS series

Re: Staff Engineer Archetypes (2020)

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

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…

Code is a liability, but it's very often the least-bad option. In particular it's severely underrated as a communication mechanism; all too often people go through weeks of planning and discussion to save hours of prototyping.

Re: Staff Engineer Archetypes (2020)

#177
post #74

Earlier quoted context omitted.

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.

I think that's because a good amount of 1x engineers could be 10x engineers if given the right kinds of support. When leadership makes sure they have that support, they become 10x engineers. If you only ever see clusters of 10x engineers, it's more likely to be about the factors around them than the engineers themselves.

I think it's both. You get a 10x engineer and a good environment and they bring in other 10x engineers who want to work with them.

Re: Staff Engineer Archetypes (2020)

#178

Earlier quoted context omitted.

More often than not, it's people that care about how to create abstractions that amplify their productivity. That is only possible if they can spend some time building abstract stuff that cannot be explained to non-technical stakeholders, which is not possible with sweatshop engineering methodologies like Scrum, or when you promote the smiling bozos that completed their 5 person-minutes Agile crash course to manageme…

Abstraction is not a panacea. It's often the root cause of significant technical debt. Abstracting as late as possible is often the best course of action, as it give you more information about how to abstract from the initial implementation.

Improper abstraction does usually lead to significant technical debt, but if you are lucky you can bank your short-term successes and leave the tech debt to someone else.
Post reply on HN