Two opposite failures
There are organisations where choosing the size of a server requires a director's signature. And there are others where each team picks provider, region and tooling without asking anybody. The first are slow; the second, incoherent. Both have the same problem: it is not written down what gets decided at each level.
Three levels, three rhythms
Strategic. Decisions that set the direction and change rarely: which providers you work with, what level of risk is accepted, what principles guide the architecture, how much budget is allocated. They are reviewed infrequently (quarterly, for instance) and taken by the board.
Tactical. Decisions that turn direction into rules: the standard, the reference architectures, the approval of exceptions, the review of designs. They have an intermediate rhythm (monthly, for instance) and are taken by each domain's owners.
Operational. Day-to-day decisions that fit inside the standard: which instance size, when to deploy, how to resolve an incident. They are taken by the teams, without asking permission, because the standard already tells them what they can do.
The rule that holds it together
A decision is taken at the lowest level where it fits. If a change complies with the standard, the team decides. If it needs to step outside it, it goes up a level as an exception. If it challenges a principle, it goes up to the strategic level.
And every decision at the upper levels is written down (like the decision records in the architecture series), so that the lower levels know where they stand without asking every time.
Escalating without drama
Escalating is not a failure, it is a procedure: you describe what you want to do, which rule prevents it and why you believe it should be done anyway. Whoever receives the escalation answers within a known period.
With who decides what now defined, the central piece of all governance is the document that separates the permitted from the rest: the standard.
How we apply it: Multicloud Governance.