Comment by atomicnumber3 | Hacker News Reader

Comment by atomicnumber3 | Hacker News Reader

Parent Full thread

I mean, yes and no. I find staff engineers, and especially the senior-staff-engineer-type positions, to be the ones most sensitive to the exact specifics of the org they've joined.

I've seen a senior staff engineer (at a popular unicorn you've all heard of) who was a very smart, but also friendly and reasonable person (how often are those traits in opposition of each other!). They were very good at the staff engineer game. They were vouching for us to upgrade a framework that we pumped 50M of spend through per year. From v2 to v3. It wasn't a huge change, not like python 2 to 3 at all. Positively trivial compared to py2 to 3. But management just were not up for it at all. Even with research done showing we could expect literally a baseline of 10% improvement in performance (so you do the math on that vs the 50M of spend), they just did not want to "waste time on version upgrades." The staff engineer was told they were being unreasonable in pushing so hard. Their manager tried to ditch them, but again, they're good at the staff eng game, so they switched teams due to being in the good graces (due to an excellent track record) with a middle manager above them. They decided, hey fuck you, I'm going to one man army this effort. They did, they had preview versions ready in less than a month and had migrated some of the bigger-win jobs within 2, saving their annual comp (which was prodigious) several times over just in that. Suddenly everyone was keen on moving their stuff over now that the startup cost (both political and eng-time) was paid.

Anyway fast forward a year, the rollout is complete and nearly the entire fucking management chain above him has turned over, a 50/50ish mix of firings vs quittings. But he's still there and the upgrade migration is complete.

So sure, sometimes staff engineers have a stick up their bum and can't dislodge it enough to get work done on the bottom line. But sometimes they're the only sane ones in a crazy world, and you can only do so much to try to turn a balky mule around.

This reminds me of the blog post, "People can read their manager's mind," by Yossi Kreinin.

https://yosefk.com/blog/people-can-read-their-managers-mind....

In particular:

"Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things."

One way to read your story is that upper management applied heavy downward pressure, to the extent that relatively trivial changes in the organization were discussed as 'costly' - in an effort to get engineers like the senior staff engineer in your example to pull heroic feats of engineering in a few weeks all by himself, instead of using a small group of engineers / resources.

I think your argument is that 'it worked for him' because he is still there while the managers are not, but reality may be the managers were there to have that effect in the first place and the 50/50 turnover was because they were in the thick of it.

That'd be my cynical take, anyway.

Especially if he wasn't rewarded commensurately for that feat.

"upper management applied heavy downward pressure"

Correct

"I'm an effort to get engineers like the senior staff engineer to pull heroic feats"

I think this gives them too much credit. The reality, imo, is that the org had a pathological emphasis on "impact" and ran performance reviews so tight that everyone, managers included, were so scared of being PIPd and losing their grants that they were extraordinarily risk averse in planning and picking projects to bet on. And leadership in general undervalued "infra-y" changes as mostly make-work.

The turnover was partly because of this general effect - people scared, not betting big or smart enough, and optimizing for holding on / not getting fired. And to their credit, most of these people vested 2-3 years of their 4-year grant before it all fell over, so they made out decently lucratively, so maybe they're the real winners in all this after all.

That's an interesting take, thanks for writing that. That gives me something to think about.

I’m not American so I don’t know what a staff engineer does, and googling the term is not helping much. I have also not worked in any software company that has “engineering teams” which would maybe have helped me understand the Google results.

What you are saying is that sometimes a senior engineer manages to make good things happen?

Did this person get rewarded for this huge effort they put in? You say they already have prodigious yearly compensation, was it at least doubled given that they saved it several times over?

> Did this person get rewarded for this huge effort they put in? You say they already have prodigious yearly compensation, was it at least doubled given that they saved it several times over?

When you're getting paid $500k-$1m/year or more as a staff engineer, putting in huge effort and getting organization-wide impactful results is part of the job description. I'm sure it had a good effect on their yearly comp review, but suggesting that their comp should be doubled because they did their job is silly.

Staff engineers (in the FAANG parlance) are, generally speaking, ICs who were previously senior engineers who have proven themselves enough that they're trusted to be roughly autonomous, they're kind of "peers" to engineering managers in a way. While a senior engineer will typically not have the political capital move big politically-heavy rocks, it is typically down in the staff engineer's job description that they are expected to. It's basically shifting from a focus on code and building systems to people/the org and architecting systems that fit the org.

"Did the person get rewarded for this huge effort" Money-wise? Haha. No. Only in the sense that they further solidified their soft power as someone you shouldn't bet against. And of course the sense of pride that comes with shipping something (that further enriches some capitalist and maybe yourself to 0.0013% of the effect, since that's how much of the company your grant commands shares of).

> staff engineers are ICs

Wtf is an IC? Internal consultant? Individual contributors (what does that even mean? One person team?)

Using abbreviations to explain something is a bad way to explain...

Used to mean a non-manager. I agree it's a nonsense term.

It still does. Individual contributor is someone with no reports.

A staff engineer is a level above senior. What they do is make them themselves more valuable than the regular engineer who has been around for 10+ years. As you get experience there is diminishing returns, so most engineers will not make a staff level (though there is plenty of title inflation and so you will find many). A staff engineer needs to know the code (or whatever they engineer) well, but they don't normally write a lot of code. They tend to spend more time thinking about the larger problems (including forcing through upgrades nobody wants to pay for), mentoring juniors, and figuring out the hard architecture problems (software architects have a role, but in my experience they rarely actually create architecture despite the name - possibly because what developers need of architecture is different from management?).

Staff level developers are trusted to figure out what needs to be done without direction. When they are given direction it is figure out how the other engineers break this problem up and do it - typically not do it themselves.

If staff engineers are doing something it is not important to any project. So nobody feels bad about interrupting them if they need help or something urgent comes up. (this also means you are developing your senior developers into staff engineers by giving them responsibility)

Reply on news.ycombinator.com