The 'line' vs 'staff' distinction makes a ton of sense to me. I've been reading Will Larson's blog about staff engineers and trying to articulate what sets staff engineers apart, and I think you've nailed it. "Staff" more or less equals "support", but on an executive or strategic level.
A problem I deal with personally is growing into "Staff" style work. I'd love to have bigger, wider impacts on a more strategic level, but I'm so damn good at getting into line work and doing a good job of it. (I also understand myself well enough to know that I like stabbing away at a technical problem way more than I like a VP or C-level planning meeting.) I also feel like I've gotten so good at doing "line" style work that there doesn't seem to be org pressure to promote me. My perception is that I'm considered too good on the "line"; I'd be a loss to the org to move up a notch. This could also mean that I'm actually not as good as I think I am, or can't see the forest for the trees. It could also be a sign of what a brutal struggle promotion is for "line" style workers. (More competition, less routes up the ladder.)
Is there a path to grow there, or am I just doomed to be a Principal Engineer? (Not the worst fate, "doomed" is probably too strong a word there lol)
I don’t think I’d try to mix those things together. Same word, completely different things.
In this article, a new grad who works on basic HR IT tasks for a factory is doing staff work. That’s not staff level scope in the Will Larson sense.
There are plenty of “staff software engineers” in the Will Larson sense who create strategy for new product lines and launch them - “line” level work. Also plenty who work on DevX - “staff” level work.
I think we'll have to agree to disagree. My takeaway from much of Larson's writing is that staff engineers can do the line work required to launch new product lines, but generally don't, because the impacts of their strategic work is much higher than that of line style coding.
They direct and advise on technical strategy, but delegate execution to others, because having the 10k foot view is typically more valuable when deployed on strategic opportunities.
I think you're missing what the above is saying, i.e. that the featured article uses staff in a different way than Larson and most discussions around "staff".
Will and this article use "staff" in a completely different sense. The author of the post even acknowledges this difference in his HN comment at the top of this post.
Will uses "Staff Software Engineer" as the rank of Staff (I.e. one above Senior).
This article uses "staff engineer" not as the rank, but as the type of engineer (Line vs staff).
"Line vs staff" is a fundamentally bankrupt concept, as much so as "combat vs logistics". Wars are won or lost on logistics, as Russia recently discovered.
Money wasted in a "profit center" has exactly the effect on bottom line as the same waste in a "cost center", and failure of a "cost center" can have just as large an effect on your business as in a "profit center". The only meaningful distinction is that the return on investment in a "cost center" is gated by the success of "profit centers".
But, woe betide if you find yourself in a cost center at a company run by MBAs. Get yourself to a profit center, or to a better-run, less MBA-saddled company.
Look at the Ukraine War… Russia clearly completely ignored logistics and failed in their attempt at a “modern” war and quickly degraded to a WW1 style artillery duel.
And yes, being a NCO or field officer in the Russian army is miserable.
> First time I've ever heard these two things talked about as a matter of "this versus that" and not "combat and logistics".
Not sure if you’re being sarcastic? Or haven’t read much about the military and are assuming?
Combat vs combat support vs combat service support (logistics) is a very common and very significant distinction to make and usually matters a lot for a great many things.
Has a logistics branch officer ever led a major Army? We had an artillery officer in the UK and even that was a talking point at the time.
> A problem I deal with personally is growing into "Staff" style work.
My problem is that you seemingly get locked into it. The only people who want to talk to me are staff positions, the “line” roles do not want me at all. Technically my current role is at a tech company, but in a “staff-like” position and happens to be one of the least recognized teams invoice department because the work is among the least visible and a very tiny percentage of the companies income.
"destined" may be a better word than "doomed" in this case :)
I have a similar feeling, I like doing low level work but I also mentoring junior engineers, hopefully that mentoring will multiply my overall output over time!
I also really like the mentorship angle. It's really cool to watch someone grow, and how fast they do when given stuff that's just outside their current capability level.
I look for folks with this background to join my team at my Day Job. I need folks with a solid hands-on technical background who want to stop building things and start telling me which people SHOULD build and which people ARE building those things so I can give those people money.
It’s tricky because I need hands on experience but the desire to switch to a more strategic, executive-style role. Plus folks need to have the core communication and people skills to manage a complex set of stakeholders.
Hard to find good people, but the people I find tend to be very very good.
> The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.[
Yeah sure but the point being these people never wanted this role and not only t company lost them as productive ICs to some other role but they lost them altogether (great engineers with deep domain expertise)
A problem I deal with personally is growing into "Staff" style work. I'd love to have bigger, wider impacts on a more strategic level, but I'm so damn good at getting into line work and doing a good job of it. (I also understand myself well enough to know that I like stabbing away at a technical problem way more than I like a VP or C-level planning meeting.) I also feel like I've gotten so good at doing "line" style work that there doesn't seem to be org pressure to promote me. My perception is that I'm considered too good on the "line"; I'd be a loss to the org to move up a notch. This could also mean that I'm actually not as good as I think I am, or can't see the forest for the trees. It could also be a sign of what a brutal struggle promotion is for "line" style workers. (More competition, less routes up the ladder.)
Is there a path to grow there, or am I just doomed to be a Principal Engineer? (Not the worst fate, "doomed" is probably too strong a word there lol)