Invest in people understanding the reasons for something, and allow them to ensure it's upheld. A relevant domain-less software analogy is testing; you can mandate some level of testing, and it will be a burden, a morale killer, and constantly fail to be upheld, or you can work to ensure everyone understands the benefits of testing, create space for people to write tests and automate their execution, and then rely on culture to ensure testing happens. I've been in places that tried to mindlessly mandate corporate policies to ensure compliance; it resulted in delays and low morale, and extremely patchwork adherence (I left that place still not knowing if we were compliant or not). I've also been at a place that implemented SOX compliance; they didn't mandate anything, just "we're becoming part of a publicly traded company. Here is what the goal is. Here is some training to help understand what sorts of things we now need to be mindful of. Here is a person who you can talk to to help understand what that means for you. This is our highest priority right now". Morale stayed high, the results were good, and completion was -early-.

>> as soon as something requires a budget

Everything requires a budget. Headcount is a budget. The point is give people problems to solve, the relevant constraints, and let them work, rather than micromanage the solution. Maybe that's an industry failure, but don't confuse it for a unique constraint on that industry, rather than just a universal problem in that industry.

>> And maybe you can have fewer rules, but instead they will be labelled processes

Process exceptions exist. Rule breaking exists. And failure to break process/rules when you should have happens too. The point isn't to not have a sensible default, but to instead arm people with knowledge so that they pick the default when it makes sense to, and deviate when it makes sense to. It's the same distinction around "best practices"; they're not, they're just reasonable defaults. And by not dictating a process, you allow evolution in the de facto process the teams follow, to improve the process. I've seen companies attempt to revamp their internal processes from a top-down model: universally not pretty. I've also seen teams and departments retro and iterate, and see constant improvements.