Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



> 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.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: