3 ms·

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 do

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.
    - arcticbull 4y ago
      That's fair criticism, and I appreciate your sharing it. I'm not always mindful that tone doesn't carry well by text, and I could have done a better job approaching this.
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.

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.
  - arcticbull 4y ago
    That's fair criticism, and I appreciate your sharing it. I'm not always mindful that tone doesn't carry well by text, and I could have done a better job approaching this.

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.