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.
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.
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.
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.
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.
I don't think of the tech industry I have been working in as being related to defense much at all - I trace my computing roots back to the home computer era of the '80s. Perhaps there have been parallel streams which are now mixing.
On the other hand I have never cared about titles, so perhaps it's been there all along and I just didn't notice.
Maybe you’re now reaching that level yourself so now interacting with those people?
Like saying ‘how come nobody’s ever discussed prostrate exams until I got to my 40s’.
> I don't think of the tech industry I have been working in as being related to defense much at all
Microprocessors come from defence, as does Silicon Valley.
We should rename all the accountants "staff" though.
As the GP said these titles have existed for a long time. But for whatever reason there's also been a progression in terms of them being super common in social media discussions.
The cynic in me says that it is driven by a certain subset of Internet Famous Devs progressing through their career.
From my experience job descriptions/title that lean into "architect" tend to attract people that can theorize about how software ought to be built all day, but haven't written a single line of code in ages.
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 :)
That's how they make sure the problem stays fixed.
If it's not that urgent, they might guide others in a more asynchronous fashion on how to get to a fix
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.