4 ms·

the fetishization of staff engineers is really fascinating. do they actually act as "force multipliers", are they really essential to the success of large engin

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.

mikefallen 4y ago
Second this, also stemming from this tend to fall behind technically speaking on the “bleeding edge”
kccqzy 4y ago
I think only the Solver type from the article acts as a force multiplier. Have a strange bug that you have been trying and failing to solve for a few days? They will probably fix that in a few hours and unblock you immediately.
- ilc 4y ago
  Solvers don't fix the problem. They tell you how to fix the problem. :) That's how they make sure the problem stays fixed.
  - Matthias247 4y ago
    they should be able to do both. In case a high severity issue is ongoing, and someone knows how to fix it very fast - they should probably do it. Or guide another engineer in realtime on how to do it. If it's not that urgent, they might guide others in a more asynchronous fashion on how to get to a fix
    - ilc 4y ago
      They most certainly can do both, and do. But as a solver, I prefer to give it back to the person to solve. 1. I may know enough to know the problem and the rough fix. I may not know how to fix it in their codebase as quickly as they do. 2. See above. I want them to internalize the fix. That said, I ain't afraid to dive in and get it done. I remember not understanding some Java build system somewhere. So I fixed the code, tested it quickly, and hand deployed the jar... then I asked how to fix it for real ;) My boss was amused.
nosequel 4y ago
> 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) companies, I do feel like Staff engineers can really have a multiplying effect. Based on the OP, I personally fell into "The Solver" category and would bounce around helping out teams who were stuck on something particularly troublesome. > are they really essential to the success of large engineering orgs I don't about know this one. In a large org, I was at my most ineffective. I do think they are essential to small-to-mid sized engineering orgs though, even if it only means they help out by knowing all the ways *NOT* to do something.
- scarface74 4y ago
  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
tunesmith 4y ago
Speaking only for myself, I'm the one they ask when there's a problem no one else on the regular team can solve, and I don't have someone technical "above" me to ask for help. I can only collaborate with people and drive the investigation and communicate the results. So that's sort of the Solver/SRE role. I don't know how to calculate "force multiple" for that scenario because in the absence of me solving it, the teams would basically limp along without a solution without fully understanding the negative impact. I'm also the one that sets certain best practices in code repositories, and I've learned that identifying a best practice and assigning it to someone else to introduce doesn't work very well. At those times I have to dive into the code, restructure things, and then present, so that the other coders can actually refer to it as an example. This in addition to helping team members know what is in-bounds and out-of-bounds for their story, and helping with code reviews. This is roughly the "tech lead" role. This has some sort of force-multiplier impact just by doing things like guiding the metaphorical ships away from the metaphorical icebergs. Finally, there's the classic "architecture" role, where we identify tech paths for the org in general. Recognizing when a well-targeted effort can replace an inefficiency with something smoother. Like I had to take it upon myself to set up elasticsearch and kibana correctly, and structuring the code to report the correct dimensions. Or structuring how our graphql queries worked so they didn't pound our graphql server. Or placing an in-memory cache on one layer of servers (this basically saved our launch). That's also stuff where it's hard to calculate "force multiplier". So I dunno. I'm talking about an eng organization of 50-100 people, so maybe that's not big enough to be valid for your question. But the point is that while the role is necessary and is a "multiplier", it's difficult to calculate because it's not as simple as just being 5x or 10x faster than another developer for a well-defined task.
ok123456 4y ago
Lake Woebegone Effect. They like to think that they're force multipliers too.
marssaxman 4y ago
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.
- chrisseaton 4y ago
  > 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.
  - cannam 4y ago
    > 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.
    - chrisseaton 4y ago
      What were influential engineers called in the companies you were in before?
      - alex-mohr 4y ago
        Member of Technical Staff, or MTS
martythemaniak 4y ago
Take the top 10% of engineers in your organization. They are the ones where the technical buck stops, the ones with the deepest technical and business domain expertise, the ones that define and drive the hiring process, the ones that drive changes that impact many teams, the ones that set the cultural tone for the rest of the engineers. It doesn't matter what you call them, they've always been there and always will be. Unless your engineering org is not run by engineers, in which case, you should join a company that has staff engineers :)
larve 4y ago
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.

mikefallen 4y ago

Second this, also stemming from this tend to fall behind technically speaking on the “bleeding edge”

kccqzy 4y ago

I think only the Solver type from the article acts as a force multiplier. Have a strange bug that you have been trying and failing to solve for a few days? They will probably fix that in a few hours and unblock you immediately.

ilc 4y ago
Solvers don't fix the problem. They tell you how to fix the problem. :) That's how they make sure the problem stays fixed.
- Matthias247 4y ago
  they should be able to do both. In case a high severity issue is ongoing, and someone knows how to fix it very fast - they should probably do it. Or guide another engineer in realtime on how to do it. If it's not that urgent, they might guide others in a more asynchronous fashion on how to get to a fix
  - ilc 4y ago
    They most certainly can do both, and do. But as a solver, I prefer to give it back to the person to solve. 1. I may know enough to know the problem and the rough fix. I may not know how to fix it in their codebase as quickly as they do. 2. See above. I want them to internalize the fix. That said, I ain't afraid to dive in and get it done. I remember not understanding some Java build system somewhere. So I fixed the code, tested it quickly, and hand deployed the jar... then I asked how to fix it for real ;) My boss was amused.

nosequel 4y ago

> 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) companies, I do feel like Staff engineers can really have a multiplying effect. Based on the OP, I personally fell into "The Solver" category and would bounce around helping out teams who were stuck on something particularly troublesome. > are they really essential to the success of large engineering orgs I don't about know this one. In a large org, I was at my most ineffective. I do think they are essential to small-to-mid sized engineering orgs though, even if it only means they help out by knowing all the ways *NOT* to do something.

scarface74 4y ago
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

tunesmith 4y ago

Speaking only for myself, I'm the one they ask when there's a problem no one else on the regular team can solve, and I don't have someone technical "above" me to ask for help. I can only collaborate with people and drive the investigation and communicate the results. So that's sort of the Solver/SRE role. I don't know how to calculate "force multiple" for that scenario because in the absence of me solving it, the teams would basically limp along without a solution without fully understanding the negative impact. I'm also the one that sets certain best practices in code repositories, and I've learned that identifying a best practice and assigning it to someone else to introduce doesn't work very well. At those times I have to dive into the code, restructure things, and then present, so that the other coders can actually refer to it as an example. This in addition to helping team members know what is in-bounds and out-of-bounds for their story, and helping with code reviews. This is roughly the "tech lead" role. This has some sort of force-multiplier impact just by doing things like guiding the metaphorical ships away from the metaphorical icebergs. Finally, there's the classic "architecture" role, where we identify tech paths for the org in general. Recognizing when a well-targeted effort can replace an inefficiency with something smoother. Like I had to take it upon myself to set up elasticsearch and kibana correctly, and structuring the code to report the correct dimensions. Or structuring how our graphql queries worked so they didn't pound our graphql server. Or placing an in-memory cache on one layer of servers (this basically saved our launch). That's also stuff where it's hard to calculate "force multiplier". So I dunno. I'm talking about an eng organization of 50-100 people, so maybe that's not big enough to be valid for your question. But the point is that while the role is necessary and is a "multiplier", it's difficult to calculate because it's not as simple as just being 5x or 10x faster than another developer for a well-defined task.

ok123456 4y ago

Lake Woebegone Effect. They like to think that they're force multipliers too.

marssaxman 4y ago

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.

chrisseaton 4y ago
> 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.
- cannam 4y ago
  > 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.
  - chrisseaton 4y ago
    What were influential engineers called in the companies you were in before?
    - alex-mohr 4y ago
      Member of Technical Staff, or MTS

martythemaniak 4y ago

Take the top 10% of engineers in your organization. They are the ones where the technical buck stops, the ones with the deepest technical and business domain expertise, the ones that define and drive the hiring process, the ones that drive changes that impact many teams, the ones that set the cultural tone for the rest of the engineers. It doesn't matter what you call them, they've always been there and always will be. Unless your engineering org is not run by engineers, in which case, you should join a company that has staff engineers :)

larve 4y ago

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.