Compliance Theater: Why Your Corporate Standards Aren’t Driving Real Change

Large operating companies have a corporate team. Sometimes called operations support, technical excellence, a center of excellence, or a governance function whose job is to develop standards, best practices, and governance documentation for the sites that report up through the organization. The team writes the standards. The sites are expected to adopt them. Audits or self-assessments confirm compliance. The cycle repeats. 

If you’ve worked in or led one of these teams, you’ve watched the cycle break down in roughly the same way every time. The standards are technically excellent. The intent is right. The work that goes into them is real. But adoption is theatrical. Plants submit improvement plans on time. Boxes get checked. Audits pass. And on the ground, almost nothing actually changes. 

This is compliance theater, and it’s the default state of nearly every centrally governed corporate function I’ve encountered. This post is the diagnosis: why it happens, and what the root cause actually is. 

The Default Push Model 

Most corporate teams operate on what I call the push model. It looks like this: 

• Corporate develops a standard, often with limited input from the sites. 

• The standard is published with an expectation of adoption. 

• Sites are required to incorporate it into their local documentation. 

• Adoption is verified through audits or self-assessments. 

• Nonconformance findings trigger increased audit frequency, escalation, or corrective action plans. 

On paper, this looks like rigorous governance. In practice, it produces three predictable failure modes. 

Failure Mode 1: Orphaned Standards. The document gets written, signed off, published and then sits. Technically accurate, formally adopted, but never actually implemented in any meaningful way. The site has its own priorities, its own competing initiatives, its own resource constraints. The standard is real on paper and invisible in operations. 

Failure Mode 2: Compliance Theater. Improvement plans are submitted on schedule, but the plans reflect what governance wants to hear, not what’s actually happening at the plant. Sites become expert at managing the audit, not at adopting the standard. The improvement plan is a deliverable to the corporate team, not a roadmap for the site. 

Failure Mode 3: The Auditing Spiral. When a nonconformance event happens, the corporate response is to audit more frequently. More pressure. More documentation. More attention from the central team. The site sees this as additional burden, punishment, even rather than support. The relationship becomes adversarial. Adoption gets even harder. 

These three failure modes compound. Over time, the corporate team is perceived as something to be avoided, managed, or worked around. Not as a resource that helps the site succeed. 

The Underlying Perception Problem 

Step into the shoes of a site leader for a moment. You have a P&L to run, production targets to hit, a workforce to manage, safety incidents to respond to, regulatory obligations to satisfy, capital projects to deliver, and your own continuous improvement initiatives in flight. You are constantly competing for finite resources: time, money, people, attention. 

Now corporate hands you a new standard. From their seat, this is the obvious next priority. From your seat, it’s one more demand on a stack that was already overflowing. 

If you don’t see how the standard helps you hit your numbers, it’s additive. And additive work, by definition, gets pushed to the bottom of the list. 

This is the perception problem at the heart of every failed corporate initiative. Corporate teams that are perceived as additive will be avoided. It doesn’t matter how good the standard is, how much technical work went into it, or how clearly leadership communicated the expectation. If the site doesn’t see the corporate team as a force multiplier on their own goals, the standard will not be adopted in any meaningful way. It will be tolerated. 

The default push model practically guarantees this perception. The standard arrives without context. The audit shows up to verify compliance. The escalation happens when compliance falls short. From the site’s vantage point, every interaction with corporate is something being done to them, never for them. 

Compounding the problem: most large operating companies have multiple corporate teams pushing standards at the same sites simultaneously. Operations support, EHS, quality, IT governance, compliance, supply chain, sustainability; they all report to different corporate executives, all develop their own standards, and all believe theirs is the obvious priority. From the site’s seat, they’re not facing one corporate team’s expectations. They’re facing twelve. And often the same site SME is the touchpoint for several of those teams. Each corporate team is competing knowingly or not for the same finite local capacity. 

The Reframe: Push vs. Pull 

The fix isn’t a better standard, a better audit, or a better escalation process. The fix is a fundamentally different operating model. One where the corporate team is pulled in by the sites because they’re useful, instead of pushing standards that the sites resist. 

In a push system, the optimization is for the corporate team. Activities are the metric, standards issued, plans submitted, audits completed. Sites are the recipients of governance. Adoption is mandated. The relationship is adversarial because the incentives are misaligned. 

In a pull system, the optimization is for the receiver. Outcomes are the metric, site performance, gap closure, business results. Sites are co-owners of the governance. Standards exist because they solve real problems the sites need solved. Corporate is a resource that gets called in because it’s helpful not avoided because it’s additive. 

The shift is philosophical before it’s procedural. It changes who the corporate team is for. In a push model, corporate exists to enforce standards on the sites. In a pull model, corporate exists to help the sites get more value from their assets. 

The North Pole Analogy 

Here’s the way I describe the difference to corporate teams trying to make this transition. 

Imagine you’re sending someone on an expedition to the North Pole. 

The push approach sounds like this: “Here’s exactly how you’re going to get to the North Pole. Here are the steps. Here’s the timeline. Here’s the gear list. We’ll be auditing along the way — checking how much water you drank, whether you wore your hiking boots, whether you turned left when we said to turn left. Don’t deviate from the plan.” 

That’s how most corporate standards land at the site level. Prescriptive. Auditable. Disconnected from the conditions actually being faced. 

The pull approach sounds different: “Here’s what the North Pole looks like, and why getting there matters to the company. Tell us where you currently are — we don’t know your terrain, you do. As you encounter challenges, we have resources to help. When you hit the desert, we’ve already designed the canteen for that. When you hit the mountains, we have a guide who’s been there. If you encounter something we don’t have a resource for yet, work with us to develop one — because the next site facing the same challenge will benefit from what you’ve built.” 

In the second approach, corporate sets the destination and provides standardized solutions for known terrain. The site owns the route, the pace, and the day-to-day execution. The relationship is one of mutual usefulness, not enforcement. 

Shared Ownership of the Outcome 

Here’s the move that makes the pull model work: shared ownership of the outcome. 

Under a push model, corporate owns the standard and the site owns the adoption. They’re separate ownerships, and they often have separate incentives. Corporate gets credit for issuing the document. The site gets credit (or blame) for adopting it. Neither feels accountable for whether the underlying business problem was actually solved. 

Under a pull model, both parties own the outcome together. Corporate owns the development of the standard, the curation of best practices across the network, and the removal of systemic barriers. The site owns the gap analysis, the implementation plan, and the actual results. But they share accountability for whether the result was achieved. 

This sounds like a small distinction. It is not. It changes every conversation that follows. When both sides own the outcome, the standard isn’t a deliverable. It’s a tool both parties are using to solve a real problem. The standard exists because the site needs it, not because corporate wrote it. 

What Comes Next 

This is the diagnosis. Compliance theater is the symptom. The push model is the disease. A pull system is the cure. 

Making that shift is harder than it sounds. It requires changing who the corporate team is talking to (and who they’re not), how progress gets measured, what gets standardized and what doesn’t, and how the corporate function rebrands itself in the eyes of the sites. 

Two principles in particular deserve their own treatment, and the next two posts in this series go after them: 

• The most counterintuitive rule for corporate teams trying to operate without direct authority, the principle that your peer group is not your working group and what that means in practice. 

• The practical mechanisms of a pull system, governance charters, site-led review meetings, the one-issue-per-site discipline, and the measurement shift from compliance to behaviors and outcomes. 

If you’re running a corporate team that’s struggling to drive change at the site level, the answer isn’t more pressure. It’s a different operating model. Start by recognizing the pattern in your own organization. Compliance theater is rarely intentional, but it’s almost always the default. Naming it is the first step toward replacing it with something that actually works.