alt Hacker NewsI ignore the spotlight as a staff engineer
Comments
This is a really good article. Don't get caught up in the tone of "anti-politics" or "slow is good." It's describing a brand of politics and impact that is just as mercurial as product development if you do it wrong. Infra and DevEx behaves fundamentally differently, and it can be a really great path if it suites your personality.
For context: my last job was PM for the infra team at Slack. I did it for 5 years. I didn't learn about Slack's product launch process until year 4. Everything until that point was internal work, on our k8s/service mesh and DB infrastructure.
The important insight here is about customer success and shadow management. Every successful engineer (and my own success) derived from figuring out what product engineers needed and delivering it. The "Shadow Hierarchy" feedback was make-or-break for those promotions. It's _hard_ to optimize for that, because you need to seek that feedback, understand if addressing it will actually fix the problem, and deliver it quickly enough to matter in the product org.
If you're willing to optimize for that internal success, you'll be rewarded, but in your career and in stability in the organization. I disagree this is only at Big Tech -- companies as small as 100 engineers have real and strong cultures in the right team, under the right manager.
But don't think this is some magical cheat code to ignoring what's important to the business. It's just a different, perhaps more palatable, route to managing the alignment and politics that are a necessary part of growth at any company.
This is a well articulated article and the OA makes some good observations about the differences in evaluation between a product engineering org and an infra engineering org. It's also clear he's got real technical chops to finish a masters degree and then make L7 at Google in just under 8 years, and clearly that doesn't happen without an ability to navigate some level of large org politics.
I will say though, that there is still a good amount of naivete in the reasoning presented. The bottom line is that these generalizations and rationalizations are based on a single vary large company and implicitly dependent on the viewpoint and priorities of a bunch of VPs and executives whose mental model may or may not align with how you see the world in the infra trenches. Now Google is an engineering-driven culture, so the author is probably not too far off, but it also represents a particular time and place. Google has enjoyed one of the strongest and most profitable market positions that was cemented years before he entered the work force, and so there's a level of comfort and sheltered existence that infra teams at most companies do not enjoy. Make hay during the good times, but always be aware leaderships attitudes and priorities can change very quickly due to market or investor pressure, and at that point you need to be ready to adapt and articulate your value in a new environment of greater scrutiny, or to a new company (in the case of layoffs).
That's the dream at a big company for sure. The last mega tech company I worked for had the familiar trap of not knowing how to rate higher level engineers. Things basically turned into a popularity contest, with grading criteria like your "impact on or leadership in the tech community" and other such nonsense.
Quietly making good things and enabling good people to be better is where it is at.
This article resonated a lot with me - I have a 25+ year career and until my most recent role I'd usually switch companies every 2 years.
My current company I'm now on year 4, and 3rd year leading a team building an internal platform for the business - for me it is a dream role - management mostly stay out the way, strategy comes from top down but our team make all the decisions, and after a slow start it's now paying off with several teams using us and helping drive through real requirements, and not the imagined ones from a few execs.
This has lead to constant positive feedback from all of our 'customers' who would never have been able to consider running their own content delivery pipelines - we're solving their real problems. Regardless of any politics, this is what gives me the energy to turn up every day.
I cannot agree more. That’s also why personally I strongly prefer to work on infra rather than product teams. You get so much insulation from random whims of the leadership or PMs and you get simply pursue technical excellence. I don’t want to contribute to “visible ‘wins’ of a product launch” at all. I’m happy that I currently work at a medium-sized company (head count between 1k and 10k) that has been around for 30+ years and my work involves quietly improving the infra used by other teams.
I am not criticizing the author or his opinion in any way. But what he didn’t emphasize enough that yes he might ignore the spotlight as a staff engineer. But he can only do so because he is a staff software engineer.
When I was working at a startup from 2018-2020, I was hired as the second technical hire by then new CTO who was tasked to bring tech leadership into the company from an outside consulting agency where all of the long term developers were in India.
They were constantly seeking the spotlight to insure they kept their jobs. I could afford to not seek the spotlight. I already had the trust of the owners, CTO etc. I had no fear of being made redundant because the right people didn’t know what I contributed.
I wasn’t trying to get a promotion, I was already leading all of the big technical cross functional initiatives as the company grew.
On the other hand, when I got into BigTech in 2020 as an L5 (Professional Services consulting not SDE), I saw for the first time how much politics played in getting ahead. I personally didn’t care. My goal from day 1 was to make money and leave after 4 years. I was already 46 and knew I didn’t want to stay long term.
But I did see how hard it was for a damn good intern I mentored their senior year and when they came back to get noticed. I had to create opportunities for them to get noticed because they were ignored by their manager [1]. They still had to change departments to just get a chance to get on a promotion track.
I see it again on the other side. I would hate to have to play the games and go through the gauntlet to get promoted at the company I work at now and where I was brought in at the staff level.
But I would be chasing after the spotlight with the best of them to get ahead.
I do have the luxury to not chase recognition - everyone who is important already knows me and what I do. My projects automatically give me visibility without my chasing them.
[1] all of the early career people reported to a separate manager and were loaned out to teams.
As a fellow infrastructure and tooling engineer with a long tenure on one team: this tracks.
You do occasionally get to scoop up the rare low-hanging fruit to get a shiny win that all the engineers appreciate; but for the most part it's chill, professional, satisfying work at a pace that leaves you with enough sanity to raise a family.
> Stewardship, staying with a system long-term, unlocks compounding returns that are impossible to achieve on a short rotation.
This is not just true of developer tools, but I think all projects and products.
It's a big problem that many parts of our industry are essentially optimized against this happening.
An observation here that wasn't quite made but in my opinion is supported by the narrative.
If you raise enough capital (whether social or financial) to run for 3 years then you can run for 3 years. If your bets are paying off 2 years in you can stick with the plan - no one will care how you used the capital in year 1 and 2 if there is a payoff in year 3.
The risk comes from being wrong.
Being left alone to build your cathedrals is the dream for me. This seems nice.
Great post. Also a reminder that there isn't one career path for everyone.
The thing that is most interesting to me as someone who works at a devtool company is how this puts a spotlight on what vendors can offer (and what they can't). Every time you integrate a devtool into your product, you are trusting that they've thought out and gone through the deep process work of stewardship.
There are downsides to this approach, however.
If your team is not critical, at least in the eyes of upper-management, then you'll be first on the chopping block in the next downturn.
But if you are critical--say, running critical but unsexy infrastructure--then it's all downside risk with no upside. If things work, they ignore you, but if they mess up, you get the blame and the spotlight.
As with any business/career advice, there are no silver bullets, only trade-offs.
The long-game of quiet impact: context accumulation, trust-building, and systems thinking
This completely matches my experience as an infra principal engineer in a coding archetype at another big company. I do impactful and good technical work and always try to defer credit to those “under” me even if it was my idea they are implementing. As long as my manager knows it was my idea everything works out fine.
That being said you do kind of end up in the spotlight anyways but it feels very different to do it through reputation of knowledge and technical competence rather than through PR-like selling.
You dont have to be at google or zoogle to witness these, even be an engineer.
People are people.
This works until your leadership changes.
>> instead of execs telling us “you should do X”, we figure out what we think will have the most impact to our customers and work on building those features and tools
What could possibly go wrong here?
Ignoring the spotlight is detrimental.
As a person who does consulting work, the best thing I've found I can do is stay visible with my accomplishments.
I did a presentation earlier this year for a client where the CEO was in attendance. I did not know he was going to be there. They were blown away by my presentation.
You make your own luck.
> If I had followed the advice to “optimize for fungibility” (i.e. if I had switched teams in 2023 to chase a new project) Bigtrace would not exist.
Would a PM be responsible for this sort of broader thinking in a more typical team?
Beautifully-written post, full of insights. Thanks for sharing!
You almost shut down my computer，lol
It's easy to write that blogpost when you are in a position of a lot of privilege, in arguably the best software engineering company in the world, and got where you are surely for your competence, but also a high degree of luck.
Some other people has to grind harder and even be better than you to get half of your success, that doesn't mean that they are wrong, or that the book is wrong.
I believe a lot, if not all advice there in the book is necessary. Other people might not work at Google, but as I've said before, might need to grind different gears in order to be successful, if you don't -- good for you!
A lot of your suggestions would get you fired very quickly on many companies, it's good that it all works for you.
[dead]
>spotlight
Literally, who?
I worked closely with a few during my career in a few companies. It is a retirement plan of people who neither can nor want to perform after they "put in time". These days as someone who gets to give my couple of cents to folks in the upper echelons of promising companies I tell the newly minted CTOs to either not hire them or if they are already hired, fire them.
Staff engineer and above = 45 year old soccer player bench warmer getting the pay 22 year old striker.
I get the sense that Lalit wants to do the work and get paid while avoiding the career meta game. The appeal of that is understandable, but having been in this situation in the past, it's not all its cracked up to be.
The number of tech companies where you can stay employed for a solid decade without falling victim to layoffs or re-orgs are very rare in my experience, even more so ones that offer competitive pay.
If you find yourself looking for a new job and want to move up in title and pay, doing the same sort of unglamorous work for years can be a detriment to that.
One thing I’ve learned in my 25+ year career is that if you don't own your narrative and your work, someone else will claim it - especially in corporate America.
I have lost count of the brilliant engineers who were passed over for credit simply because someone less technically capable, but extremely popular, pulled the strings to steal the spotlight.
You don't necessarily need to be in the spotlight, but you do need to leave a paper trail. Claim your work and inventions both internally and externally. You don't need to be a 'LinkedIn thought leader' to do this, just submit talks to conferences and find peers at other companies who understand the difference between those who build and those who only talk about building.