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 :(
> 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. :)