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.
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.
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".
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.
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.
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.
> 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. :)
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.
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.
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.
Unfortunately I was helping out with our hiring process, and let's just say with the recent downturn that hasn't been the most important work lately :(
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?
Figure out how to argue for more headcount, by expanding the scope of the team or by asking reports to narrow the depth of their work.
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.
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!