14 ms·

I ignore the spotlight as a staff engineer

547 points by todsacerdoti 11mo ago

chrisweekly 11mo ago
Beautifully-written post, full of insights. Thanks for sharing!
beernet 11mo ago
>> 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?
- 0x696C6961 11mo ago
  The same things that go wrong anyway?
- sd9 11mo ago
  What do you mean? The quoted text is the exact strategy I always use. I don't want or need to be told top down what to do, it's better to think for myself and propose that upward. Execs appreciate it because it makes their jobs easier; users get the features they actually want; I get to work on what I think is important. What am I missing that makes this a bad strategy?
  - wordpad 11mo ago
    If your proposal doesn't align with leadership vision or the product they want to grow...
    - sd9 11mo ago
      Well you factor that in too? And be willing to change focus if that's the feedback.
    - bluGill 11mo ago
      This can still be okay - but you have to be correct in a way that the company values. This of course needs to be without doing something against the rest of the company - either legally or sabotaging some other product are both out. Values is most commonly money, but there are other things the company values at times..
    - orwin 11mo ago
      In my experience (I make tools for the network and security guys): that's why you don't propose only one thing. We often have one new project every year, we propose multiple ways to go about it, the leadership ask us to explore 2-3 solutions, we come back with data and propose our preferred solution, the leadership say 'ok' (after a very technical two-hour meeting) and propose minor alterations (or sometimes they want to alter our database design to make it 'closer' to the user experience...)
  - qznc 11mo ago
    I think this is the most efficient approach. Decisions should be made at the lowest possible level of the org chart. However, it has an important assumption: You are sufficiently aware of higher level things. If you have a decent communication culture in your company or if you are around long enough to know someone everywhere, it should be fine though.
  - beernet 11mo ago
    More often than not, things don't turn out too well if engineers decide what to build without tight steering from customers and/or upper management. This is exactly what it sounds like here. Tech for the purpose of tech. I understand this is HN and we have a pro-engineering bias here, at the same time, engineers don't tend to be the greatest strategists.
    - deleted 11mo ago
      [deleted]
    - sd9 11mo ago
      Customers and management should always be part of the loop. This is reflected in the original quote and my comment. I just think that having to be micromanaged from the top down is completely miserable, is worse for the customer, and is time consuming for execs. It’s not a way to live. You as an engineer should be familiar with users’ needs. I got into this field because I love automating solutions that help users solve their problems. So of course I want to know what they’re doing, and have a good idea of what would improve their lives further.
    - tayo42 11mo ago
      The article was about how he doesn't work on a product team and only builds internal tools for other coworkers and doesn't need all of that overhead
- flohofwoe 11mo ago
  Nothing, except maybe an asteroid hitting the building and wiping out the entire team?
zdragnar 11mo ago
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.
- zwnow 11mo ago
  As long as quietly making stuff pays off, sure. If I get a bigger paycheck just from being known by the higher ups I'll go for the popularity contest. People work to feed themselves and their families after all and considering how unethical big tech is, I dont think anything u work on could do anything to better the world. So yeah, popularity contest and doing as little work as possible it is.
  - lotsofpulp 11mo ago
    > People work to feed themselves and their families after all and considering how unethical big tech is, I dont think anything u work on could do anything to better the world. A little hyperbolic. Members of my family have found great utility in accessibility improvements, language translation, video calling, navigation assistance, etc.
    - zwnow 11mo ago
      Yea all that is neat if all that data wouldn't be collected and sold by all these big tech companies.
- ownagefool 11mo ago
  The thing about your bigco, the OPs and the post he's talking about, is it's all so abstract from money. You have two poles here. 1. The VC route, strikes gold, and never really needs to live with the reality of asking what an ROI is, it's all talk about spotlight, impact and value, without any articulation about cash money. 2. The MBA route where you effectively can't brush your teeth without a cost/benefit analysis that itself often cost multiple times your initiative, resulting in nothing getting done until you're in some tech debt armageddon. The reality is if you're still making bank on the abstract without being able to articulate revenue or costs, you're probably still in the good times.
etothepii 11mo ago
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.
- lalitmaganti 11mo ago
  > The risk comes from being wrong. It's definitely a high risk high reward strategy but if you have the context from being the space for years and you've done your due diligence by speaking to your customers before you build things, you reduce the risk significantly. Of course the risk can never be zero though and luck definitely played a role in past successes.
- bluGill 11mo ago
  There is another risk: you run for 2 years and prevent a major problem that would bite the company in year 3 or 4. However because the problem never happened nobody knows how much you saved everyone and so you don't replace all that capital you used up. Every company I've worked for has regular meetings where they honor the people who stayed late to get the release out the door (I work in embedded systems where upgrades often mean flying someone with a USB stick to a remote location without cell service - thus bug free releases are important since upgrades are expensive). I can't help thinking every time that if the rewarded person had just done their job 6 months ago they wouldn't have had the bug in the first place.
  - potato3732842 11mo ago
    Everyone says the thing they're working on is critically important. Who's right? More work gets done for less if you wait until the 11th hour and fix the real problems last minute rather than fix everything ahead of time, much of which will turn out to not have needed fixing. Yeah there's risks involved but at the limit it makes some sense.
    - 11mo ago
LinuxAmbulance 11mo ago
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.
- lalitmaganti 11mo ago
  It's not that I want to avoid the career metagame (I would argue I haven't so far) but that the career metagame is different depending on your environment.
  - class3shock 11mo ago
    I know this is off topic but if you ever have the inclination to write about it, I would be really interested in reading about any books, people, experiences, professional lessons learned, etc. that have been helpful to you on progressing along a non-spotlight technical focused engineering path. I'm in a different domain (aerospace) but am trying to carve out a similar career path and am always looking for more to learn about just being a good engineer.
    - lalitmaganti 11mo ago
      > if you ever have the inclination to write about it I definitely plan on writing a lot more about this in the coming months :) After seeing Sean's own posts and the fact this post resonated, it feels like there are people out there who might be interested in this sort of thing :) > books, people, experiences, professional lessons learned Books not so much but one thing i've been very fortunate to have is very good mentors I can learn off. I've had the same manager from when I first joined Google and honestly I've learned so much just from watching him work and interact with people. Also a couple of senior directors/engineers in other teams as well who I always make a habit to catch up with. If you're interested, stay tuned to the blog :)
thiago_fm 11mo ago
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.
- lalitmaganti 11mo ago
  My goal with this post was not to claim this is a universal template to success for everyone but simply sharing an approach that worked for me. I tried to point out several times that, yes there are places where a "move fast with leadership" approach works better. And yes this only works in the biggest companies capable of sustaining an infra team for a long period of time.
- bluGill 11mo ago
  There are staff level jobs like that in every company. However they are hard to get into. You have to prove yourself constantly and for long enough that the executives trust they can leave you alone and you will solve problems. You here means your team, as a staff engineer you likely have a lot of more junior engineers working under you.
- swaits 11mo ago
  It’s not luck. To assume so, let alone say so, is uninformed and quite rude. Getting into these roles requires a ton of hard work. Yes, it’s a grind. If you feel it’s only achievable with luck, I suggest you’re selling yourself short.
  - WhyOhWhyQ 11mo ago
    It is a large amount of luck, obviously. You didn't hard-work your way out of brain damage at birth. You didn't hard-work your way into your geographic location which gave you access to the resources that lead you to where you are, which are unavailable most places in the world. You didn't hard-work your way out of avoiding a draft for a war where you got killed at age 18.
eutropia 11mo ago
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.
bonsai_spool 11mo ago
> 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?
- lalitmaganti 11mo ago
  > Would a PM be responsible for this sort of broader thinking in a more typical team? Good PMs do exactly this in product teams yes. But unfortunately PMs are not immune to shifting priorities and moving around either, just like I describe for engineers. So it's very hard to make it work but the best PMs I know somehow manage anyway!
- mh2266 11mo ago
  It’s a little snarky and cynical but I’ve found little use for product managers in infra and devx teams because they typically don’t have the technical background to have relevant product vision and anyone that can make L7+ as an engineer on this sort of team should be able to figure out what the product should be. This is different in a product team because engineers aren’t the customers, although I’d still argue anyone senior in a product engineering team should still have at least some product sense.
sebstefan 11mo ago
Being left alone to build your cathedrals is the dream for me. This seems nice.
- bluGill 11mo ago
  You are only left alone if your cathedrals generate enough value while being ignored. The post is about a tools team, so long as the tools work and nobody comes selling a "cheaper tool that solves everything" management doesn't care and you get to work. However if you tools start causing problems for the engineers who use them and the complain to management you are in trouble. If someone else comes along with a "cheaper tool that solves everything" you are in trouble (such tool may or may not be cheaper/better, the point is they can sell management on the idea they are - you didn't successfully defend yours) Edit: there is one more danger: you do your job well and management thinks you do nothing and so gets rid of you (only to hire a new team in 3 months when everything collapses)
spinity 11mo ago
You almost shut down my computer，lol
kccqzy 11mo ago
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.
notyourday 11mo ago
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.
- giuscri 11mo ago
  so what one should do after a certain age?
  - notyourday 11mo ago
    Continue to perform or live off the savings.
    - giuscri 11mo ago
      Well you said you’d fire them/not hire them at all. No benefit of doubt
      - notyourday 11mo ago
        Correct. To get to the staff engineer level you probably spent at least 10 years in the industry making gobs of money. You did save some, right? Right?
- sakopov 11mo ago
  So you suggest firing people based on their title alone? Sounds pretty damn stupid.
  - notyourday 11mo ago
    > So you suggest firing people based on their title alone? Sounds pretty damn stupid. You can look through the threads in this comment section and in other comment sections of threads that touched on Staff Engineers and Senior staff engineers. People perfectly illustrate why the companies would do well firing them - people describe that as their dream "retirement" job. Yes, I suggest firing every single one of them. They are non-performing group eating enormous compensation packages.
grimpy 11mo ago
This works until your leadership changes.
moralestapia 11mo ago
>spotlight Literally, who?
dasil003 11mo ago
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).
- thundergolfer 11mo ago
  Did you read the full post? The author addressed these points at the end. They’re not naive.
- lalitmaganti 11mo ago
  I'm very well aware of the privilege afforded to me by my company and the time I'm working in. I tried to emphasize in the post several times that this is not a "universal guide to success" and that in other companies or teams, a different approach and strategy might be needed. The whole reason I wrote this post at all was, with the success of Sean's work on HN recently, I felt people were leaning too far into the direction of "you need to constantly move around and go where the exec attention is". I just wanted to show that, from my singular experience, it is possible to carve out a different path in some positions while still being ambitious and "successful" (for some definition of success).
postit 11mo ago
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.
- proc0 11mo ago
  This is one of the main reasons I'm trying to pivot away from a career inside a corporate environment. There is too much politics. I wish it was just do the work and go home, and get rewarded for the work that was completed, but instead there is a huge self-promotion (as in marketing) component. If that's what it takes I might as well do something that I own and control. If I'm going to need to worry about how to market my own work then I might as well try and at least not have a boss. I always thought the point of being an employee and having a limited paycheck meant that you don't worry about this things. That's the fair tradeoff.
  - jeffwass 11mo ago
    To be fair, this issue isn’t endemic only to big companies. I’ve seen similar even in academia, some people just know how to “play the game” and play it very well. It really depends on the culture of where you are, which can even vary team by team in the same org.
    - shermantanktop 11mo ago
      Some people seem willfully ignorant of the game. When confronted with the reality of it, they turn away, complain that it exists, and act like a bullied middle schooler. You don’t have to enthusiastically endorse the game. You can learn it, just like you learn Go or Rust or whatever. You can refuse to actively play it, but also be aware of it enough to avoid getting hurt by it. E.g. figure out the minimal effort for convincing game players that your work is important.
123sereusername 11mo ago
[dead]
trjordan 11mo ago
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.
- TimByte 11mo ago
  I've seen the same dynamics play out at mid-sized companies
- Quothling 11mo ago
  I agree with the author in regards to it being different career paths, but I think your take is better and more nuanced. I've done both. I started my career being a spotlight engineer, quickly advancing the ranks and being sent on a educational path for leadership. I didn't like it though. Don't get me wrong. I basked in the glory for the first year, but then when it got to be just a regular day, I really started to miss solving what I see as interesting problems. Which is often working on stability and safety, building tools and infrastructure which makes it easier for other people to serve the business. Maybe it's because I've done the spotlight thing, but I don't really care about praise from management anymore. In fact I suspect that most of my direct managers have never really known what I did, but since they've seen the impact for other people, it's not really been an issue in regards to my reviews or pay. I don't get a lot of credit and I don't get a lot of praise. I don't necessarily see someone who's build a great product with the tools I've made as stealing my credit either. That's sort of the point of what I do. I completely agree with you that this is not just Big Tech, or Enterprise or even in organisations that are focused on Tech. I also agree that it's not about ignoring the business, you're still going to want to build things that are useful. You're still going to do change management from the ground up to make sure people know the tools are useful and how to use them. You're still going to network and be friendly with your co-workers. What you can skip is a lot of the corporate politics and frankly most of the "financial" information. I don't even think the price is very high, you don't get the publicity, but it's not like spotlight engineers necessarily get better pay or better career paths unless they want to go into management.
tanepiper 11mo ago
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.
- TimByte 11mo ago
  That kind of bottom-up traction feels rare, but when it happens, it's incredibly energizing
TimByte 11mo ago
The long-game of quiet impact: context accumulation, trust-building, and systems thinking
GMoromisato 11mo ago
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.
mh2266 11mo ago
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.
dbacar 11mo ago
You dont have to be at google or zoogle to witness these, even be an engineer. People are people.
froggertoaster 11mo ago
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.
raw_anon_1111 11mo ago
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.
- lalitmaganti 11mo ago
  > But he can only do so because he is a staff software engineer. I don't agree with this at all. This is how I've worked for my entire time at Google, all the way from new grad L3 joining the company till today. Ignoring the spotlight does not mean "don't get attention from other people" but "don't chase the project execs are focusing on". Whenever I've work on a project, I make a very active effort to make sure engineers are aware of it, especially if I think they would find it useful. But that's different than going to my execs and asking "what's the highest priority at the moment" and working on that.
jrochkind1 11mo ago
> 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.
mooreds 11mo ago
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.
rconti 11mo ago
Can confirm. I've worked on infra teams for decades, at companies from 80-80,000 people, and I don't think I've _ever_ had a PM on a project I worked on. EDIT: Note, this is not _necessarily_ a complaint, although I think they would have been very helpful in some circumstances. My main misgivings in working with PM orgs is when they treat my projects as a necessary evil input to the success of the projects they care about. So you get all of the hectoring and demands of professional management with none of the help.
nitwit005 11mo ago
Google is an unusual environment for internal tools. A lot of companies will build things, and then starve them of funding and engineers, as they aren't part of any of the top company priorities. This often means building tools comes with a penalty. People will keep reaching out to you for help, because there is no one else.
- alephnerd 11mo ago
  Priorities only become priorities because people fought for them to become priorities. You can fight that battle via significant self promotion, but you can also lobby for yourself by keeping in constant contact with a subset of stakeholders who actually matter (your manager, your skip manager, your PM, your PM's manager, and maybe 1-2 adjacent EMs). And honestly, the latter is the norm and much easier as well simply because it ensures that other people are fighting your battle.
  - nitwit005 11mo ago
    Well, no, the priorities are often whatever the CEO thinks they are right now. People have to be open to being convinced. It'd be nice if that was always true, but it's clearly not always the case.
    - alephnerd 11mo ago
      > Well, no, the priorities are often whatever the CEO thinks they are right now... They are not, and I say this as someone who has reported to people who reported to CEOs and now has CEOs "report" to me. In most cases, Executive Leadership Teams largely depend on upper-mid level management as their primary filters for initiatives (think VPs/SVPs) and those members of management depend on mid-level management (Engineering Directors, Engineering Managers, Principal/Staff Engineers, and IC Product Managers). If you are an IC Engineer and actually want to make something you care about a priority, you need to: 1. Convince your manager (usually an EM) and skip manager (usually an Engineering Director) and your PM to fight for you. 2. Think about how to show that an engineering initiative actually has a positive impact on ARR or COGS. 3. Find a way to craft an argument around how your proposal aligns with an OKR - OKRs are purposely made open-ended in order to act as a soft filter. > People have to be open to being convinced... Yes, but you also need to be able to convince them in their language. You have to be able to understand every individual's incentives and then explain how your proposal aligns with their incentives. ------------ The amount of learned helplessness on HN is counterproductive for anyone hoping to maintain a career over the long term.
nsxwolf 11mo ago
There's also another path to staying out of the spotlight - when you've been under the spotlight a couple times and got no reward at all from it.
GrumpyGoblin 11mo ago
Meh. Good article but not sure it's globally relevant. Spotlight is about personality. Some people are visible, outspoken, and in the spotlight, and impactful. Others are quiet, subdued, behind the scenes but impactful. Some of the best developers I've known have been on either end of the spectrum. At the end of the day it's about impact. When the quiet guy gets the job done every time, people still notice. When the loud guy doesn't, people notice even more. Sure, there are cases where one guy screams from the mountaintops about how much he has done and gets promoted. And there are cases where the quiet guy gets passed over no matter how well he does. But these always wash in the end unless you work for a supremely shitty company. And even then they tend to work themselves out in life eventually. Even if it sucks for the people involved at the time. Impact is the name of the game. Loud or quiet is irrelevant.
striglia 11mo ago
I find this infra perspective so fascinating, as a career-long product platform engineer and solidly staff+. I don't argue that sean's writing (which is amazing) is a little overly mercenary in framing, but I'll pick a few choice sections I don't agree with here too. tldr I think the "product cares about speed; infra cares about leverage" staff engineer archetype is a false dichotomy we shouldn't encourage. "In the product environments Sean describes, where goals pivot quarterly and features are often experimental, speed is the ultimate currency. You need to ship, iterate, and often move on before the market shifts." -- I disagree that speed is the ultimate currency! A great product org also respects long term leverage, it's just _always_ harder to argue for. But it's best to build a strong portfolio of going fast (where needed), going slow (where high leverage), and if everyone agrees your "going slow" led to huge returns you get the best of all worlds. Frankly it's a sign of a relatively junior product engineer if they are myopically focused on speed at the cost of all else. "But the more powerful return is systemic innovation. If you rotate teams every year, you are limited to solving acute bugs that are visible right now. Some problems, however, only reveal their shape over long horizons." -- Extremely true, and this is _equally or more true_ in product domains. My most valuable contributions have come from sitting in a product area long enough to generalize 5 micro optimizations into the macro engineering leverage we needed to drive an order of magnitude more value from the same engineering input. "For some engineers, navigating this [high visibility driven] chaos is a thrill. For those of us who care about system stability, it feels like a trap." -- my protip for prospective staff engineers is to _never_ say you only care about [speed, stability]. In most cases you must care about both, and it's worth advertising yourself as such. If you self select out of companies that only care about [pure stability/pure ship velocity] there should be a valuable balance to strike and staff engineers are in a unique place to enshrine that balance in engineered systems. "In a product organization, you often need to impress your manager’s manager. In an infrastructure organization, you need to impress your customers’ managers." -- surely we can agree impressing customer stakeholders is even more important in (healthy) product orgs :) But it's a curious claim! Great article, wonderful to hear more nuanced and deep discussion of the practice of extremely senior IC engineering. Kudos!
- lalitmaganti 11mo ago
  Firstly, thanks for the thoughtful comments across the post. Really happy you found it insightful! > But it's best to build a strong portfolio of going fast (where needed), going slow (where high leverage), and if everyone agrees your "going slow" led to huge returns you get the best of all worlds. I guess maybe I oversold this a little in the post but I definitely think that product orgs value speed more than infra orgs: there's often an mismatch when I speak to product engineers on how fast they expect us to build things for them vs how fast we can actually go while considering all our other customers and not breaking other usecases. > my protip for prospective staff engineers is to _never_ say you only care about [speed, stability] Fully agreed, both are important for engineers to have. As above, I think the relative composition of them varies though depending on the area (just pulling numbers from the top of my head, maybe it's 70/30 in favor of speed in product orgs, 30/70 in favor of stability in infra orgs). > surely we can agree impressing customer stakeholders is even more important in (healthy) product orgs You're absolutely right for what I say in the post; reflecting I think I maybe did not go into this topic in enough detail for the nuance it deserves (but the post already felt long enough!). Let's split the discussion into 3 different areas (as IMO they each work slightly different): infra/devex, B2C and B2B. * Infra/devex: as I say in the post, it's critical to impress your other team's managers as that's how you prove impact. * B2C: your customers are consumers so it's all MAUs, revenue etc. There is no "customer stakeholder" who will give you direct feedback for your promo packet * B2B: here's where it gets interesting. So if your management chain is directly able to talk to customers (and especially senior managers) to solicit feedback without middle layers (parter manager, account managers, PMs) then yes you're absolutely correct. But often this is not the case: the middle layers act as a filtering point so you get only a fuzzy sense of how stakeholders in the other company about a specific technical thing you worked on. So again it's sort of at the whim of how your manager feels the other company's managers feels. The basic point I was trying to make is that if you're working on external facing product, from my understanding, even if you impress your external stakeholders, it's not like in your promo packet you can attribute concrete quotes to the customers. quotes like "we couldn't have done X in our company without the work of Y engineer in your org who worked on Z". Whereas this sort of quote is extremely common to see in infra promo packets. Hope this made sense, I'm not sure I communicated this last point well!
diebold 11mo ago
[flagged]
diebold 11mo ago
[flagged]
vcbueger 11mo ago
My voice will likely get lost in the wilderness, but I think it’s a bad sign if you have to write or vibe a whole post like this to defend your worth against another engineer. I understand from a good chunk of my career that the person on the team that promotes themself and/or has the highest charisma and is adequately intelligent will exceed over others on the team that may work harder, have more experience, and/or is doing more important work for the business. But it doesn’t mean that you have to ladder climb and play the game to get what you deserve. You can, and maybe can make more money and survive longer that way. More important than that though is to be yourself. Don’t spend all that time promoting yourself just to make the world a shittier place, so that you get the nice house and car with the kids at the best school, etc. It’s ok to be stepped over while you actually do your job, and for you to feel like shit and maybe be jaded a bit because some asshole that doesn’t deserve it is getting the spotlight. Someone needs to be the Woz. (That’s not a slight against Jobs, btw.)
huflungdung 11mo ago
[dead]

547 points by todsacerdoti 11mo ago

Beautifully-written post, full of insights. Thanks for sharing!

>> 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?

0x696C6961 11mo ago
The same things that go wrong anyway?
sd9 11mo ago
What do you mean? The quoted text is the exact strategy I always use. I don't want or need to be told top down what to do, it's better to think for myself and propose that upward. Execs appreciate it because it makes their jobs easier; users get the features they actually want; I get to work on what I think is important. What am I missing that makes this a bad strategy?
- wordpad 11mo ago
  If your proposal doesn't align with leadership vision or the product they want to grow...
  - sd9 11mo ago
    Well you factor that in too? And be willing to change focus if that's the feedback.
  - bluGill 11mo ago
    This can still be okay - but you have to be correct in a way that the company values. This of course needs to be without doing something against the rest of the company - either legally or sabotaging some other product are both out. Values is most commonly money, but there are other things the company values at times..
  - orwin 11mo ago
    In my experience (I make tools for the network and security guys): that's why you don't propose only one thing. We often have one new project every year, we propose multiple ways to go about it, the leadership ask us to explore 2-3 solutions, we come back with data and propose our preferred solution, the leadership say 'ok' (after a very technical two-hour meeting) and propose minor alterations (or sometimes they want to alter our database design to make it 'closer' to the user experience...)
- qznc 11mo ago
  I think this is the most efficient approach. Decisions should be made at the lowest possible level of the org chart. However, it has an important assumption: You are sufficiently aware of higher level things. If you have a decent communication culture in your company or if you are around long enough to know someone everywhere, it should be fine though.
- beernet 11mo ago
  More often than not, things don't turn out too well if engineers decide what to build without tight steering from customers and/or upper management. This is exactly what it sounds like here. Tech for the purpose of tech. I understand this is HN and we have a pro-engineering bias here, at the same time, engineers don't tend to be the greatest strategists.
  - deleted 11mo ago
    [deleted]
  - sd9 11mo ago
    Customers and management should always be part of the loop. This is reflected in the original quote and my comment. I just think that having to be micromanaged from the top down is completely miserable, is worse for the customer, and is time consuming for execs. It’s not a way to live. You as an engineer should be familiar with users’ needs. I got into this field because I love automating solutions that help users solve their problems. So of course I want to know what they’re doing, and have a good idea of what would improve their lives further.
  - tayo42 11mo ago
    The article was about how he doesn't work on a product team and only builds internal tools for other coworkers and doesn't need all of that overhead
flohofwoe 11mo ago
Nothing, except maybe an asteroid hitting the building and wiping out the entire team?

zdragnar 11mo ago

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.

zwnow 11mo ago
As long as quietly making stuff pays off, sure. If I get a bigger paycheck just from being known by the higher ups I'll go for the popularity contest. People work to feed themselves and their families after all and considering how unethical big tech is, I dont think anything u work on could do anything to better the world. So yeah, popularity contest and doing as little work as possible it is.
- lotsofpulp 11mo ago
  > People work to feed themselves and their families after all and considering how unethical big tech is, I dont think anything u work on could do anything to better the world. A little hyperbolic. Members of my family have found great utility in accessibility improvements, language translation, video calling, navigation assistance, etc.
  - zwnow 11mo ago
    Yea all that is neat if all that data wouldn't be collected and sold by all these big tech companies.
ownagefool 11mo ago
The thing about your bigco, the OPs and the post he's talking about, is it's all so abstract from money. You have two poles here. 1. The VC route, strikes gold, and never really needs to live with the reality of asking what an ROI is, it's all talk about spotlight, impact and value, without any articulation about cash money. 2. The MBA route where you effectively can't brush your teeth without a cost/benefit analysis that itself often cost multiple times your initiative, resulting in nothing getting done until you're in some tech debt armageddon. The reality is if you're still making bank on the abstract without being able to articulate revenue or costs, you're probably still in the good times.

etothepii 11mo ago

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.

lalitmaganti 11mo ago
> The risk comes from being wrong. It's definitely a high risk high reward strategy but if you have the context from being the space for years and you've done your due diligence by speaking to your customers before you build things, you reduce the risk significantly. Of course the risk can never be zero though and luck definitely played a role in past successes.
bluGill 11mo ago
There is another risk: you run for 2 years and prevent a major problem that would bite the company in year 3 or 4. However because the problem never happened nobody knows how much you saved everyone and so you don't replace all that capital you used up. Every company I've worked for has regular meetings where they honor the people who stayed late to get the release out the door (I work in embedded systems where upgrades often mean flying someone with a USB stick to a remote location without cell service - thus bug free releases are important since upgrades are expensive). I can't help thinking every time that if the rewarded person had just done their job 6 months ago they wouldn't have had the bug in the first place.
- potato3732842 11mo ago
  Everyone says the thing they're working on is critically important. Who's right? More work gets done for less if you wait until the 11th hour and fix the real problems last minute rather than fix everything ahead of time, much of which will turn out to not have needed fixing. Yeah there's risks involved but at the limit it makes some sense.
  - 11mo ago

LinuxAmbulance 11mo ago

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.

lalitmaganti 11mo ago
It's not that I want to avoid the career metagame (I would argue I haven't so far) but that the career metagame is different depending on your environment.
- class3shock 11mo ago
  I know this is off topic but if you ever have the inclination to write about it, I would be really interested in reading about any books, people, experiences, professional lessons learned, etc. that have been helpful to you on progressing along a non-spotlight technical focused engineering path. I'm in a different domain (aerospace) but am trying to carve out a similar career path and am always looking for more to learn about just being a good engineer.
  - lalitmaganti 11mo ago
    > if you ever have the inclination to write about it I definitely plan on writing a lot more about this in the coming months :) After seeing Sean's own posts and the fact this post resonated, it feels like there are people out there who might be interested in this sort of thing :) > books, people, experiences, professional lessons learned Books not so much but one thing i've been very fortunate to have is very good mentors I can learn off. I've had the same manager from when I first joined Google and honestly I've learned so much just from watching him work and interact with people. Also a couple of senior directors/engineers in other teams as well who I always make a habit to catch up with. If you're interested, stay tuned to the blog :)

thiago_fm 11mo ago

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.

lalitmaganti 11mo ago
My goal with this post was not to claim this is a universal template to success for everyone but simply sharing an approach that worked for me. I tried to point out several times that, yes there are places where a "move fast with leadership" approach works better. And yes this only works in the biggest companies capable of sustaining an infra team for a long period of time.
bluGill 11mo ago
There are staff level jobs like that in every company. However they are hard to get into. You have to prove yourself constantly and for long enough that the executives trust they can leave you alone and you will solve problems. You here means your team, as a staff engineer you likely have a lot of more junior engineers working under you.
swaits 11mo ago
It’s not luck. To assume so, let alone say so, is uninformed and quite rude. Getting into these roles requires a ton of hard work. Yes, it’s a grind. If you feel it’s only achievable with luck, I suggest you’re selling yourself short.
- WhyOhWhyQ 11mo ago
  It is a large amount of luck, obviously. You didn't hard-work your way out of brain damage at birth. You didn't hard-work your way into your geographic location which gave you access to the resources that lead you to where you are, which are unavailable most places in the world. You didn't hard-work your way out of avoiding a draft for a war where you got killed at age 18.

eutropia 11mo ago

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.

bonsai_spool 11mo ago

> 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?

lalitmaganti 11mo ago
> Would a PM be responsible for this sort of broader thinking in a more typical team? Good PMs do exactly this in product teams yes. But unfortunately PMs are not immune to shifting priorities and moving around either, just like I describe for engineers. So it's very hard to make it work but the best PMs I know somehow manage anyway!
mh2266 11mo ago
It’s a little snarky and cynical but I’ve found little use for product managers in infra and devx teams because they typically don’t have the technical background to have relevant product vision and anyone that can make L7+ as an engineer on this sort of team should be able to figure out what the product should be. This is different in a product team because engineers aren’t the customers, although I’d still argue anyone senior in a product engineering team should still have at least some product sense.

sebstefan 11mo ago

Being left alone to build your cathedrals is the dream for me. This seems nice.

bluGill 11mo ago
You are only left alone if your cathedrals generate enough value while being ignored. The post is about a tools team, so long as the tools work and nobody comes selling a "cheaper tool that solves everything" management doesn't care and you get to work. However if you tools start causing problems for the engineers who use them and the complain to management you are in trouble. If someone else comes along with a "cheaper tool that solves everything" you are in trouble (such tool may or may not be cheaper/better, the point is they can sell management on the idea they are - you didn't successfully defend yours) Edit: there is one more danger: you do your job well and management thinks you do nothing and so gets rid of you (only to hire a new team in 3 months when everything collapses)

spinity 11mo ago

You almost shut down my computer，lol

kccqzy 11mo ago

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.

notyourday 11mo ago

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.

giuscri 11mo ago
so what one should do after a certain age?
- notyourday 11mo ago
  Continue to perform or live off the savings.
  - giuscri 11mo ago
    Well you said you’d fire them/not hire them at all. No benefit of doubt
    - notyourday 11mo ago
      Correct. To get to the staff engineer level you probably spent at least 10 years in the industry making gobs of money. You did save some, right? Right?
sakopov 11mo ago
So you suggest firing people based on their title alone? Sounds pretty damn stupid.
- notyourday 11mo ago
  > So you suggest firing people based on their title alone? Sounds pretty damn stupid. You can look through the threads in this comment section and in other comment sections of threads that touched on Staff Engineers and Senior staff engineers. People perfectly illustrate why the companies would do well firing them - people describe that as their dream "retirement" job. Yes, I suggest firing every single one of them. They are non-performing group eating enormous compensation packages.

grimpy 11mo ago

This works until your leadership changes.

moralestapia 11mo ago

>spotlight Literally, who?

dasil003 11mo ago

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).

thundergolfer 11mo ago
Did you read the full post? The author addressed these points at the end. They’re not naive.
lalitmaganti 11mo ago
I'm very well aware of the privilege afforded to me by my company and the time I'm working in. I tried to emphasize in the post several times that this is not a "universal guide to success" and that in other companies or teams, a different approach and strategy might be needed. The whole reason I wrote this post at all was, with the success of Sean's work on HN recently, I felt people were leaning too far into the direction of "you need to constantly move around and go where the exec attention is". I just wanted to show that, from my singular experience, it is possible to carve out a different path in some positions while still being ambitious and "successful" (for some definition of success).

postit 11mo ago

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.

proc0 11mo ago
This is one of the main reasons I'm trying to pivot away from a career inside a corporate environment. There is too much politics. I wish it was just do the work and go home, and get rewarded for the work that was completed, but instead there is a huge self-promotion (as in marketing) component. If that's what it takes I might as well do something that I own and control. If I'm going to need to worry about how to market my own work then I might as well try and at least not have a boss. I always thought the point of being an employee and having a limited paycheck meant that you don't worry about this things. That's the fair tradeoff.
- jeffwass 11mo ago
  To be fair, this issue isn’t endemic only to big companies. I’ve seen similar even in academia, some people just know how to “play the game” and play it very well. It really depends on the culture of where you are, which can even vary team by team in the same org.
  - shermantanktop 11mo ago
    Some people seem willfully ignorant of the game. When confronted with the reality of it, they turn away, complain that it exists, and act like a bullied middle schooler. You don’t have to enthusiastically endorse the game. You can learn it, just like you learn Go or Rust or whatever. You can refuse to actively play it, but also be aware of it enough to avoid getting hurt by it. E.g. figure out the minimal effort for convincing game players that your work is important.

123sereusername 11mo ago

[dead]

trjordan 11mo ago

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.

TimByte 11mo ago
I've seen the same dynamics play out at mid-sized companies
Quothling 11mo ago
I agree with the author in regards to it being different career paths, but I think your take is better and more nuanced. I've done both. I started my career being a spotlight engineer, quickly advancing the ranks and being sent on a educational path for leadership. I didn't like it though. Don't get me wrong. I basked in the glory for the first year, but then when it got to be just a regular day, I really started to miss solving what I see as interesting problems. Which is often working on stability and safety, building tools and infrastructure which makes it easier for other people to serve the business. Maybe it's because I've done the spotlight thing, but I don't really care about praise from management anymore. In fact I suspect that most of my direct managers have never really known what I did, but since they've seen the impact for other people, it's not really been an issue in regards to my reviews or pay. I don't get a lot of credit and I don't get a lot of praise. I don't necessarily see someone who's build a great product with the tools I've made as stealing my credit either. That's sort of the point of what I do. I completely agree with you that this is not just Big Tech, or Enterprise or even in organisations that are focused on Tech. I also agree that it's not about ignoring the business, you're still going to want to build things that are useful. You're still going to do change management from the ground up to make sure people know the tools are useful and how to use them. You're still going to network and be friendly with your co-workers. What you can skip is a lot of the corporate politics and frankly most of the "financial" information. I don't even think the price is very high, you don't get the publicity, but it's not like spotlight engineers necessarily get better pay or better career paths unless they want to go into management.

tanepiper 11mo ago

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.

TimByte 11mo ago
That kind of bottom-up traction feels rare, but when it happens, it's incredibly energizing

TimByte 11mo ago

The long-game of quiet impact: context accumulation, trust-building, and systems thinking

GMoromisato 11mo ago

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.

mh2266 11mo ago

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.

dbacar 11mo ago

You dont have to be at google or zoogle to witness these, even be an engineer. People are people.

froggertoaster 11mo ago

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.

raw_anon_1111 11mo ago

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.

lalitmaganti 11mo ago
> But he can only do so because he is a staff software engineer. I don't agree with this at all. This is how I've worked for my entire time at Google, all the way from new grad L3 joining the company till today. Ignoring the spotlight does not mean "don't get attention from other people" but "don't chase the project execs are focusing on". Whenever I've work on a project, I make a very active effort to make sure engineers are aware of it, especially if I think they would find it useful. But that's different than going to my execs and asking "what's the highest priority at the moment" and working on that.

jrochkind1 11mo ago

> 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.

mooreds 11mo ago

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.

rconti 11mo ago

Can confirm. I've worked on infra teams for decades, at companies from 80-80,000 people, and I don't think I've _ever_ had a PM on a project I worked on. EDIT: Note, this is not _necessarily_ a complaint, although I think they would have been very helpful in some circumstances. My main misgivings in working with PM orgs is when they treat my projects as a necessary evil input to the success of the projects they care about. So you get all of the hectoring and demands of professional management with none of the help.

nitwit005 11mo ago

Google is an unusual environment for internal tools. A lot of companies will build things, and then starve them of funding and engineers, as they aren't part of any of the top company priorities. This often means building tools comes with a penalty. People will keep reaching out to you for help, because there is no one else.

alephnerd 11mo ago
Priorities only become priorities because people fought for them to become priorities. You can fight that battle via significant self promotion, but you can also lobby for yourself by keeping in constant contact with a subset of stakeholders who actually matter (your manager, your skip manager, your PM, your PM's manager, and maybe 1-2 adjacent EMs). And honestly, the latter is the norm and much easier as well simply because it ensures that other people are fighting your battle.
- nitwit005 11mo ago
  Well, no, the priorities are often whatever the CEO thinks they are right now. People have to be open to being convinced. It'd be nice if that was always true, but it's clearly not always the case.
  - alephnerd 11mo ago
    > Well, no, the priorities are often whatever the CEO thinks they are right now... They are not, and I say this as someone who has reported to people who reported to CEOs and now has CEOs "report" to me. In most cases, Executive Leadership Teams largely depend on upper-mid level management as their primary filters for initiatives (think VPs/SVPs) and those members of management depend on mid-level management (Engineering Directors, Engineering Managers, Principal/Staff Engineers, and IC Product Managers). If you are an IC Engineer and actually want to make something you care about a priority, you need to: 1. Convince your manager (usually an EM) and skip manager (usually an Engineering Director) and your PM to fight for you. 2. Think about how to show that an engineering initiative actually has a positive impact on ARR or COGS. 3. Find a way to craft an argument around how your proposal aligns with an OKR - OKRs are purposely made open-ended in order to act as a soft filter. > People have to be open to being convinced... Yes, but you also need to be able to convince them in their language. You have to be able to understand every individual's incentives and then explain how your proposal aligns with their incentives. ------------ The amount of learned helplessness on HN is counterproductive for anyone hoping to maintain a career over the long term.

nsxwolf 11mo ago

There's also another path to staying out of the spotlight - when you've been under the spotlight a couple times and got no reward at all from it.

GrumpyGoblin 11mo ago

Meh. Good article but not sure it's globally relevant. Spotlight is about personality. Some people are visible, outspoken, and in the spotlight, and impactful. Others are quiet, subdued, behind the scenes but impactful. Some of the best developers I've known have been on either end of the spectrum. At the end of the day it's about impact. When the quiet guy gets the job done every time, people still notice. When the loud guy doesn't, people notice even more. Sure, there are cases where one guy screams from the mountaintops about how much he has done and gets promoted. And there are cases where the quiet guy gets passed over no matter how well he does. But these always wash in the end unless you work for a supremely shitty company. And even then they tend to work themselves out in life eventually. Even if it sucks for the people involved at the time. Impact is the name of the game. Loud or quiet is irrelevant.

striglia 11mo ago

I find this infra perspective so fascinating, as a career-long product platform engineer and solidly staff+. I don't argue that sean's writing (which is amazing) is a little overly mercenary in framing, but I'll pick a few choice sections I don't agree with here too. tldr I think the "product cares about speed; infra cares about leverage" staff engineer archetype is a false dichotomy we shouldn't encourage. "In the product environments Sean describes, where goals pivot quarterly and features are often experimental, speed is the ultimate currency. You need to ship, iterate, and often move on before the market shifts." -- I disagree that speed is the ultimate currency! A great product org also respects long term leverage, it's just _always_ harder to argue for. But it's best to build a strong portfolio of going fast (where needed), going slow (where high leverage), and if everyone agrees your "going slow" led to huge returns you get the best of all worlds. Frankly it's a sign of a relatively junior product engineer if they are myopically focused on speed at the cost of all else. "But the more powerful return is systemic innovation. If you rotate teams every year, you are limited to solving acute bugs that are visible right now. Some problems, however, only reveal their shape over long horizons." -- Extremely true, and this is _equally or more true_ in product domains. My most valuable contributions have come from sitting in a product area long enough to generalize 5 micro optimizations into the macro engineering leverage we needed to drive an order of magnitude more value from the same engineering input. "For some engineers, navigating this [high visibility driven] chaos is a thrill. For those of us who care about system stability, it feels like a trap." -- my protip for prospective staff engineers is to _never_ say you only care about [speed, stability]. In most cases you must care about both, and it's worth advertising yourself as such. If you self select out of companies that only care about [pure stability/pure ship velocity] there should be a valuable balance to strike and staff engineers are in a unique place to enshrine that balance in engineered systems. "In a product organization, you often need to impress your manager’s manager. In an infrastructure organization, you need to impress your customers’ managers." -- surely we can agree impressing customer stakeholders is even more important in (healthy) product orgs :) But it's a curious claim! Great article, wonderful to hear more nuanced and deep discussion of the practice of extremely senior IC engineering. Kudos!

lalitmaganti 11mo ago
Firstly, thanks for the thoughtful comments across the post. Really happy you found it insightful! > But it's best to build a strong portfolio of going fast (where needed), going slow (where high leverage), and if everyone agrees your "going slow" led to huge returns you get the best of all worlds. I guess maybe I oversold this a little in the post but I definitely think that product orgs value speed more than infra orgs: there's often an mismatch when I speak to product engineers on how fast they expect us to build things for them vs how fast we can actually go while considering all our other customers and not breaking other usecases. > my protip for prospective staff engineers is to _never_ say you only care about [speed, stability] Fully agreed, both are important for engineers to have. As above, I think the relative composition of them varies though depending on the area (just pulling numbers from the top of my head, maybe it's 70/30 in favor of speed in product orgs, 30/70 in favor of stability in infra orgs). > surely we can agree impressing customer stakeholders is even more important in (healthy) product orgs You're absolutely right for what I say in the post; reflecting I think I maybe did not go into this topic in enough detail for the nuance it deserves (but the post already felt long enough!). Let's split the discussion into 3 different areas (as IMO they each work slightly different): infra/devex, B2C and B2B. * Infra/devex: as I say in the post, it's critical to impress your other team's managers as that's how you prove impact. * B2C: your customers are consumers so it's all MAUs, revenue etc. There is no "customer stakeholder" who will give you direct feedback for your promo packet * B2B: here's where it gets interesting. So if your management chain is directly able to talk to customers (and especially senior managers) to solicit feedback without middle layers (parter manager, account managers, PMs) then yes you're absolutely correct. But often this is not the case: the middle layers act as a filtering point so you get only a fuzzy sense of how stakeholders in the other company about a specific technical thing you worked on. So again it's sort of at the whim of how your manager feels the other company's managers feels. The basic point I was trying to make is that if you're working on external facing product, from my understanding, even if you impress your external stakeholders, it's not like in your promo packet you can attribute concrete quotes to the customers. quotes like "we couldn't have done X in our company without the work of Y engineer in your org who worked on Z". Whereas this sort of quote is extremely common to see in infra promo packets. Hope this made sense, I'm not sure I communicated this last point well!

diebold 11mo ago

[flagged]

diebold 11mo ago

[flagged]

vcbueger 11mo ago

My voice will likely get lost in the wilderness, but I think it’s a bad sign if you have to write or vibe a whole post like this to defend your worth against another engineer. I understand from a good chunk of my career that the person on the team that promotes themself and/or has the highest charisma and is adequately intelligent will exceed over others on the team that may work harder, have more experience, and/or is doing more important work for the business. But it doesn’t mean that you have to ladder climb and play the game to get what you deserve. You can, and maybe can make more money and survive longer that way. More important than that though is to be yourself. Don’t spend all that time promoting yourself just to make the world a shittier place, so that you get the nice house and car with the kids at the best school, etc. It’s ok to be stepped over while you actually do your job, and for you to feel like shit and maybe be jaded a bit because some asshole that doesn’t deserve it is getting the spotlight. Someone needs to be the Woz. (That’s not a slight against Jobs, btw.)

huflungdung 11mo ago

[dead]