Hacker News new | past | comments | ask | show | jobs | submit login

Absolutely. There are a lot of failure modes. This is why true IC leadership with teeth is needed. The whole point of staff+ engineer roles (outside of specialist research) is to navigate the right technical decisions that span across teams.



IC leadership positions are earned by leading cross-team projects, so the senior engineers who want them (and the managers who want to grow IC leaders) are encouraged to turn everything into one.


Leadership positions should be granted not just on “projects”, but demonstrated technical ability and judgement. This often includes influence of what NOT to do just as much as it involves driving projects. Obviously any rubric is only as good as the people who apply it, and if you hire tens of thousands of smart engineers with only one really profitable product and not much in the way of vision it’s going to be a fucking mess.


But because of the stigmatization of silos and valorization of cross-team efforts, making a project cross-team when it doesn't need to be is considered an example of demonstrating the company's values rather than example of bad technical judgement.


That’s a false dichotomy and bad leadership judgement. I don’t doubt these arguments are made and sometimes won (especially in dysfunctional or apathetic orgs), but context matters, there’s no value system that supersedes critical thinking in context. One of the questions I ask in staff+ promo committee is what did this person prevent from being built.


Good question :-) Could make sense on a senior developer level?

At the same time, seems possibly easy to game? If two friends make unnecessary suggestions, and stop each other's suggestions.

If it becomes well known that this question is being asked?

Not much work required to pretend one stopped sth from getting built




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

Search: