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.
That's how it works for every organization. Not just corporate America. Want to play on the varsity baseball team? Better be popular with the coaches and other players. Otherwise you're on the bench keeping score. Want to go to Harvard grad school? Better be the right kind of popular. Want to be celebrated in machine learning? Better be popular by doing shallow work on lots of projects. The whole world is a scam, and the scammers always win.
But calling the whole world a scam feels like letting the worst parts define the whole yet it can feel like the game is rigged in favor of the loudest or most connected
So I'm not sure about this, particularly in the context of this article. I think it definitely applies to the splashy, Spotlight, one-off projects that will make a career with one shot. But a lot of careers aren't made that way, and this article is specifically talking about the ones that aren't.
I've found that trust is a currency in a corporate environment, possibly the most important one. And trust is built over time. If you work behind the scenes to ensure the success of a project but don't claim it, there's a decent chance somebody else will, and maybe it'll appear in their promo packet. But if you are in the vicinity of enough successful projects, over a long period of time, there's a good chance that leadership will notice that the common element is you. And in the process you'll built up a good reputation and network, so even if leadership gets replaced there are lots of other people that want to work with you. Promotions come slower at first, but they eventually catch up since you don't need to suffer the resets of failed projects and new roles.
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.
There’s too much emphasis on career growth into leadership. I know so many programmers who simply want to solve the trickiest of technical problems, do good work they can feel proud of, and go home to their families. They want stability more than anything.
There are rare software companies where this is exactly what programmers do. The pay is lower than at FAANG & SV/LA/NYC startups, but work-life balance is great, stability is great, and most of all they get to just focus on doing great work. It's not about making quarterly goals, it's about stewarding (or perhaps gardening) a software project for many years.
I worked at such a place for 15 years. The downsides for me were lower pay, no equity, and not getting broad industry experience. I ended up leaving, and I now make a lot more money, but I do miss that environment. It was very conducive to long-term, focused, deep problem solving, and most of the senior engineers were absolutely stellar because of being in that environment for so long.
The problem here, at least I think, is you may be very unaware of the expectations of running ones own business. There are far more politics, more being cutthroat, tons of regulations you must be aware of that come with potential later penalties if you are not, legal threats, and more.
To be fair, I this issue isn’t endemic only to big companies. Rg 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.
It's pretty demoralizing to realize that appearances matter more than merit in careers/politics/dating/business/etc. The pragmatic approach is to not give up on merit but not neglect appearances either.
Still, the idealist in me hates this. It feels like quality should win out over advertising yet it rarely does in the grand scheme of things.
That is because time and energy are limited resources, and measuring merit accurately is very costly. Measuring appearance is far less costly, and might serve as an acceptable proxy. And often times it might not.
this is the biggest benefit of 1:1's in my opinion.
Often, individuals can claim credit simply by being first and loudest. For example, and individual can highlight a problem area that someone is already working on in the team and loudly talk about the flaws in the current approach and how they will solve it. The individual need not actually solve the task if the first person finishes - but now the success is subconsciously attributed to the thought leadership/approach of the new individual.
Good managers/leadership teams have mechanisms to limit this type of strategy, but it requires them to talk to everyone on the team - listen for unsaid feedback and look at hard artifacts. Otherwise you quickly have a team of people who are great at nothing more than talking about problems and dreaming of solutions.
I've always kind of expected it to work this way, with people being cutthroat and stealing credit for other people's work.
What I have seen in reality is a lot more nuanced. There are a lot of good ideas that will simply die if nobody pitches them the right way, i.e. if no one gets the rest of the team/org/company to understand and agree that it solves an important problem.
There are also very few novel ideas in a mature business or technology space. Every time I think I've come up with one, I search the internal company docs and often someone had mentioned the same thing 5 years ago in some long-forgotten design doc or something.
I've come to realize that the hard thing and the bottleneck for a good idea to have real impact is not the idea itself or the execution, it's pulling the right strings to make space for the idea and get it accepted. At a small scale, in your own team or ownership domain, this isn't necessary and you can just build things and let the results speak for themselves. But the amount of impact that thing has on the broader company will be limited if you don't pull the strings the right way.
Some people despise this idea and in that case, a big company is probably not the right place for you. But most of the cases I've seen of "brilliant engineers passed over for credit" were people not realizing and not doing this necessary part of the job. If someone else steps in and gets the idea more widely recognized after you had let it stall and moved onto the next thing, then 1. usually you do still some partial recognition for it so it's a win/win and 2. the other person is not really stealing credit, because if they had done nothing the idea would have just died and you wouldn't have gotten credit anyway.
You can own the narrative while also not being in the spotlight.
At the end of the day, only a handful of stakeholders matter in any organization. So long as you can promote you and your team's initiatives to your manager, your skip manager, and a couple key members of Product, Sales, Customer Success, and Leadership - your place is secure.
In fact, in most cases I would say a mass spotlight is actually a net negative, because it only increases the risk that someone might view you as a potential competitor for either budget or responsibility.
So long as you remain aligned to the business's stated goals for the year and can communicate that to the relevant subsegment of stakeholders, a massive spotlight is unnecessary.
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 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.
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.
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.
Yeah, a couple years ago I built a system that undergirded what was at the time a new product but which now generates significant revenue for the company. That system is shockingly reliable to the extent that few at the company know it exists and those who do take its reliability for granted. It's not involved in any cost or reliability fires, so people never really have to think about how impressive this little piece of software really is--the things they don't need to worry about because this software is chugging along, doing its job, silently recovering from connectivity issues, database maintenance, etc without any real issue or maintenance.
It's a little bit of a tragic irony that the better a job you do, the less likely it is to be noticed. (:
May be you need to have "scheduled downtime" when your undergirding system is down for "maintenance" and they will notice! [Half joking... Probably not possible but better to have scheduled maintenance than have to do firefighting under extreme time pressure]
Unfortunately, in this profession we are being lead by managers that do not longer have deep knowledge of how to build good software systems. They can't evaluate contributions in code, so they resort to evaluate participation, and popularity.
As an engineer you are left with a dilema. Either you focus on writing solid code and making your projects move forward or you focus on selling your self to the leadership class.
Couldn’t agree more (but frustratingly due to HN’ shitty mobile experience i downvoted this, sorry!)
In a past life i used to complain that people only praised my work after i fucked up and subsequently fixed it. I’d go month on month of great execution and all I’d hear would be complaints, but as soon as i “fixed” a major issue, i was a hero.
I’ve learn that setting appropriate incentives is the hardest part of building an effective organization.
I had to mention this in an early startup, when I did some firefighting, and the biz people were praising that. I said I wanted to set a culture in which engineering was rewarded for making things just happen and work, not for firefighting.
A nice thing about early startups is that it's the easiest time to try to set engineering culture like this on a good track. Once you start hiring people, they will either cement elements of whatever culture you're setting, or they'll bring a poor culture with them.
(My current understanding, if you find your culture has been corrupted with a clique/wolfpack of mercenary ex-FAANG people, or a bunch of performative sprint theatre seatwarmers, is that you either have to excise/amputate everywhere the cancer has spread, or accept that you're stuck with a shit culture forever.)
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.
> 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.
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.
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.
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.
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.
I forget the exact details, but we had a bug that prevented logging in to the app for a large subset of users.
The engineer that caused the bug ended up staying late and fixing it. He was treated like an absolute hero by management, even though it was his fault in the first place. (Don't worry, we all fully understood it wasn't just his fault. The whole system failed and he wouldn't have been harshly judged for the problem.)
From then on we joked about adding bugs on purpose so that we could all get similar treatment.
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.
Who is right is the wrong question here (not that your point is wrong - it is correct in some situations but not the one I'm talking about). This is a case where the features we need for the release were planned in advance and management signed off on them - by definition getting the feature done is right (even if it turns out customers don't want it, at this point we have committed as a company). However there are always a few bugs that become last minute stop ship issues that should have been prevented long ago.
I guess it takes a visionary management to recognize the value of disasters that were prevented.
Who is worth more? The person that quietly removes scrub brush and other fuel on the ground in the years before the forest fire starts, or the person that comes in once the fire starts and using lots of equipment and effort puts the fire out. Often the latter person gets the accolades, the former is a thankless task.
If a company lacks visionary leaders like that, then one must wonder if the company has much of a future anyway.
> I guess it takes a visionary management to recognize the value of disasters that were prevented.
I think you should change “visionary” with “competent” here.
This industry has been talking about how bad it is to have “hero devs” for decades, maybe since it’s ENIAC beginnings. After a few decades, you’d think this would filter up to management.
If you change your example from brush clearing to garbage removal it becomes pretty clear: who should get more accolades, the guy who takes out the trash or the guy who stays up all night treating the infections? Both. It’s management that fired the custodial staff who should be canned.
Management knows in the abstract. However they also know the value of awards and shipping - both of which can be in conflict. They do not know how to resolve this conflict.
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.
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)
>> 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 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.
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.
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...)
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..
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.
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.
> 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!
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.
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.
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.
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.
My brother had an internship in a medium-sized company, and after 6 months, a new product (that he was hired for basically) and 3 new internal tools (including one for reading data trace, which, after reading this, is quite a propos), he was hired as a staff engineer.
I do not have his proactivity for sure, nor I have his ease with other people, but I managed to land my job in an infra/tool for network and security without much difficulties.
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 read it as saying you should fire someone because of their age. Not stupid, malicious.
One does not get the title of "Staff Engineer" for age.
One also does not get fired for age. One gets fired for sitting on their ass doing virtually nothing. The "Staff Engineers" and above tend to sit on their ass, doing virtually nothing. Any sane company would do well by firing them.
When Google was a young company the idea of someone in engineering with a fat title sitting on his ass doing nothing was not tolerated. That's when Google was doing amazing things, was innovative and actually gave a s!it because every single person in that company wanted to get s!it done. Right now Google is a standard issue sh!t company because its upper echelons are full of people who are just warming their fancy chairs, talk about their amazing work life balance and count the days to their next options package vests so they can take yet another multi-months vacation.
> 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.
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.
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.
This - I've been very honest with my manager that I won't play "the game" in this organisation - I don't really have to, there is plenty for staff engineers to tackle to have a long career without the yoke of management.
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.
> 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.
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.
That's how it works for every organization. Not just corporate America. Want to play on the varsity baseball team? Better be popular with the coaches and other players. Otherwise you're on the bench keeping score. Want to go to Harvard grad school? Better be the right kind of popular. Want to be celebrated in machine learning? Better be popular by doing shallow work on lots of projects. The whole world is a scam, and the scammers always win.
But calling the whole world a scam feels like letting the worst parts define the whole yet it can feel like the game is rigged in favor of the loudest or most connected
So I'm not sure about this, particularly in the context of this article. I think it definitely applies to the splashy, Spotlight, one-off projects that will make a career with one shot. But a lot of careers aren't made that way, and this article is specifically talking about the ones that aren't.
I've found that trust is a currency in a corporate environment, possibly the most important one. And trust is built over time. If you work behind the scenes to ensure the success of a project but don't claim it, there's a decent chance somebody else will, and maybe it'll appear in their promo packet. But if you are in the vicinity of enough successful projects, over a long period of time, there's a good chance that leadership will notice that the common element is you. And in the process you'll built up a good reputation and network, so even if leadership gets replaced there are lots of other people that want to work with you. Promotions come slower at first, but they eventually catch up since you don't need to suffer the resets of failed projects and new roles.
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.
There’s too much emphasis on career growth into leadership. I know so many programmers who simply want to solve the trickiest of technical problems, do good work they can feel proud of, and go home to their families. They want stability more than anything.
There are rare software companies where this is exactly what programmers do. The pay is lower than at FAANG & SV/LA/NYC startups, but work-life balance is great, stability is great, and most of all they get to just focus on doing great work. It's not about making quarterly goals, it's about stewarding (or perhaps gardening) a software project for many years.
I worked at such a place for 15 years. The downsides for me were lower pay, no equity, and not getting broad industry experience. I ended up leaving, and I now make a lot more money, but I do miss that environment. It was very conducive to long-term, focused, deep problem solving, and most of the senior engineers were absolutely stellar because of being in that environment for so long.
What interr problems have you solved recently?
>meant that you don't worry about this things
Not at all, that was a confused expectation.
The problem here, at least I think, is you may be very unaware of the expectations of running ones own business. There are far more politics, more being cutthroat, tons of regulations you must be aware of that come with potential later penalties if you are not, legal threats, and more.
To be fair, I this issue isn’t endemic only to big companies. Rg 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.
You don't have to self-promote aggressively, but you do have to advocate for your work
It's pretty demoralizing to realize that appearances matter more than merit in careers/politics/dating/business/etc. The pragmatic approach is to not give up on merit but not neglect appearances either.
Still, the idealist in me hates this. It feels like quality should win out over advertising yet it rarely does in the grand scheme of things.
That is because time and energy are limited resources, and measuring merit accurately is very costly. Measuring appearance is far less costly, and might serve as an acceptable proxy. And often times it might not.
this is the biggest benefit of 1:1's in my opinion.
Often, individuals can claim credit simply by being first and loudest. For example, and individual can highlight a problem area that someone is already working on in the team and loudly talk about the flaws in the current approach and how they will solve it. The individual need not actually solve the task if the first person finishes - but now the success is subconsciously attributed to the thought leadership/approach of the new individual.
Good managers/leadership teams have mechanisms to limit this type of strategy, but it requires them to talk to everyone on the team - listen for unsaid feedback and look at hard artifacts. Otherwise you quickly have a team of people who are great at nothing more than talking about problems and dreaming of solutions.
It shouldn’t be this way. Merit should be the metric. But it’s true. No matter how good or bad your numbers are, if Bob likes you, you’re good.
Keep polishing those soft skills and if you have a face only your mother would love, be a writer… but get your voice out there.
I've always kind of expected it to work this way, with people being cutthroat and stealing credit for other people's work.
What I have seen in reality is a lot more nuanced. There are a lot of good ideas that will simply die if nobody pitches them the right way, i.e. if no one gets the rest of the team/org/company to understand and agree that it solves an important problem.
There are also very few novel ideas in a mature business or technology space. Every time I think I've come up with one, I search the internal company docs and often someone had mentioned the same thing 5 years ago in some long-forgotten design doc or something.
I've come to realize that the hard thing and the bottleneck for a good idea to have real impact is not the idea itself or the execution, it's pulling the right strings to make space for the idea and get it accepted. At a small scale, in your own team or ownership domain, this isn't necessary and you can just build things and let the results speak for themselves. But the amount of impact that thing has on the broader company will be limited if you don't pull the strings the right way.
Some people despise this idea and in that case, a big company is probably not the right place for you. But most of the cases I've seen of "brilliant engineers passed over for credit" were people not realizing and not doing this necessary part of the job. If someone else steps in and gets the idea more widely recognized after you had let it stall and moved onto the next thing, then 1. usually you do still some partial recognition for it so it's a win/win and 2. the other person is not really stealing credit, because if they had done nothing the idea would have just died and you wouldn't have gotten credit anyway.
You can own the narrative while also not being in the spotlight.
At the end of the day, only a handful of stakeholders matter in any organization. So long as you can promote you and your team's initiatives to your manager, your skip manager, and a couple key members of Product, Sales, Customer Success, and Leadership - your place is secure.
In fact, in most cases I would say a mass spotlight is actually a net negative, because it only increases the risk that someone might view you as a potential competitor for either budget or responsibility.
So long as you remain aligned to the business's stated goals for the year and can communicate that to the relevant subsegment of stakeholders, a massive spotlight is unnecessary.
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 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.
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).
Did you read the full post? The author addressed these points at the end. They’re not naive.
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.
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.
That was painful to read and acknowledge. Succinct.
This description of the poles is so true from my experience
Deep work that's important but does not appear shiny carries an elevated risk of being completely messed up by someone.
"Oh this thing here looks steady and boring. This sure does not need a team of six."
Next thing you know, the thing falls apart, destabilizing everything that stood on it's stability.
Basically the Sysadmin's dilemma.
Everything working fine: "What are we paying you for?"
Something broken: "What are we paying you for?"
Yeah, a couple years ago I built a system that undergirded what was at the time a new product but which now generates significant revenue for the company. That system is shockingly reliable to the extent that few at the company know it exists and those who do take its reliability for granted. It's not involved in any cost or reliability fires, so people never really have to think about how impressive this little piece of software really is--the things they don't need to worry about because this software is chugging along, doing its job, silently recovering from connectivity issues, database maintenance, etc without any real issue or maintenance.
It's a little bit of a tragic irony that the better a job you do, the less likely it is to be noticed. (:
May be you need to have "scheduled downtime" when your undergirding system is down for "maintenance" and they will notice! [Half joking... Probably not possible but better to have scheduled maintenance than have to do firefighting under extreme time pressure]
Unfortunately, in this profession we are being lead by managers that do not longer have deep knowledge of how to build good software systems. They can't evaluate contributions in code, so they resort to evaluate participation, and popularity.
As an engineer you are left with a dilema. Either you focus on writing solid code and making your projects move forward or you focus on selling your self to the leadership class.
Couldn’t agree more (but frustratingly due to HN’ shitty mobile experience i downvoted this, sorry!)
In a past life i used to complain that people only praised my work after i fucked up and subsequently fixed it. I’d go month on month of great execution and all I’d hear would be complaints, but as soon as i “fixed” a major issue, i was a hero.
I’ve learn that setting appropriate incentives is the hardest part of building an effective organization.
I had to mention this in an early startup, when I did some firefighting, and the biz people were praising that. I said I wanted to set a culture in which engineering was rewarded for making things just happen and work, not for firefighting.
A nice thing about early startups is that it's the easiest time to try to set engineering culture like this on a good track. Once you start hiring people, they will either cement elements of whatever culture you're setting, or they'll bring a poor culture with them.
(My current understanding, if you find your culture has been corrupted with a clique/wolfpack of mercenary ex-FAANG people, or a bunch of performative sprint theatre seatwarmers, is that you either have to excise/amputate everywhere the cancer has spread, or accept that you're stuck with a shit culture forever.)
You can hit the undown link that shows up?
Click the “undown” button to undo a down vote.
You can downvote submissions?
After your karma gets high enough, yes.
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.
> 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.
Yea all that is neat if all that data wouldn't be collected and sold by all these big tech companies.
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.
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.
The long-game of quiet impact: context accumulation, trust-building, and systems thinking
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.
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.
I forget the exact details, but we had a bug that prevented logging in to the app for a large subset of users.
The engineer that caused the bug ended up staying late and fixing it. He was treated like an absolute hero by management, even though it was his fault in the first place. (Don't worry, we all fully understood it wasn't just his fault. The whole system failed and he wouldn't have been harshly judged for the problem.)
From then on we joked about adding bugs on purpose so that we could all get similar treatment.
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.
Who is right is the wrong question here (not that your point is wrong - it is correct in some situations but not the one I'm talking about). This is a case where the features we need for the release were planned in advance and management signed off on them - by definition getting the feature done is right (even if it turns out customers don't want it, at this point we have committed as a company). However there are always a few bugs that become last minute stop ship issues that should have been prevented long ago.
I guess it takes a visionary management to recognize the value of disasters that were prevented.
Who is worth more? The person that quietly removes scrub brush and other fuel on the ground in the years before the forest fire starts, or the person that comes in once the fire starts and using lots of equipment and effort puts the fire out. Often the latter person gets the accolades, the former is a thankless task.
If a company lacks visionary leaders like that, then one must wonder if the company has much of a future anyway.
> I guess it takes a visionary management to recognize the value of disasters that were prevented.
I think you should change “visionary” with “competent” here.
This industry has been talking about how bad it is to have “hero devs” for decades, maybe since it’s ENIAC beginnings. After a few decades, you’d think this would filter up to management.
If you change your example from brush clearing to garbage removal it becomes pretty clear: who should get more accolades, the guy who takes out the trash or the guy who stays up all night treating the infections? Both. It’s management that fired the custodial staff who should be canned.
Management knows in the abstract. However they also know the value of awards and shipping - both of which can be in conflict. They do not know how to resolve this conflict.
That's sounds very Shakespearean.
> 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.
Being left alone to build your cathedrals is the dream for me. This seems nice.
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)
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?
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?
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.
If your proposal doesn't align with leadership vision or the product they want to grow...
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...)
Well you factor that in too? And be willing to change focus if that's the feedback.
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..
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.
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.
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
The same things that go wrong anyway?
Nothing, except maybe an asteroid hitting the building and wiping out the entire team?
> 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?
> 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!
Beautifully-written post, full of insights. Thanks for sharing!
>spotlight
Literally, who?
You almost shut down my computer，lol
[dead]
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.
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.
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.
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.
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.
My brother had an internship in a medium-sized company, and after 6 months, a new product (that he was hired for basically) and 3 new internal tools (including one for reading data trace, which, after reading this, is quite a propos), he was hired as a staff engineer.
I do not have his proactivity for sure, nor I have his ease with other people, but I managed to land my job in an infra/tool for network and security without much difficulties.
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.
So you suggest firing people based on their title alone? Sounds pretty damn stupid.
I read it as saying you should fire someone because of their age. Not stupid, malicious.
> I read it as saying you should fire someone because of their age. Not stupid, malicious.
One does not get the title of "Staff Engineer" for age.
One also does not get fired for age. One gets fired for sitting on their ass doing virtually nothing. The "Staff Engineers" and above tend to sit on their ass, doing virtually nothing. Any sane company would do well by firing them.
When Google was a young company the idea of someone in engineering with a fat title sitting on his ass doing nothing was not tolerated. That's when Google was doing amazing things, was innovative and actually gave a s!it because every single person in that company wanted to get s!it done. Right now Google is a standard issue sh!t company because its upper echelons are full of people who are just warming their fancy chairs, talk about their amazing work life balance and count the days to their next options package vests so they can take yet another multi-months vacation.
> 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.
so what one should do after a certain age?
Continue to perform or live off the savings.
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.
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.
This - I've been very honest with my manager that I won't play "the game" in this organisation - I don't really have to, there is plenty for staff engineers to tackle to have a long career without the yoke of management.
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.
> 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 :)