[mancerayder]

Understood, but so far what I observed is the embedded devops pressured/saying Yes/beholden to a PM running sprints, and the central infra team management constantly has to intervene to protect the embedded devops engineer politically.

Maybe my experience is a rare example, but my conclusion so far is that it's tricky to prevent this painful situation, and requires vigilance.

[raw_anon_1111]

And once you have the infra team saying no all of the time and being antagonistic - you’re back to old school operations and you aren’t a DevOps shop.

[mancerayder]

But if they never say no, how do you maintain central infrastructure standards?

If you say yes all the time, I feel like that's how you turn devops into Ops monkeys who are reactive, since people are operating on Sprint timelines instead of optimizing for long-term stability.

[raw_anon_1111]

Looking through the AWS lens because that’s the one I know.

The goal of the centralized ops team is to put just enough guardrails on the Organization (a group of AWS accounts) to keep the company in compliance - no public access S3 buckets, no one has organization::* permissions, set budget limits per account or organizational units etc, establish budget thresholds (or in the case of Isengard - AWS’s account vending machine - you can do almost anything except spin up an Oracle DB) . Let each team be responsible for their own deployments, monitoring, etc. For the most part, the top level operations department should be responsible for the Organization, setting up service control policies, Security monitoring and then the embedded DevOps person should be an SME not the department of “no”.

If you make the dev team a long with the embedded ops person responsible for their account/monitoring and they get called once a twice, they will figure it out