I wouldn't say so much that SRE has veto power. You call your Ops team an SRE team and tell them they have veto power with few other changes, and either the CEO

I wouldn't say so much that SRE has veto power. You call your Ops team an SRE team and tell them they have veto power with few other changes, and either the CEO is going to end the SRE experiment in a week when Dev and SRE are yelling at each other about getting product out the door, or the company will implode rather quickly from being dysfunctionally unable to ship. Rather, there is an error budget and if Dev violates the error budget then Dev has to go back to being responsible for Ops until they fix whatever was causing the product to go over its error budget. Without the ops-responsibility handoff between Dev and SRE, you just have an Ops team. This requires the org to both a) have shared language for defining errors and error budgets b) have some way of transferring control from SRE to Dev securely, without incurring additional downtime. That's more difficult than it sounds - going from Dev not having production credentials, to having production credentials, to losing them again when SRE takes the service back, all the while often using similar infrastructure e.g. managed databases which are backed up without Dev intervention etc. What most organizations get wrong is that SRE is a higher level of efficiency, not a foundational practice. It requires building out infrastructure to support the model. If you don't have it yet then you can't force it by slapping a label on it.