IT governance has a reputation problem. Mention “governance framework” to most developers and watch their eyes glaze over. They’re thinking about change advisory boards that meet weekly to approve routine deployments, architecture review processes that take months, and policy documents nobody reads.

That’s because most IT governance is implemented badly. It becomes bureaucracy for its own sake, divorced from the actual risks it’s meant to manage. People bypass it whenever possible, which defeats the entire purpose.

Good governance is different. It provides genuine value, operates at the right level of abstraction, and feels like helpful structure rather than obstacles. Getting there requires rethinking what governance is actually for.

What Governance Should Accomplish

The point of IT governance is to ensure technology decisions align with business objectives, manage risk appropriately, and allocate resources effectively. That’s it. Not to slow everything down, not to centralize all decisions, not to create approval checkpoints.

Every governance mechanism should answer the question: what bad outcome are we preventing, and is this control proportional to that risk? If you can’t articulate the specific risk being managed, you don’t need the control.

At our organization, we used to require architecture review board approval for any new technology adoption. This made sense when we were smaller and technology decisions were rare. Once we hit a certain scale, it became a bottleneck. Teams waited weeks for meetings. The board couldn’t meaningfully evaluate every decision. People started bypassing the process.

We replaced it with a risk-based approach. Low-risk decisions (adopting a new monitoring tool, changing a deployment tool) don’t require approval. Medium-risk decisions (new cloud service, new programming language) require an architecture consultation but not formal approval. High-risk decisions (new database platform, major infrastructure change) still go through formal review.

This works because the governance overhead matches the actual risk. Teams don’t feel like they’re fighting bureaucracy for trivial decisions, so they actually engage with the process for important ones.

Decision Rights and Escalation Paths

Clear decision rights prevent most governance problems. When everyone knows who can make which decisions, you don’t need approval processes for everything.

We use a RACI-style framework, but simpler. For each category of decision, we define who has authority to decide, who must be consulted, and who must be informed. For example, individual developers can choose testing frameworks and libraries within approved languages. Tech leads can choose deployment approaches within approved platforms. The architecture team decides on new infrastructure platforms.

This eliminates most of the “I need approval to proceed” situations because people know their decision authority. When escalation is needed, the path is clear.

The critical part is giving people real authority at their level. If developers theoretically have decision-making power but in practice everything gets second-guessed, they’ll stop making decisions and start asking permission for everything. That creates bottlenecks and teaches learned helplessness.

Standards vs. Standardization

Standardization is often used to justify governance overhead, but there’s a difference between useful standards and forced uniformity.

Useful standards solve real problems. Using the same identity provider across all systems means single sign-on works. Standardizing on observability platforms means consistent monitoring. Agreeing on API design principles enables easier integration.

Forced uniformity creates problems. Mandating one programming language for all projects ignores that different problems have different optimal solutions. Requiring all data processing to use the same tool creates artificial constraints.

The test is whether the standard makes individual teams more productive or less productive. If teams are fighting the standard to get work done, it’s probably wrong. If teams appreciate having decisions made for them so they can focus on building things, it’s working.

Lightweight Architecture Review

Architecture review doesn’t need to be a formal board meeting with PowerPoint presentations. Most architecture concerns can be addressed through lightweight peer review.

We require that architecture decision records (ADRs) be written for significant decisions and reviewed by at least two other senior engineers before implementation. The review happens asynchronously in document comments. It takes days, not weeks. The focus is on identifying risks and alternatives, not on gatekeeping.

For decisions that need broader input, we do architecture consultations. The team building something schedules an hour with relevant technical leaders, walks through their approach, gets feedback, and incorporates it. No formal approval, just informed input.

This works because it’s designed to add value rather than control. Teams want the input because it helps them avoid mistakes. If it felt like an obstacle, they’d work around it.

Policy Documentation

Most policy documents are useless because nobody reads 50-page PDFs. Policy needs to be embedded in workflow, not separate from it.

Our security policies are documented as code wherever possible. If you violate a policy, the CI/CD pipeline fails and tells you why. The policy is enforced automatically, and the documentation is in the error message. This is better than a PDF that says “developers must not commit secrets to git” that everyone ignores until the breach happens.

For policies that can’t be automated, we document them as decision trees. “Should I do X?” leads to a series of yes/no questions that result in a clear answer. This is much more useful than prose paragraphs describing principles.

And we keep policy documents short. If you can’t explain a policy in two pages, it’s probably not clear enough to be useful. When one firm we talked to helped us revise our cloud adoption policies last year, the biggest improvement was cutting a 30-page document down to a 4-page set of decision guidelines.

Financial Controls

Budget and cost management require governance, but most organizations either over-control or under-control spending.

Over-control looks like requiring approval for every cloud resource provisioned or every software subscription purchased. This is annoying and gets bypassed through shadow IT.

Under-control looks like no visibility into spending until the monthly cloud bill arrives. Teams over-provision because there’s no cost awareness, and the company gets surprised by six-figure bills.

The middle ground is visibility plus guardrails. We give each team a monthly budget allocation and transparent real-time cost visibility. They can spend within their budget however they want. When they approach limits, automated alerts notify them and their manager. This gives teams autonomy while preventing runaway costs.

Compliance Requirements

Compliance obligations (SOC 2, ISO 27001, GDPR, industry regulations) require certain controls. The mistake is implementing those controls in ways that create maximum friction.

Take access reviews. Most organizations do quarterly reviews where managers get spreadsheets of all their team’s access permissions and check off that they’re appropriate. This is painful, takes hours, and catches almost nothing because managers don’t actually understand what “IAM:PutUserPolicy” means.

We automated most of this. Access that follows standard patterns is automatically approved. Access that’s unusual gets flagged for manager review with context explaining what the permission does and why it might be risky. Reviews take 15 minutes instead of hours, and they actually catch inappropriate access because the information is actionable.

The principle is: meet the compliance requirement with the minimum necessary friction. Auditors care that controls exist and evidence can be produced. They don’t care if the controls are maximally inconvenient.

Making Governance Stick

The test of good governance is whether people follow it voluntarily. If compliance requires constant enforcement and everyone’s looking for workarounds, the governance framework is badly designed.

Good governance feels like helpful structure. It answers questions teams have. It prevents them from making mistakes they’d regret. It provides consistency without constraining them unnecessarily.

Getting there requires treating governance as a product. The people the governance affects are your users. If they’re not choosing to engage with your governance processes, you need to understand why and improve the product. Blaming users for “not following policy” misses the point.

Most organizations have too much governance overhead in areas that don’t matter and too little in areas that do. Rethinking governance from first principles, focusing on actual risks, and designing for usability rather than control makes it possible to have both appropriate oversight and organizational agility. That’s when governance actually works.