The Governance Theater Problem
Imagine this - your CTO announces a major cloud governance initiative. Super critical to the business, all hands on deck, yada yada yada.
Six months later, you have a 60-page policy document, monitoring dashboards generating 1,000+ alerts per week, and a SharePoint site full of standards that developers have bookmarked but never actually read.
Sound familiar?
This is governance theater - a classic example of "work as imagined vs. work as done". It looks impressive from the executive level, but teams on the ground know it's completely disconnected from how they actually work. The real kick in the teeth? Most of these governance programs fail because they're built with a bureaucratic mindset trying to control a generative technology.
Why Traditional Governance Breaks in the Cloud
Traditional IT governance worked (for some value of "worked") when deploying a server took three weeks and changing a firewall rule required approval from the bi-weekly CCRB. The slow pace meant cumbersome and heavy processes could keep up. Rules, approvals, and documentation made sense. Or at least they didn't get in the way too much.
The cloud flipped this model upside down - the Jevons paradox in full effect. Developers can now spin up entire environments in minutes, auto-scale based on demand, and deploy code dozens of times per day. The old governance playbook doesn't just slow things down anymore. It breaks them completely.
Here's what happens when bureaucratic governance meets cloud velocity
Information Flow Problems: Critical security findings get buried in noise because there's no way to distinguish between "fix this now" and "fix this eventually." Teams ignore most alerts because the signal-to-noise ratio is terrible. Our old friend normalization of deviance rears its familiar head.
Ownership Confusion: When something breaks, nobody knows whose responsibility it is to fix it. The cloud's shared responsibility model collides with traditional departmental silos.
Process Overhead: By the time a security exception gets approved through the proper channels, the project has already shipped to production three times.
This is where Ron Westrum's research becomes incredibly relevant. Westrum studied organizational culture in high-risk, high-tempo environments like aviation and healthcare. He found that organizations fall into three cultural types, and the type directly predicts how well information flows through the organization.
Cloud Governance meets the Westrum Model
Pathological (Power-Oriented): Fear dominates decision-making. Teams hoard information, cover up problems, and focus on self-preservation. Cloud governance becomes about blame assignment and political maneuvering.
Bureaucratic (Rule-Oriented): Following the process matters more than achieving the outcome. Each department protects its turf and insists on its own rules. Cloud governance becomes a collection of disconnected policies that teams work around rather than with.
Generative (Performance-Oriented): The mission comes first. Teams collaborate across boundaries, share risks, and treat failures as learning opportunities. Cloud governance becomes an enabler that helps teams move faster while staying secure and compliant.
The research is clear: generative cultures don't just feel better to work in; they deliver better business outcomes. And business outcomes are why we are here, right? Companies with generative cultures have higher software delivery performance, better organizational performance, and more satisfied employees. And research shows they are funnier and more popular with their friends (research may not actually show this last part).
CALMS: The Cultural Operating System for Cloud Governance
The CALMS model gives us the foundation for building generative governance. CALMS represents the key tenets and foundational principles of DevOps (if you prefer, you can use the acronym CLAMS; I'm not here to judge you).
If these principles can transform how development and operations teams work together, they can also transform how governance works. Roll out!
Culture: Shared Responsibility Over Departmental Silos
Instead of the governance team owning all policies while engineering teams follow them, create cross-functional teams responsible for each of the 5 Pillars. Your security pillar team should include security professionals, platform engineers, and application developers. Your cost pillar team should include FinOps practitioners, engineering managers, and product owners.
This breaks down the "us versus them" dynamic that kills most governance programs. When the people who have to live with the policies help create them, you get policies that actually work in practice. It's like magic (with fewer sparkly vests).
Automation: Policy as Code Over Process Documents
Documentation-heavy governance fails because it can't keep up with cloud velocity. Teams need governance decisions at code-commit time, not committee-meeting time.
Move your governance policies into code. Security baselines become Terraform modules. Cost controls become automated budget alerts and resource right-sizing. Compliance requirements become pipeline gates that provide immediate feedback.
When governance is automated, it becomes invisible to teams when they're doing the right thing and immediately visible when they're not. The mantra for success here is "make the right way the easy way".
Lean: Value Stream Thinking Over Approval Chains
Traditional governance optimizes for risk avoidance. Generative governance optimizes for value delivery while managing risk intelligently.
Apply lean thinking to your governance processes. Map the value stream from "developer wants to deploy something" to "secure, compliant workload running in production." Identify waste, eliminate unnecessary handoffs, and remove approval steps that don't actually reduce risk.
The goal isn't to remove all controls. It's to remove controls that create friction without creating safety, and to implement controls that create safety without creating friction. Often times, we are focused on our small slice of the flow, and it's always beneficial to zoom out to the entire stream.
Measurement: Leading Indicators Over Compliance Theater
Most governance programs measure lagging indicators like "number of policy violations found during audit." By the time you measure these, the damage is already done.
Generative governance focuses on leading indicators that predict problems before they happen. How long does it take teams to get security exceptions? How often do cost alerts lead to actual cost reduction? How many governance policies have teams automated away versus worked around?
Measure governance effectiveness by measuring whether it helps teams move faster or just creates more overhead. And make sure you don't have bloat on "feel good" metrics that don't drive any improvement or change.
Sharing: Transparent Information Over Information Hoarding
Bureaucratic governance treats governance information as something to be controlled and dispensed carefully. Generative governance makes governance information radically transparent.
Create public dashboards showing security posture, cost trends, and operational health across all teams. When everyone can see the same data, you eliminate the political games and focus on solving actual problems.
Share governance successes and failures openly. When the platform team figures out how to automate compliance for PCI workloads, that knowledge should spread to every team, not stay locked in one department. Success breeds success - teams will see others having improvements and want that for themselves.
What This Looks Like in Practice
Before: A security team creates a 40-page cloud security policy. Teams ignore it. Security violations accumulate. Quarterly audit finds hundreds of issues. Finger-pointing ensues. Nothing improves. There is much wailing and gnashing of teeth.
After: Security and DevOps teams collaborate to embed security policies directly into infrastructure templates. Teams get immediate feedback when they violate policies. Most violations get auto-remediated. Manual violations trigger helpful guidance, not punishment. Security posture improves continuously. Teeth-gnashing is reduced by 96%.
Before: Finance gets a shocking cloud bill. They demand cost controls. IT implements manual approval processes. Innovation slows to a crawl. Shadow IT proliferates. Costs actually increase. The CFO's corporate card gets declined and the entire AWS infrastructure shuts off.
After: Cost policies are embedded in infrastructure automation. Teams get real-time feedback on spending. Optimization recommendations appear automatically. Cost accountability is clear and immediate. Teams self-optimize because they can see the impact. CFO treats the cloud team to a pizza party.
The Transformation Playbook
Start with Culture Assessment: Where is your organization today? Use Westrum's model to honestly assess whether your governance culture is pathological, bureaucratic, or generative. Most organizations discover they're more bureaucratic than they thought.
Pick One Pillar: Don't try to transform everything at once. Pick the pillar where you have the most pain and the most organizational support for change. Security and cost are often good starting points.
Apply CALMS Principles: For your chosen pillar, deliberately apply each CALMS principle. How can you make the culture more collaborative? What manual processes can you automate? How can you eliminate waste? What should you measure? How can you share information better?
Build Feedback Loops: Implement mechanisms to measure whether your governance changes are actually helping teams move faster while staying secure and compliant. If governance changes don't improve both velocity and control, they're not working.
Scale What Works: Once you've proven the approach on one pillar, expand to others. The cultural changes you make will compound across all areas of governance.
The Bottom Line
Cloud governance isn't failing because teams don't want to follow rules. It's failing because we're applying bureaucratic solutions to generative problems.
When you build cloud governance using the same cultural principles that make DevOps successful, something interesting happens. Governance stops being something teams work around and becomes something they work with. Security improves, because controls are consistent and automated. Costs become predictable, because spending is visible and controlled. Compliance shifts from quarterly fire drills to continuous confidence (wait, did I just coin a new industry buzzword?).
The cloud demands governance that moves at cloud speed (vroom vroom). That means governance built on generative culture, collaborative ownership, intelligent automation, and continuous improvement.
Your governance framework should enable teams to move fast and stay safe. Not force them to choose between the two.
The CloudGovernance.org framework gives you the 5 Pillars to define what you govern. DevOps culture gives you the principles to govern it effectively. When you combine them, you get governance that actually works.
What's your governance horror story? Drop a comment about the most bureaucratic, useless, or downright bizarre governance process you've encountered in the cloud. Bonus points if you've successfully transformed it into something that actually helps teams move faster.