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.
They exist to point out that there isn't only one way to define someone as staff engineer. If you don't write them out, then companies degrade into only allowing one type of archetype to get promoted, which discounts other ways of doing things, leading to a less efficient company. You see it at google in 2018: https://mtlynch.io/why-i-quit-google/ and today with the LPA (Launch, Promote, Abandon) cycle : https://nextbigwhat.com/the-lpa-cycle-at-google-launch-promo...
What do people complain about at FB that they can't seem to get done there that seems really obvious that you should? You'll find similar issues. Maybe not like google, but unique to FB.
These archetypes seem like they should have different job titles except for maybe Solver. Additionally, what differentiates a Staff Engineer who's a Team Lead archetype from someone that's a TeamLead?
Overloading the Staff Engineer title with these archetypes is going to lead to identity confusion in the job hunting landscape.
If you're searching for Staff Engineer positions by title, now you need to figure out if your personal archetype matches what they're looking for. You might be able to get it from the posting, but maybe not.
This also confuses salary bands. You might have some really effective management type Staff Engineers making loads of cash because they're management, but someone who's just a Solver might be on the far lower end of pay because they aren't management. These examples might be reversed if the Solver is able to solve really hard technical problems.
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…
Depends on the role of management in the company. At some companies there is a bright line where managers are expected to _not_ participate directly in the technical discussion of how to solve problems.
So say, in such an organization, two teams each with a Staff Engineer are taking different and conflicting approaches, and neither Staff has been able to pursuade the other to their side? Often in this scenario it's extremely valuable to have a technically capable third-party mediator to help bring the two together.
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…
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.
> 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…
> 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.
I'm not suggesting that the role isn't helpful or that some people wouldn't like it.
This is the problem:
> At the moment I'm working outside of an engineering function,
If the company needs a firefighting cross-team manager, get a firefighting cross-team manager and empower them accordingly.
But hiring Staff Engineers to combat management dysfunction is a misunderstanding of the Staff Engineer role.
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'm not sure if I'd name them "the politician", because I think they are not doing the harm consciously, but I've met several of them. Pair it with the "CV builder" ,that just throws new technologies at problems to add them to their CVs, and now your codebase is a minefield.
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 it was less about politics and more about getting shit done, and if you failed to get shit done, you were alerted to that very quickly. If you did get shit done, and got it done well, you got promoted, and were given even more shit to get done. Upper management at those big three had their game tight.
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. The whole point of having this as a role/title is to give leverage to those who have proven they can use it for the good of the organization. That means maximizing the ratio of effect to code written, by themselves or anyone else, and there are a great many ways to do that. "Code is all" is the hallmark of the very junior engineer who hasn't finished climbing that first rung yet - a very important rung, yes, but still only one of many. TBH it comes across as something between sour grapes and Tall Poppy Syndrome.
Mozilla had some interesting archetypes. I only recall two because I didn't work there, but they were Wizard and True Believer. They all seemed to be more apt archetypes than standard job progression ladders because they allowed for more diversity than just 'manager' and 'technical' paths. I applaud the attempts even if they do seem a tad cringy.
This was a great read. I think there may be a 5th archetype for individuals who help enable others with “glue” work. This work can easily go unnoticed, but can have a dramatic impact on individual and team productivity.