Why I Ignore The Spotlight as a Staff Engineer
88 points by lalitm
88 points by lalitm
One potential conclusion you may draw from this is that big tech companies do in fact possess the ability to build good software, as long as that software is not being deployed to its customers.
This gives vocabulary to what I've seen in the past several years of my career—gradually I've felt more like a weapon that leadership can point at an odd project to fix it or speed it up. The attention is positive, but the more often I'm moved, the slower and less effective I am. I have taken to optimizing stress first, work goals second.
But while finding the team might have involved luck, staying there for almost a decade was a choice.
Isn’t that also luck though? Your team hasn’t had a reorg in almost a decade, which IME is really rare to see at Google.
To an extent, yes the stability of the team and org is not "normal" from the perspective of the rest of the Google. But we've also had 4 different directors in that time-frame so it's not like we've not had changes in leadership. I just think there's a lot less incentive for exec meddling the more out of the "spotlight" you are. And as I say, I've seen several other teams in Android who I also feel have been quite stable in terms of the senior people in those teams and what their "mission" is.
This is especially the case if you are able to show concrete successes to the rest of the org and to any other exec who starts questioning your work.
I think we have differing perspectives. In my experience, even if your team is showing concrete successes, execs will still kneecap it by doing layoffs/reorgs. This can also happen if your team is out of the spotlight (but I agree that there is more chaos if it’s in the spotlight). It’s awesome that you found a good place though; Perfetto seems cool :)
For calibration, have the other teams they name as stable and out-of-spotlight been reorged in this timeframe?
There is an explicit claim in the text that such teams are generally rare to see from outside…
Thanks for this. Definitely going to share it with my team.
Great article. I think this does a great job calling out the mindset differences between the product and dev-tools/infra worlds. As someone who has bounced around a bit between the "product" and "infra" side of the house (ultimately I've settled in infra), I do agree with most points written here, but something I wanted to highlight...
In a product organization, you often need to impress your manager’s manager. In an infrastructure organization, you need to impress your customers’ managers.
I think this is true, but it shouldn't be understated that impressing your own management chain is still important in infra. If the infrastructure you support is the kind that is non-optional and "just works" most of the time (think networking, firewall, compute platform type of thing), then if you've done your job right, your customers won't ever be impressed because they'll forget you even exist. How often do you find yourself praising your energy company that powers your home? Hopefully not often, but you get my point.
You know that old Futurama quote, "When you do things right, people won't be sure you've done anything at all"? That's my basic philosophy as an infrastructure provider. Of course there's nuance to this too - customer complaints about the parts they do use, visibility and debug tooling are all very important too, and they even start to veer a little bit more into the product side of things again. But my goal as an infrastructure engineer is ensure that the product-level parts of the company don't even know I exist, unless necessary. If you can migrate petabytes of data on live systems and none of your customers even notice, that's a huge win to share with your management chain.
This is much more closely aligned with my experience as a staff engineer in big tech than what's described the usual writeups about that position.
There's one other dimension that I think doesn't get discussed enough: there can be huge variation in how technically hands-on staff engineers are in their day-to-day work.
The popular wisdom is that when you hit staff, you start spending most of your time in meetings and reviewing design docs and mentoring/helping other engineers, and you stop writing much code. And that was true for some of my peers at the time. But not all of them, and not me: while I had meetings and mentoring and design reviews, I spent the vast majority of most work days doing hands-on technical work.
The biggest difference between "senior" and "staff" for me was autonomy: very often I'd be working on some new prototype or experiment that I'd dreamed up on my own, rather than implementing someone else's product or tool idea. Some of those experiments worked out, others didn't, but part of the path to staff for me was having a solid history of both picking projects with high potential payoff and (the hard part!) letting go of them if they didn't pan out.
But not all of them, and not me: while I had meetings and mentoring and design reviews, I spent the vast majority of most work days doing hands-on technical work.
I'm not in big tech, but at my company, most staff engineers are "people with lots of critical knowledge that hasn't been institutionalized/formalized who can use their special knowledge to maintain critical systems and firefight". I'm the only staff eng I know who spends real time working on strategy and mentoring (I'm sure there are a few others in my org). I've heard this distinction referred to as "barbarian vs bureaucrat" (these aren't my terms, hopefully they at least sound equally disparaging 🙃).
I get the feeling what she's describing (not being at management's whim, recognizing recurring patterns, initiating projects with low visibility but high importance) used to be the job description of a "senior engineer".
I recognize this author is probably far more skilled than most senior software engineers (seeing as they made senior just three years after graduating), but the attitude they're describing isn't so much about skill, it's about experience.
And I'm not trying to imply this is the effect of title inflation, as much as is the effect of shrinking autonomy of software developers everywhere.
I generally use the same strategy, I guess, though there is a "grass is greener on the other side" effect. I feel like I'm getting complacent and detached from the excitement of cool products.