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.
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.
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.
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.
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.
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.
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 (not Big Tech) 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.
>> 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.
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.
I think you're conflating engineer-led "tech for the purposes of tech" with "do what we think will have the most impact for customers." Obviously tech for the purposes of tech is bad, as is doing something that the engineer perceives has most impact for customers when it didn't actually have the most impact for customers, but it is undoubtedly good when the engineer autonomously builds what's best/resonates most with customers despite that thing not being what the exec is telling us to do. There is some nuance, and a need to thread the needle to do this successfully and keep one's job, but for savvy folks it's the best way to have impact and get promotions.
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..
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.
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.
> 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!
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.
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.
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.
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.
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.
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.
You can hit the undown link that shows up?
Click the “undown” button to undo a down vote.
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.
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.
> 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.
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 (not Big Tech) 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.
Being left alone to build your cathedrals is the dream for me. This seems nice.
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?
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.
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.
I think you're conflating engineer-led "tech for the purposes of tech" with "do what we think will have the most impact for customers." Obviously tech for the purposes of tech is bad, as is doing something that the engineer perceives has most impact for customers when it didn't actually have the most impact for customers, but it is undoubtedly good when the engineer autonomously builds what's best/resonates most with customers despite that thing not being what the exec is telling us to do. There is some nuance, and a need to thread the needle to do this successfully and keep one's job, but for savvy folks it's the best way to have impact and get promotions.
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...)
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..
Well you factor that in too? And be willing to change focus if that's the feedback.
The same things that go wrong anyway?
Nothing, except maybe an asteroid hitting the building and wiping out the entire team?
You almost shut down my computer，lol
It's easy to write that blogpost when you are in a position of a lot of privilege, in arguably the best software engineering company in the world, and got where you are surely for your competence, but also a high degree of luck.
Some other people has to grind harder and even be better than you to get half of your success, that doesn't mean that they are wrong, or that the book is wrong.
I believe a lot, if not all advice there in the book is necessary. Other people might not work at Google, but as I've said before, might need to grind different gears in order to be successful, if you don't -- good for you!
A lot of your suggestions would get you fired very quickly on many companies, it's good that it all works for you.
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.
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.
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.
> 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!
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.