Wow, I am floored at so many comments painting an egocentric view of the author. I find it highly ironic that supposedly high EQ neurotypicals would not be able to take one small step back and evaluate what is written with a modicum of assumed good intent.
Take this example:
> A manager came to me asking if we should rewrite the checkout of our E-Commerce platform using React because they had read a blog post about another company doing it.
> [...]
> In this particular situation, the discussion never got past the first question.
My reaction to this is, yes obviously an engineer should be asking these questions, and it's a huge red flag that the manager didn't entertain even the first one. Obviously we don't have that managers side of the story, so I take it with a small grain of salt, but on the other hand the issue is articulated very clearly, and it is decidedly not personal or egocentric. In fact the questions are exactly what I as an EM expect my senior ICs to be asking. This demonstrates ownership and good thinking about the overall cost and impact of resourcing decisions. Good systems can not be built by managers dictating things without buy in from the expert ICs who actually build and maintain them. Therefore I think it's completely bass-ackwards that we would ding the IC for a communication gap (regardless of neurotype)—I've seen far too many cases of teams just doing what they're told and driving off a cliff because everyone prioritized agreeability and had a very narrow view of their own responsibilities. When the shit hit the fan everyone just throws their hands in the air and says "not my job".
So let me first say, kudos to you larve, you are the type of engineer I want on my team.
Now that said, some feedback. Describing office politics as "playing mind games" does you no favors in terms of being understood. I know what you mean—office politics often involved bending over backwards and dancing around issues to avoid offending people. This is not my idea of fun either. That said, morale matters, and this song and dance is a big part of how morale is managed for allistic people. Furthermore, there is a fundamentally difficult issue which is if you have 100 smart people, building consensus through complete understanding is impossible. At some point owners need to be identified, decisions made, and progress begun. Some people will need to "disagree and commit" with partial understanding. Given your experience I don't expect you would disagree with that in any way, but when folks are short with you, consider the difficulty of reaching such consensus. I don't think it's an excuse for shortcuts, but this is the art of technical management, and it requires hard work and a commitment to building trust and understanding from all parties to have any hope of realizing large scale technical achievements.
I actually love "office politics" when people engage in it in good faith. I love crossing team boundaries, figuring out who is not talking to whom, who works well with certain kind of people. I love running good meetings and making sure everybody is heard. I love writing and editing documents, cleaning up meeting notes, I am happy writing whatever shitty glue I need to to make other people's work smoother.
I think office politics is just a derisive name for the very important work of having lots of people of different backgrounds work with each other towards a same goal. I've come to understand that my biggest technical capability as an engineer is to play office politics well. Organizing a single meeting between two people (or conversely, making sure two people never have to code review each other) can be the difference between a dead project and a successful one.
The "mind games" is specifically about getting me to say something I can't stand behind. I am fine doing things I can't stand behind, because I'd rather get something janky shipped than nothing at all, and I will do so without complaining, in fact I enjoy it. But don't expect me to say something I don't mean, I'd rather say nothing at all. I have two anecdotes come to mind. One is a colleague not wanting to use the API I provided to store configuration files (an API I provided so they wouldn't have to deal with the versioning, saving to flash safely, validation and encryption), instead repeatedly bringing up in the public slack channel how I should KISS and that writing a file is really not a complicated thing (it kind of is, especially in an embedded system). I don't really care too much about engaging with people calling me stupid in public, and I'm certainly not going to say that writing a file is simple.
I also care very much about other more junior engineers not getting bullied by older engineers. Junior engineers might not be very nuanced in their opinions, or might need to learn a few lessons the hard way, but that is not done by playing the authority card, that is done by providing a safe space for them to discover these things on their own (be it by mentoring, by watching more experienced people do it, or by giving them enough ownership to be able to make a few mistakes without impacting the business).
> The "mind games" is specifically about getting me to say something I can't stand behind.
Cool, that's a great clarification. I agree with that characterization of "mind games", and its obviously 100% legitimate to stand your ground in those cases.
One reason I think these things happen is because people go straight from school to the corporate world where they expect to be told what to do and never develop their own agency and feedback loops for higher level goals. In a big org it can be hard to see the forest for the trees. Silicon Valley youth worship doesn't help either as it takes time to get enough experience to learn the myriad different ways things can succeed and fail. Young managers often feel they need to have all the answers and control everything rather than realizing the job is really about understanding individual strengths and giving everyone the right incentives and well-defined goals (appropriate to their competence level) to work together and produce output greater than the sum of the parts.
Take this example:
> A manager came to me asking if we should rewrite the checkout of our E-Commerce platform using React because they had read a blog post about another company doing it.
> [...]
> In this particular situation, the discussion never got past the first question.
My reaction to this is, yes obviously an engineer should be asking these questions, and it's a huge red flag that the manager didn't entertain even the first one. Obviously we don't have that managers side of the story, so I take it with a small grain of salt, but on the other hand the issue is articulated very clearly, and it is decidedly not personal or egocentric. In fact the questions are exactly what I as an EM expect my senior ICs to be asking. This demonstrates ownership and good thinking about the overall cost and impact of resourcing decisions. Good systems can not be built by managers dictating things without buy in from the expert ICs who actually build and maintain them. Therefore I think it's completely bass-ackwards that we would ding the IC for a communication gap (regardless of neurotype)—I've seen far too many cases of teams just doing what they're told and driving off a cliff because everyone prioritized agreeability and had a very narrow view of their own responsibilities. When the shit hit the fan everyone just throws their hands in the air and says "not my job".
So let me first say, kudos to you larve, you are the type of engineer I want on my team.
Now that said, some feedback. Describing office politics as "playing mind games" does you no favors in terms of being understood. I know what you mean—office politics often involved bending over backwards and dancing around issues to avoid offending people. This is not my idea of fun either. That said, morale matters, and this song and dance is a big part of how morale is managed for allistic people. Furthermore, there is a fundamentally difficult issue which is if you have 100 smart people, building consensus through complete understanding is impossible. At some point owners need to be identified, decisions made, and progress begun. Some people will need to "disagree and commit" with partial understanding. Given your experience I don't expect you would disagree with that in any way, but when folks are short with you, consider the difficulty of reaching such consensus. I don't think it's an excuse for shortcuts, but this is the art of technical management, and it requires hard work and a commitment to building trust and understanding from all parties to have any hope of realizing large scale technical achievements.