Hopefully others will jump in with answers more relevant to your situation. I work mainly in a startup and small-company context because the customer and business realities are more prominent than the political situation. In my mind's eye, I see companies as opaque spheres of different sizes. The bigger they get, the farther the average person is from the external reality, and so the less that reality matters.
I also think this is tied in with current American managerialist culture. The notion of controlling work by setting arbitrary hurdles and deadlines is so pervasive that many people can't imagine an alternative. This very easily turns into pure fantasy, even on the billion-dollar scale. [1] I expect that there are plenty of companies that would literally go out of business before they would change their ways.
So in your shoes I'd take a hard look at your company and ask what its true values are. If they really value appearance over results, politics over substance, dominance over cooperation, then I don't think that's something you can change on your own. I'd personally try to find someplace better, and if I couldn't then I'd mainly play to survive, not to win.
But if you think the company has its heart mostly in the right place, then in your shoes I'd start with weekly team retrospectives. [2] [3] Each week, you'll make note of problems and possible solutions. Each week you try to make things incrementally better. And gradually you'll build up solid data to say things like, "For the last quarter, the most common thing in team X's weekly top 3 productivity drains has been insufficient contiguous time to focus. If you want us to go faster, please help us to limit meetings and interruptions to the mornings for the next quarter as an experiment."
If possible, I also strongly recommend finding ways to ship early and often. The longer managers go without experiencing actual progress, the crazier they get. If you release new business value at least weekly, then they'll focus much more on picking what's next then on yelling at people. At my last startup, even with a small team, we were releasing a few times a day. That meant that the CEO wanted something urgently, he could always get it soon just by telling us what thing currently in progress was less urgent. He always felt in control. It also meant that he was kept busy looking at new results and thinking about what came next; he didn't have time to fuss much with our work.
Related to that is building cross-functional teams. To me, a team is a group of people that win and lose together, a group that can play the game basically on their own. So I'll try to put a few developers physically together with a designer and a product manager and whoever else is vital. If PMs think of themselves as their own team, then it's hard to counteract those bad incentives. But if the PM only wins when the project and the rest of the team wins, they'll be much more collaborative.
And I'd also encourage you to make good use of every disaster that comes your way. The best luck I've had changing culture and process has always come when there's some mega-fuckup that's fresh in people's minds. That's especially true when you already have a successful small-scale example going. E.g., I remember one retrospective after a team spent 9 months building a big upgrade that was a flop. One of their peer teams was at that point releasing every few days and quickly responding to business data: killing bad ideas quickly, doubling down on the good ones. The pain of failure plus the envy of colleagues doing well was a powerful combination.
Sorry for the ramble in reply, but basically my answer is: as problems present themselves, solve them in ways that move you toward greater agility. By which I mean more frequent releases, faster feedback loops, closer collaboration, less work in process, more responsive to business and customer needs. To it continuously on a small scale and regularly at the large. If you can make a 1% weekly improvement, things will be 68% better by the end of the year, and 181% better at two years.
Does that help? If not, feel free to reply here or email me. Glad to help as I can.
I also think this is tied in with current American managerialist culture. The notion of controlling work by setting arbitrary hurdles and deadlines is so pervasive that many people can't imagine an alternative. This very easily turns into pure fantasy, even on the billion-dollar scale. [1] I expect that there are plenty of companies that would literally go out of business before they would change their ways.
So in your shoes I'd take a hard look at your company and ask what its true values are. If they really value appearance over results, politics over substance, dominance over cooperation, then I don't think that's something you can change on your own. I'd personally try to find someplace better, and if I couldn't then I'd mainly play to survive, not to win.
But if you think the company has its heart mostly in the right place, then in your shoes I'd start with weekly team retrospectives. [2] [3] Each week, you'll make note of problems and possible solutions. Each week you try to make things incrementally better. And gradually you'll build up solid data to say things like, "For the last quarter, the most common thing in team X's weekly top 3 productivity drains has been insufficient contiguous time to focus. If you want us to go faster, please help us to limit meetings and interruptions to the mornings for the next quarter as an experiment."
If possible, I also strongly recommend finding ways to ship early and often. The longer managers go without experiencing actual progress, the crazier they get. If you release new business value at least weekly, then they'll focus much more on picking what's next then on yelling at people. At my last startup, even with a small team, we were releasing a few times a day. That meant that the CEO wanted something urgently, he could always get it soon just by telling us what thing currently in progress was less urgent. He always felt in control. It also meant that he was kept busy looking at new results and thinking about what came next; he didn't have time to fuss much with our work.
Related to that is building cross-functional teams. To me, a team is a group of people that win and lose together, a group that can play the game basically on their own. So I'll try to put a few developers physically together with a designer and a product manager and whoever else is vital. If PMs think of themselves as their own team, then it's hard to counteract those bad incentives. But if the PM only wins when the project and the rest of the team wins, they'll be much more collaborative.
And I'd also encourage you to make good use of every disaster that comes your way. The best luck I've had changing culture and process has always come when there's some mega-fuckup that's fresh in people's minds. That's especially true when you already have a successful small-scale example going. E.g., I remember one retrospective after a team spent 9 months building a big upgrade that was a flop. One of their peer teams was at that point releasing every few days and quickly responding to business data: killing bad ideas quickly, doubling down on the good ones. The pain of failure plus the envy of colleagues doing well was a powerful combination.
Sorry for the ramble in reply, but basically my answer is: as problems present themselves, solve them in ways that move you toward greater agility. By which I mean more frequent releases, faster feedback loops, closer collaboration, less work in process, more responsive to business and customer needs. To it continuously on a small scale and regularly at the large. If you can make a 1% weekly improvement, things will be 68% better by the end of the year, and 181% better at two years.
Does that help? If not, feel free to reply here or email me. Glad to help as I can.
[1] For example, the dumbfounding mess in Mississippi, which we know about because of one stubbornly honest engineer: http://www.nytimes.com/2016/07/05/science/kemper-coal-missis...
[2] A good book is Larsen and Derby's Agile Retrospectives: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Gre...
[3] Also handy is the Retromat: http://plans-for-retrospectives.com/