When a team has a useful idea, it should be able to find out how to build, test and release it. That is a reasonable test of whether the operating model works.
I have worked on both sides of this problem: accountable for enterprise technology, and building solutions that need a route into use. The tension is real. A document review tool can be ready to test while access, ownership and release arrangements are still being worked out.
Give different work different routes
A bounded task using approved material, with a person checking the result, may suit a fast path. A service that changes core records or carries a business-critical dependency needs deeper engineering and assurance. Define the distinction before the team starts building.
Both routes need an owner, acceptance criteria and a support arrangement. The depth of the work changes with the consequences. Teams should know what would trigger a move to the enterprise route.
Make the controls available to the builder
Policy becomes useful when it informs the starting template, the data permissions and the release checklist. Provide an approved pattern the team can use. Include example tests, the publishing steps and the person who can resolve a decision.
Track waiting time as well as build time. If business review takes longer than development, agree how and when the owner will participate. That can matter more to delivery speed than another tool.
Use live delivery to improve the model
The first few builds will expose gaps. Record the decisions and turn them into reusable standards. Keep a shared record of what is running, who owns it and what it costs. Give the next team a better starting point.
For leaders, the question is whether the approved route helps good work reach users with the right evidence and ownership. If teams have to assemble that route for every initiative, there is operating-model work to do.