4 ms·

I kind-of wonder if a key point here is: Grooming newly trained engineers to be comfortable with a proprietary tech stack, a particular delivery cadence and a

I kind-of wonder if a key point here is: Grooming newly trained engineers to be comfortable with a proprietary tech stack, a particular delivery cadence and a company’s cultural values results in a shorter and more seamless onboarding process and quicker contributions to the team. I.e. "We want interchangeable developers to slot into our process, rather than people who arrive with established ideas and -- probably -- a desire for some degree of autonomy.

mindcrime 9y ago
rather than people who arrive with established ideas If those established ideas conflict with the prevailing mindset at $COMPANY and - more importantly - aren't objectively better by a sufficient margin, then it might make sense to not want that person around. Especially if they're going to spend a lot of energy and time creating conflict, arguing with other people, creating controversy, etc. and -- probably -- a desire for some degree of autonomy. I've been there, and in hindsight, I was an asshole about it. I've come to realize that if you're part of a team (and a company is a team of sorts) there are limits on how much autonomy you can really have. On the flipside, I believe the core responsibility of higher leadership is to create a vision and direction, and get people to buy into moving towards that vision, as opposed to simply leading by fiat. But if a given player is constantly rowing in the opposite direction, or even perpendicular, to the direction of everybody else, they're causing problems and you might actually be better off without them.