Governance: Great intentions, bad outcomes
How well-meant policies create friction, slow teams down, and damage trust when empathy is missing.
Governance is key to engineering. It automates checks, removes human error, and ships faster with more consistency and less debate. In theory, security requirements are built into pipelines, compliance rules serve as guardrails, and engineers receive instant feedback instead of waiting for reviews.
Platform and SRE teams love the clarity. Leadership loves the promise. Governance as code is finally scalable.
But in many organizations, governance-as-code becomes a mechanism of control rather than clarity.
Engineers experience broken pipelines with cryptic errors. Policies are enforced without context. Exceptions require tickets and approval chains longer than the blocked code. Teams start treating governance as an obstacle. Instead of improving safety and alignment, governance becomes a source of friction, resentment, and workarounds.
The promise vs the reality
The pitch for governance as code is always the same: “Let’s automate the rules so engineers don’t have to think about them.”
It’s a compelling vision. I’ve used this argument countless times.
And then Platform teams start the work: security rules become policy files, standards become reusable modules, CI checks enforce compliance long before anything reaches production. Instead of relying on tribal knowledge or outdated Confluence pages, teams get instant and objective feedback.
No more manual reviews. No more contradictory guidance. No more chasing down security or platform teams for clarifications.
But the reality engineers experience is very different. Nobody fully understands the policies, and new rules are constantly added. Error messages are frequently left as afterthoughts, forcing teams to reverse-engineer the policy. And when engineers don’t know why a rule exists, its legitimacy is questioned, and it becomes something to work around. And the Platform team’s lack of empathy doesn’t help.
What was meant to create consistency ends up creating frustration.
Why governance as code fails in practice
Governance is often viewed as a control mechanism, rather than an enabler.
Most organizations adopt governance-as-code to address inconsistencies or mitigate risk. And while these are legitimate goals, policies are written to prevent mistakes, not enable progress. Rules accumulate, each one added after an incident or audit finding.
And, suddenly, governance becomes synonymous with “no.” No longer a guardrail, just a gate.
Policies written in isolation
Security teams, platform teams, or architecture boards develop policies without a thorough understanding of how teams operate. A rule that seems simple in a document can become painful in a real-world delivery workflow.
For example, data governance officers may want to enforce that every new table in the data warehouse must have a label of the team that owns it. However, can the engineers tag all tables to a team? What happens when a team is restructured? When is a name change? When are the responsibilities shared? Engineers will struggle to pass the CI pipelines and add default owner labels solely to eliminate the error messages.
Moreover, engineers may experience CI failures that say things like: “This deployment violates policy X-443: Owner is unknown.” What does this mean?
Why does it matter? How do they fix it?
When governance is designed without the people who must use it, friction is guaranteed.
The systems are opaque
Governance-as-code creates invisible constraints baked into pipelines, platform libraries, or infrastructure modules. Engineers don’t know where a policy lives, who owns it, its purpose, how to request an exception, or how to provide feedback.
When they ask the Platform teams, they also don’t get the answers to their questions. For example, Terraform policies may disallow legitimate infra patterns. Why is that? Why is the Platform team deciding on the best pattern to use while not being exposed to the use case?
Worse, teams discover new rules only when their build fails. This creates resentment. Nobody wants to learn about new constraints by being blocked, especially late at night or close to a feature deadline.
Without transparency or appropriate communication, governance feels like an invisible hand pushing back. Engineers comply because they have no choice, but that doesn’t mean governance is a success.
Implementing governance that engineers accept
Governance only works when rules guide and inform engineers. Not block them.
Design policies with engineers
Instead of writing policies in isolation and based on supposed best practices, interview engineering teams about their pain points. Validate that the rule solves a real risk, not a theoretical one.
When engineers participate in shaping the rules, adoption becomes a natural process. Transparency over silos.
Make governance self-explanatory
Policies should feel like a well-designed API: documented, easy to understand, with clear examples and rationales, and a process for handling exceptions. This is to prevent engineers from having no idea why they exist. Adding context transforms enforcement into collaboration.
When implementing checks on CI pipelines, take the time to craft clear and concise error messages. Explain what is wrong, why, what risk it protects, how to fix it, or how to request an exception. Governance rules should not be too rigid. There will always be exceptions.
Observe before enforcing
Only enforce rules once adoption is high and workflows are stable. In the meantime, track where teams diverge, continue to communicate the good practices you advocate for, and enable teams to do the right things easily through templates or libraries.
Beginning with enforcement may feel faster and yield results more quickly for the governance team, but it will come at the cost of reduced engineer velocity and increased friction. Many governance approaches solve for one variable: control, but the real challenge is balancing risk reduction and friction reduction.
Governance becomes sustainable only when both improve at the same time. Otherwise, teams will find ways around the system. And you know they always do.
Conclusion
Governance-as-code is one of the most powerful ways to scale safety, compliance, and consistency across modern engineering teams. But when it’s rolled out as a control system, it becomes just another form of invisible friction.
Governance-as-code should provide clarity and context to engineers. Co-design policies, make sure teams understand the “why,” and be open to updating rules based on reality.
To prevent engineers from viewing governance as a gate, communicate effectively, build empathy into the process, and have a well-thought-out rollout plan.
So before you ship your next set of policies as pipelines, ask:
Does this rule reflect how teams actually work?
Would this rule still make sense if we weren’t enforcing it?
When governance works, nobody talks about it. It just quietly supports flow, safety, and scale. If governance makes work harder, the system isn’t governed. It’s broken. So will you spend time reviewing your approach to governance?