"Team player" is one of those things that seems to go along with other, almost contradictory things like "self-starter" and "takes ownership". In theory, they

"Team player" is one of those things that seems to go along with other, almost contradictory things like "self-starter" and "takes ownership". In theory, they can be good things. In practice, it feels like they're often just used to justify poor decisions while "blaming the victim". If someone wasn't willing to work long hours for free to build better tooling to support the project, then she's "not a self-starter". If someone feels strongly about using a certain tech stack or architecture on a project and doesn't just go along with the old PHP 5.x or Python 2.x stack the company has always used, then she's "not a team player". To some extent, caring enough about your projects that you're willing to work the occasional weekend means ALSO caring enough about your project to have a say in the choices that are being made, or being unwilling to accept something as it is when you think it could be much better. It means getting frustrated when the feedback you are presumably being paid to provide goes unacknowledged. You can just not care, and show up, do the minimum amount of work and go home, but presumably managers don't want that out of their top tech talent. I'm not saying traits like "team player" and "self-starter" are mutually exclusive traits, but they also have consequences. They shouldn't be code for "just do what we ask of you". What I find a bit annoying from this article's feedback, though, is how many engineers seem happy to ALSO take these terms and weaponize them against their colleagues' opinions.