Pick your battles. Not only is it exhausting to make everything a fight, but people will appreciate it more, and be on your side more, if you pick only the important things to stand your ground on.
Make friends. There will be people who feel the same way, finding them is usually good to get things done quickly. It can be important also to break down the team barriers. Requiring a different team to accomplish something is a big part of friction, and knowing individuals in those teams that get stuff done can help. The way to get them on side is to make their jobs easier, and again picking your battles and compromising are good ways to do this.
Get buy in on big changes. So this is different from making friends. You need to develop people that agree that a change needs to happen, and on a way of making that change. I'd start small, with convincing Individual Contributors first, particularly if there are very well respected ones. Then seeking out management and building the case that the changes will improve their situation. This can be a slow process. Managers will appreciate it if it can seem like their project, and once it does, you'll have their backing because they don't want it to fail.
All that said, there are certainly places where this sort of friction is minimal, usually remote devops driven start-ups or consultancies.
I'd use buzz words also, to help make your case. The whole DevOps shift comes with some principles that you can wield to make the case that infra changes should belong in the team, and CI/CD and similar require that VMs (well, pods really) be spun up easily, and from an API.
Pick your battles. Not only is it exhausting to make everything a fight, but people will appreciate it more, and be on your side more, if you pick only the important things to stand your ground on.
Make friends. There will be people who feel the same way, finding them is usually good to get things done quickly. It can be important also to break down the team barriers. Requiring a different team to accomplish something is a big part of friction, and knowing individuals in those teams that get stuff done can help. The way to get them on side is to make their jobs easier, and again picking your battles and compromising are good ways to do this.
Get buy in on big changes. So this is different from making friends. You need to develop people that agree that a change needs to happen, and on a way of making that change. I'd start small, with convincing Individual Contributors first, particularly if there are very well respected ones. Then seeking out management and building the case that the changes will improve their situation. This can be a slow process. Managers will appreciate it if it can seem like their project, and once it does, you'll have their backing because they don't want it to fail.
All that said, there are certainly places where this sort of friction is minimal, usually remote devops driven start-ups or consultancies.
I'd use buzz words also, to help make your case. The whole DevOps shift comes with some principles that you can wield to make the case that infra changes should belong in the team, and CI/CD and similar require that VMs (well, pods really) be spun up easily, and from an API.