Politics is the worst part of the job, not the only part of the job. The job has also good parts and boring parts and meh parts.
With your experience, you might be fine business analyst on customers projects. Talking with customers, dealing with their politics and then turning all that into consistent set of requirements. That last part is something you would have to learn.
I also think there's an inherent bias to complains about "internal politics" in a software job. For the most part, the people complaining about that have only ever worked in software jobs.
If you mechanically translate "internal politics are a bad part of software jobs" to "internal politics are a bad part of all jobs with more than 2 people", it mostly goes away (IMO). It's possible that software engineers are slightly worse at or less tolerant of politics, but I don't see a particular excess of politics in software vs other fields. (We are a multi-discipline company, sales, marketing, manufacturing, R&D, software, call centers, supply chain, etc. All of them have more than 2 people and therefore all of them have some amount of politics.)
I partly agree, but the lack of autonomy and no ability to do independent decisions/responsibility you have in agile teams (unless you constantly fight for it) makes politics much worst compare to the jobs where you have clear role/responsibility in the team.
The again, it is still much better then middle management in big corporation or something similar.
Yes, middle management in big corporations often has very complex politics. I rather enjoy getting things done in spite of that, and manipulating the politics in favor of advancing an agenda that will benefit the organization. It wears me out, which is why I usually leave after about five years for a new playing field. (I have never had an interest in advancing to the executive level, where the politics are not at all to my taste.)
>>With your experience, you might be fine business analyst on customers projects. Talking with customers, dealing with their politics and then turning all that into consistent set of requirements. That last part is something you would have to learn.
This is a great suggestion, and I have had similar thoughts in the past. What would be the best way to go about learning how to create a consistent set of requirements? Actually work on a few software projects writing code, or something different?
With your experience, you might be fine business analyst on customers projects. Talking with customers, dealing with their politics and then turning all that into consistent set of requirements. That last part is something you would have to learn.