Ask a technology leader what governance means in their organisation and you will almost always get the same answer: approval processes, review boards, sign-off requirements, and compliance gates. They will describe a system designed to prevent bad decisions. They will not describe a system designed to enable good ones.
This is because most technology organisations do not have governance. They have control. And the two are fundamentally different things.
The confusion is understandable. Both governance and control involve oversight. Both involve rules. Both exist to reduce risk. But they do so in entirely opposite ways — and the difference between them determines whether a technology organisation moves with clarity or drowns in bureaucracy.
Governance enables. Control prevents.
Governance is a system for making decisions well. It ensures the right people make the right decisions at the right time with the right information. It creates clarity about who is accountable, what criteria matter, and how decisions connect to outcomes. Governance does not slow things down. Done properly, it accelerates them — because people know exactly what they are empowered to decide and what requires escalation.
Control is a system for preventing decisions. It ensures nothing happens without approval, sign-off, or review. It assumes that without intervention, people will make bad choices. Control does not trust the system. It trusts nobody.
The difference is not subtle. Governance creates clarity and speed. Control creates queues and delay. Governance distributes authority to the people closest to the work. Control concentrates authority with people furthest from the context. Governance asks: how do we make this decision well? Control asks: how do we stop this decision from being made without our involvement?
Most technology organisations believe they have governance. What they actually have is a control framework with a governance label attached to it.
How control frameworks get built
They start with good intentions. An incident happens — a bad deployment, a security breach, an architectural mistake that costs the organisation time and money. The response is entirely rational: add an approval process. Create a review board. Introduce a gate.
Each gate makes sense in isolation. After a failed release, a change advisory board is created. After a security incident, a security review step is added. After an architectural inconsistency, an architecture review board is established. Each one addresses a real problem. Each one is defensible.
But over years, the gates accumulate. Nobody removes them. Each one adds friction. The original incident that justified the gate may have happened once, five years ago, under circumstances that no longer apply. The gate remains. It becomes institutional furniture — something that has always been there, something nobody questions.
The cumulative effect is an organisation that cannot move. Not because people are slow, not because the work is complex, but because every action requires multiple approvals from people who do not have the context to approve well. The approvers become bottlenecks. The teams become supplicants. The entire system optimises for permission rather than outcomes.
The symptoms of control disguised as governance
The patterns are consistent across organisations, regardless of size or sector. If any of the following sound familiar, the organisation has control, not governance:
- More than three approval steps for routine work. A standard deployment, a minor architecture change, a new service integration — each requiring sign-off from multiple people who add no meaningful judgment to the decision.
- Review boards that meet on a fixed cadence regardless of urgency. A decision that could be made in ten minutes waits two weeks for the next scheduled board meeting. The board exists for the board's convenience, not for the organisation's effectiveness.
- Senior leaders spending most of their time approving rather than deciding. There is a critical difference between approving work that others have defined and making strategic decisions that shape direction. When leaders become approval machines, strategic thinking disappears.
- Teams waiting weeks for sign-off on work they could assess themselves. The people closest to the work, with the deepest context, are not trusted to make decisions within their domain. Instead, they prepare documents for people with less context to review.
- Nobody can explain who is accountable for a decision versus who needs to be consulted. Accountability is diffused across committees and boards. When a decision goes wrong, nobody owns it. When a decision needs to be made, everybody needs to be involved.
These are not governance failures. They are the predictable outcomes of a control framework operating exactly as designed. The system is working. It is simply working against the organisation.
The cost nobody measures
Control frameworks are never measured for their cost. Nobody tracks how many engineering weeks are lost waiting for approvals. Nobody measures the opportunity cost of delayed decisions — the features not shipped, the market windows missed, the competitor advantage conceded while a review board deliberated. Nobody asks whether the approval actually improved the outcome.
The most expensive line item in most technology budgets is not infrastructure or headcount. It is the invisible cost of decisions not made — opportunities lost to a system that was designed to prevent action rather than enable it.
The control framework is treated as overhead that must be accepted — a tax on doing business. But it is not a tax. A tax is imposed externally. This is a structural choice made internally. It can be questioned. It can be measured. And it can be redesigned.
The organisations that do measure this are routinely shocked by the numbers. Weeks of engineering time consumed by approval processes that add no value. Strategic decisions delayed by months because they were trapped in a governance structure designed for operational sign-off. Talented people leaving because they spent more time seeking permission than doing meaningful work.
Designing actual governance
Real governance has four characteristics. They are straightforward to articulate and demanding to implement, because they require the organisation to trust its own people — something control frameworks are specifically designed to avoid.
Clear decision rights. Who decides what, and who is consulted. Not who approves — who decides. Decision rights must be explicit, documented, and enforced. Every significant decision category should have a named accountable person or role. If a decision requires a committee, the governance framework has already failed at that point — committees diffuse accountability, they do not create it.
Appropriate delegation. Routine decisions are delegated to teams, not escalated to boards. The people with the most context make the decisions within their domain, guided by clear standards and guardrails. Escalation happens by exception, not by default. A deployment decision should not require the same governance as a platform strategy decision. When it does, the governance framework cannot distinguish between risk levels — and that is a design failure.
Outcome-based accountability. People are accountable for outcomes, not compliance with process. A team that follows every process perfectly but delivers nothing of value has not governed well. A team that makes a sound judgment call outside the standard process and delivers a strong outcome has governed excellently. If the governance framework cannot tell the difference, it is measuring the wrong thing.
Measured effectiveness. Governance is evaluated by decision quality and speed, not by the number of reviews conducted. How quickly are decisions made? How often do they produce the intended outcome? How frequently are decisions escalated that should have been resolved locally? These are governance metrics. The number of board meetings held is not a governance metric. It is an activity metric, and it tells you nothing about whether decisions are being made well.
The shift from control to governance requires trust — trust that teams with clear standards and guardrails will make good decisions. That trust is not blind. It is earned by designing the right operating model: clear decision rights, appropriate delegation, meaningful accountability, and transparent measurement. The trust is in the system, not in the hope that individuals will always get it right.
The bottom line
If your technology governance makes the organisation slower without making it better, it is not governance. It is control wearing governance's name. The solution is not to remove governance — organisations without governance make worse decisions, not better ones. The solution is to replace control with actual governance: a system that enables decisions rather than preventing them.
The test is simple. Look at your governance framework and ask one question: does this system exist to help people make good decisions, or does it exist to stop people making decisions without permission? If the answer is the latter, you do not have governance. You have a control framework. And it is costing you far more than you think.