4 ms·

Their counter-argument is that leaf services like that without measurable impact aren't things the company should be investing in and it is up to the individual

Their counter-argument is that leaf services like that without measurable impact aren't things the company should be investing in and it is up to the individual to recognize that and re-allocate themselves onto something that's actually aligned with the company's goals. You simply working on a project isn't useful to a company, what's useful is working on the right project. You get promoted and compensated more if your work aligns with the company, and less (or none) if it doesn't. It's your job to figure it out. Just as it's the company's job to figure out what the market needs. Yeah, projects that are most valuable to a company will be competitive. If you don't want to compete, you'll have to figure something out on your own that isn't as sexy but still provides value. This becomes especially true as you become more senior at this kind of company. If you don't want to work in that environment that's fine, maybe that's not the right corporate culture for you. I hope you found somewhere that was a better fit!

thomasahle 4y ago
Are you saying that people should only focus on building infrastructure for other engineers and never actually make a product? Because it sounds like OP was doing that: making something useful for the customers, just not for the other engineers. Hence the engineers couldn't vouch for the system and secure OP a promotion. That being said, bad projects definitely exist within big companies, and it's not always easy for (junior in particular) people to know if they are working on something useful or not.
- arcticbull 4y ago
  > Are you saying that people should only focus on building infrastructure for other engineers and never actually make a product? Sorry, maybe I was unclear. I wasn't intending to opine on that aspect. I think product and infrastructure are both super valuable. You're goaled on impact not necessarily on whether you build infra or product per se. Infra you're rewarded based on the impact of the product teams leveraging your infra - and product teams you're goaled on moving specific metrics. I've worked at 2 FAANGs - on product teams - and my experience has been that if your product moves metrics that your org has decided are important then you will be rewarded. What I meant when I said "leaf services like that" was "leaf services whose measurable impact doesn't align with org goals." > That being said, bad projects definitely exist within big companies, and it's not always easy for (junior in particular) people to know if they are working on something useful or not. Yeah, that's basically what I was trying to say.
  - kentm 4y ago
    > Infra you're rewarded based on the impact of the product teams leveraging your infra - and product teams you're goaled on moving specific metrics. This was not the case for me. I was told that my project had significant positive impact, and had many product teams vouch for me, but it didn't matter because "the principal engineers don't know who you are".
  - dchftcs 4y ago
    No you were perfectly clear. You just did not approach this constructively. It would have been better if you asked first about how the impact was and could have be measured. Or at least responded more directly when they tried to explain the impact better. Instead of making and sticking to an assumption that the service wasn't useful. It may well be that the person misunderstood their impact, but your arguments did not address that after the person came back with theirs. They could have been an edge case, that they are in an unfortunate situation in the human process of deciding rewards, where choosing and calculating metrics is itself subject to errors in judgment, and you tried to generalize your experiences to their corner of the world, which normally requires a stronger questioning.
    - dchftcs 4y ago
      Now, it's also perfectly fine advice that if a person wants to be rewarded, they should pursue projects that move the metrics of what's normally perceived as important. But that is also trivial advice. A common chokepoint in an engineer's career development is challenging others' preconceived notion of what is important. Often this is with non-technical management, but unfortunately this is sometimes needed with technical peers too. It's politically convenient to just go with the flow and align oneself to the most visible metrics, but that way only a limited amount of bottom-up innovation can happen, and those can be critical to the business. The best one can do is to establish the importance of the project before you do it, but I've seen important projects that were initially not supported by management, and only got traction when an IC did it anyway and demonstrated the value. Sometimes ICs were lucky that the impact was measurable and recognized, sometimes not so much and were deemed to have wasted precious company resources. The world is not perfect and we often have to choose between taking a calculated risk or to conform. It's hard to get business processes 100% right, and not easy for a person to do things with guaranteed outcome, so we just have to live with it and try our best to navigate strategically.
- sobkas 4y ago
  > Because it sounds like OP was doing that: making something useful for the customers, just not for the other engineers. Hence the engineers couldn't vouch for the system and secure OP a promotion. For internal customers. Not real customers. Because they are captive audience. What they are going to do if generating a report takes 10hr? Purchase* different tool? Force devs to make w better one? Not their pay grade. They aren't even allowed to set requirements for features/functionality. *That's when consulting firm swoops in to make great promises about how tool that they will make will solve all the problems. But because people who are using such tools can't set priorities for features/functionality, reports will generate in 9hr, but they will have to click ok every X minutes.
kentm 4y ago
This is a pretty condescending post that assumes quite a lot about my work. > You simply working on a project isn't useful to a company, what's useful is working on the right project. No, my project was measurably useful to the company. It wasn't useful for engineers, but it was useful for internal, non technical users. I helped build a team from scratch and launch a product with high internal user satisfaction. But I was told that I needed, specifically, engineers from outside my immediate team to vouch for me. And I met with other people with the same problem and they told me "Don't work for products for business users." As an aside the internal tooling for non-technical users was atrocious. Wonder why. :)
- arcticbull 4y ago
  > This is a pretty condescending post that assumes quite a lot about my work. Sorry if it came across that way, that was not my intent. > No, my project was measurably useful to the company. It wasn't useful for engineers, but it was useful for internal, non technical users. If that's not what the company values, then that's not a project the company wants to incentivize you to make. If you choose to make it anyways, would you really expect them to reward you for it? It sounds like the issue was as I was suggesting, that what you were trying to solve for wasn't what the org wanted and wasn't what they were goaling you on.
  - kentm 4y ago
    > If you choose to make it anyways, would you really expect them to reward you for it? A healthy organization should reward developers for making internal tooling that is deemed necessary for the functioning of the org and drives value, yes. You're kinda ignoring the part here where I said that it was measurably useful to the company. If you're saying that you need to ignore necessary internal tools and get on the big visibility projects to get promoted, then thats exactly optimizing for self-promotion. Companies that ignore vital internal work that is not sexy and don't provide ways for engineers working on that vital internal work to advance their careers will end up unable to drive revenue due to low productivity.
  - btown 4y ago
    > wasn't what they were goaling you on This is the problem in a nutshell, no? A company that does not value a team that delivers measurable value to non-technical teams, and that provides no "alternate paths" for its non-technical users to vouch quantitatively for the promotability of technical team members, is creating a culture that is suboptimal for its financial goals. That quantitative bar must be high, of course, but if I heard as a C-level that people were getting advice "don't work for products for business users" I'd clear my calendar and get to the heart of why that was, because the very "routing fabric" of the company would be at stake. If they're not allowed to build i-tools, your technical teams will miss insights they need to build the right things, from the users who know more about the domain than anyone else.
nequo 4y ago
> You get promoted and compensated more if your work aligns with the company, and less (or none) if it doesn't. It's your job to figure it out. I have never worked at a FAANG. Wouldn’t it be the manager’s job to figure out what I should be working on? What is the manager’s job at such a company?
- GoOnThenDoTell 4y ago
  > What is the manager’s job at such a company? Figure out how to argue for more headcount, by expanding the scope of the team or by asking reports to narrow the breadth of their work to create headcount gaps.
  - arcticbull 4y ago
    Exactly, and provide mentorship, guidance - and accountability - to ICs.
anonymoushn 4y ago
Maybe you should try having impactful projects assigned to you instead of not-impactful ones, haha!
- arcticbull 4y ago
  At these companies successful senior folks don't sit around waiting to get told what they're working on. It's their job to pick or start impactful projects in line with their org goals. If they're right they get rewarded but if they're not, they don't. If you're junior it won't really matter. If you're senior, and you're sitting there hoping your manager is going to give you something meaty you're not long for that company - because that is not your job. This was my experience at two FAANGs and also at one non-FAANG company over the last 10 years. Maybe it's different at the ones I didn't work at, but your snark is neither useful nor interesting. It also gives folks considering FAANGs here a false impression of what working there is actually like.
  - anonymoushn 4y ago
    As a senior SWE at Amazon I had the autonomy to do this sort of thing as soon as the several years worth of work my team had planned was done. Half the senior SWEs at a big job board that calls itself a tech company are concerned with migrating everything to per-table microservices that expose endpoints that do exactly the SQL queries other services used to do directly. Thanks for your report of your different experience in a different org. I'll try not to give people a false impression by posting about mine.

thomasahle 4y ago

Are you saying that people should only focus on building infrastructure for other engineers and never actually make a product? Because it sounds like OP was doing that: making something useful for the customers, just not for the other engineers. Hence the engineers couldn't vouch for the system and secure OP a promotion. That being said, bad projects definitely exist within big companies, and it's not always easy for (junior in particular) people to know if they are working on something useful or not.

arcticbull 4y ago
> Are you saying that people should only focus on building infrastructure for other engineers and never actually make a product? Sorry, maybe I was unclear. I wasn't intending to opine on that aspect. I think product and infrastructure are both super valuable. You're goaled on impact not necessarily on whether you build infra or product per se. Infra you're rewarded based on the impact of the product teams leveraging your infra - and product teams you're goaled on moving specific metrics. I've worked at 2 FAANGs - on product teams - and my experience has been that if your product moves metrics that your org has decided are important then you will be rewarded. What I meant when I said "leaf services like that" was "leaf services whose measurable impact doesn't align with org goals." > That being said, bad projects definitely exist within big companies, and it's not always easy for (junior in particular) people to know if they are working on something useful or not. Yeah, that's basically what I was trying to say.
- kentm 4y ago
  > Infra you're rewarded based on the impact of the product teams leveraging your infra - and product teams you're goaled on moving specific metrics. This was not the case for me. I was told that my project had significant positive impact, and had many product teams vouch for me, but it didn't matter because "the principal engineers don't know who you are".
- dchftcs 4y ago
  No you were perfectly clear. You just did not approach this constructively. It would have been better if you asked first about how the impact was and could have be measured. Or at least responded more directly when they tried to explain the impact better. Instead of making and sticking to an assumption that the service wasn't useful. It may well be that the person misunderstood their impact, but your arguments did not address that after the person came back with theirs. They could have been an edge case, that they are in an unfortunate situation in the human process of deciding rewards, where choosing and calculating metrics is itself subject to errors in judgment, and you tried to generalize your experiences to their corner of the world, which normally requires a stronger questioning.
  - dchftcs 4y ago
    Now, it's also perfectly fine advice that if a person wants to be rewarded, they should pursue projects that move the metrics of what's normally perceived as important. But that is also trivial advice. A common chokepoint in an engineer's career development is challenging others' preconceived notion of what is important. Often this is with non-technical management, but unfortunately this is sometimes needed with technical peers too. It's politically convenient to just go with the flow and align oneself to the most visible metrics, but that way only a limited amount of bottom-up innovation can happen, and those can be critical to the business. The best one can do is to establish the importance of the project before you do it, but I've seen important projects that were initially not supported by management, and only got traction when an IC did it anyway and demonstrated the value. Sometimes ICs were lucky that the impact was measurable and recognized, sometimes not so much and were deemed to have wasted precious company resources. The world is not perfect and we often have to choose between taking a calculated risk or to conform. It's hard to get business processes 100% right, and not easy for a person to do things with guaranteed outcome, so we just have to live with it and try our best to navigate strategically.
sobkas 4y ago
> Because it sounds like OP was doing that: making something useful for the customers, just not for the other engineers. Hence the engineers couldn't vouch for the system and secure OP a promotion. For internal customers. Not real customers. Because they are captive audience. What they are going to do if generating a report takes 10hr? Purchase* different tool? Force devs to make w better one? Not their pay grade. They aren't even allowed to set requirements for features/functionality. *That's when consulting firm swoops in to make great promises about how tool that they will make will solve all the problems. But because people who are using such tools can't set priorities for features/functionality, reports will generate in 9hr, but they will have to click ok every X minutes.

kentm 4y ago

This is a pretty condescending post that assumes quite a lot about my work. > You simply working on a project isn't useful to a company, what's useful is working on the right project. No, my project was measurably useful to the company. It wasn't useful for engineers, but it was useful for internal, non technical users. I helped build a team from scratch and launch a product with high internal user satisfaction. But I was told that I needed, specifically, engineers from outside my immediate team to vouch for me. And I met with other people with the same problem and they told me "Don't work for products for business users." As an aside the internal tooling for non-technical users was atrocious. Wonder why. :)

arcticbull 4y ago
> This is a pretty condescending post that assumes quite a lot about my work. Sorry if it came across that way, that was not my intent. > No, my project was measurably useful to the company. It wasn't useful for engineers, but it was useful for internal, non technical users. If that's not what the company values, then that's not a project the company wants to incentivize you to make. If you choose to make it anyways, would you really expect them to reward you for it? It sounds like the issue was as I was suggesting, that what you were trying to solve for wasn't what the org wanted and wasn't what they were goaling you on.
- kentm 4y ago
  > If you choose to make it anyways, would you really expect them to reward you for it? A healthy organization should reward developers for making internal tooling that is deemed necessary for the functioning of the org and drives value, yes. You're kinda ignoring the part here where I said that it was measurably useful to the company. If you're saying that you need to ignore necessary internal tools and get on the big visibility projects to get promoted, then thats exactly optimizing for self-promotion. Companies that ignore vital internal work that is not sexy and don't provide ways for engineers working on that vital internal work to advance their careers will end up unable to drive revenue due to low productivity.
- btown 4y ago
  > wasn't what they were goaling you on This is the problem in a nutshell, no? A company that does not value a team that delivers measurable value to non-technical teams, and that provides no "alternate paths" for its non-technical users to vouch quantitatively for the promotability of technical team members, is creating a culture that is suboptimal for its financial goals. That quantitative bar must be high, of course, but if I heard as a C-level that people were getting advice "don't work for products for business users" I'd clear my calendar and get to the heart of why that was, because the very "routing fabric" of the company would be at stake. If they're not allowed to build i-tools, your technical teams will miss insights they need to build the right things, from the users who know more about the domain than anyone else.

nequo 4y ago

> You get promoted and compensated more if your work aligns with the company, and less (or none) if it doesn't. It's your job to figure it out. I have never worked at a FAANG. Wouldn’t it be the manager’s job to figure out what I should be working on? What is the manager’s job at such a company?

GoOnThenDoTell 4y ago
> What is the manager’s job at such a company? Figure out how to argue for more headcount, by expanding the scope of the team or by asking reports to narrow the breadth of their work to create headcount gaps.
- arcticbull 4y ago
  Exactly, and provide mentorship, guidance - and accountability - to ICs.

anonymoushn 4y ago

Maybe you should try having impactful projects assigned to you instead of not-impactful ones, haha!

arcticbull 4y ago
At these companies successful senior folks don't sit around waiting to get told what they're working on. It's their job to pick or start impactful projects in line with their org goals. If they're right they get rewarded but if they're not, they don't. If you're junior it won't really matter. If you're senior, and you're sitting there hoping your manager is going to give you something meaty you're not long for that company - because that is not your job. This was my experience at two FAANGs and also at one non-FAANG company over the last 10 years. Maybe it's different at the ones I didn't work at, but your snark is neither useful nor interesting. It also gives folks considering FAANGs here a false impression of what working there is actually like.
- anonymoushn 4y ago
  As a senior SWE at Amazon I had the autonomy to do this sort of thing as soon as the several years worth of work my team had planned was done. Half the senior SWEs at a big job board that calls itself a tech company are concerned with migrating everything to per-table microservices that expose endpoints that do exactly the SQL queries other services used to do directly. Thanks for your report of your different experience in a different org. I'll try not to give people a false impression by posting about mine.