We launched our automated governance project on the heels of our company’s DevOps transformation. Times were good, people were motivated, and we were idealistic about what it meant to engineer great software at a highly regulated institution. We believed in things like developer freedom and flexibility, and we believed that we could bend the bureaucracy to our will. This was a fallacy and we had to abandon our beliefs in order to achieve our desired outcome: secure, compliant software, and a faster time to market. And all this had to be fully auditable.In this talk we aim to share our initial beliefs, which will sound familiar to the community because they’re derived from the ethos of the DevOps movement. But then we will talk about the things we learned along the way, and how they transformed our beliefs. Our goal is to share that it is okay to not be a perfect steward of the DevOps movement, especially in a highly regulated organization. Sometimes you need to change the game. Changing the game is contextual to each organization's needs. Our initial approach was the “carrot” instead of the “stick.” We engineered a great carrot and made it available to teams, but teams didn’t take the carrot because they could not see past their dominant incentive, which was to not change. After we realized this, we had to embrace the stick approach via the release process, and that’s how we changed the game. This was done with a restorative approach by giving teams a select way thru the process. Sometimes in large complex enterprises, this needs to be done by instinctive nature versus approved process. If it gets buy-in, at some point fake-it-to-make-it is required to get to the outcome. This doesn't come without its own set of risk, but neither does true transformation.