The Hidden Cost of an Approval Form
Count the number of approvals needed for a developer to deploy a minor improvement to production in your organization. Two? Five? Eight? I've seen companies where a CSS change, the color of a button, required four signatures and a pass through the Change Advisory Board.
Meanwhile, your competitors are shipping.
Permission culture has become the silent disease of European IT organizations. Not a spectacular virus that triggers a visible crisis. An autoimmune disease, where the system attacks itself, suffocates its own innovative cells, and ends up confusing motion with progress.
Your teams spend more time asking for permission than creating value. And the worst part is that everyone knows it. But nobody dares say it, because questioning the approval process means questioning the legitimacy of those who approve.
Intent vs. Permission
The military world solved this problem over a century ago. The concept is called Mission Command (Auftragstaktik in German, formalized by the Prussian army in the 19th century). The principle is radical in its simplicity: command defines the intent and the expected outcome. The teams on the ground decide the how.
Translated to IT, this gives you:
- Permission culture: "I want to deploy this feature. May I have authorization?" The initiative comes from the ground, but the power sits at the top. The delay is structural.
- Intent culture: "The objective is to improve the conversion rate by 15% this quarter. Here are the guardrails. Act." The power flows down to those closest to the problem.
The difference isn't measured in management philosophy. It's measured in days of time-to-market, in team engagement rates, and in the ability to seize opportunities before they vanish.
Organizations operating in permission mode add an average of 40% delay to every delivery cycle. Not because of the technology. Because of the approval process. That lost time is irreversible. It never comes back.
The Four Pillars of Innovation by Default
Moving from permission to intent doesn't mean eliminating all control. That would be irresponsible. It means relocating control: from prior approval to structural governance. Four pillars support this transformation.
Pillar 1: Visionary Leadership That Clarifies Intent
Innovation by default starts at the top. If the executive committee can't clearly articulate its strategic priorities, teams have no choice but to ask for permission on every initiative, because they have no way of knowing whether it's aligned or not.
The visionary leader doesn't give orders. They give direction. "We want to become the fastest provider in the Luxembourg market in our segment within 18 months." That's the intent. Everything that contributes to this objective is authorized by default, within the defined guardrails.
The test is simple: if a developer in your organization can't explain in 30 seconds the company's strategic priority and how their work contributes to it, your leadership hasn't clarified the intent. And every ambiguity generates a permission request.
Pillar 2: Mature Governance That Replaces the Lock with the Guardrail
Traditional governance works like a lock: nothing gets through unless someone turns the key. Mature governance works like a guardrail: everything goes through, except what falls outside the defined framework.
Concretely, this means:
- Clear and accessible architectural standards, not buried in a wiki nobody reads. If the team follows the standards, they deploy. No approval meeting required.
- Explicit autonomy thresholds. Below X euros in impact, below Y users affected, below Z criticality level: the team decides alone. Above: structured escalation.
- Post-hoc reviews rather than prior reviews. Replace "May I?" with "Here's what I did, here are the results, here's what I learned." The control hasn't disappeared. It's shifted from blocking to learning.
Pillar 3: Technology Autonomy as an Organizational Capability
Intent without the means is an empty promise. If your teams need to file an infrastructure ticket to create a test environment, wait two weeks for a VM, or get network approval to test an external API, your intent culture will die on contact with reality.
Technology autonomy means giving teams the tools to act without lateral dependencies. Self-service platforms for infrastructure provisioning. CI/CD pipelines the team controls end-to-end. Ephemeral environments created and destroyed on demand. Feature flags that allow testing in production without risk.
Every point of technical friction is a permission-request generator. Eliminate the friction, and you eliminate the bureaucracy.
Pillar 4: Performance Measurement as a Compass
The classic objection to team autonomy is the risk of chaos. "If everyone does what they want, how do we maintain control?" The answer is one word: measurement.
An autonomous team isn't a team without accountability. It's a team whose results are measured with rigor and transparency:
- Lead time: how long between the idea and deployment to production?
- Deployment frequency: how often are you delivering value?
- Change failure rate: what percentage of your changes causes an incident?
- Mean time to recovery: how quickly do you fix a problem?
These are the four DORA metrics. They don't measure effort. They measure impact. And they make permission unnecessary, because the results speak for themselves.
The Art of Structured Letting Go
I know what the CIO reading this article is thinking: "Sounds great on paper, but in my reality, I have a regulator, a board, and auditors who demand traceability."
Traceability and autonomy aren't contradictory. They're complementary. A well-designed CI/CD pipeline produces more traceability than a manual approval process. Every commit is traced, every deployment is auditable, every rollback is automatically documented. The auditor who receives an automated, comprehensive log is infinitely more satisfied than one who receives a form signed by four people, none of whom verified the technical content.
The permission paradox: the more manual approvals you require, the less real visibility you have into what's actually happening. Because teams, faced with the weight of the process, end up circumventing the system. The "under the radar" deployments. The modifications "that don't count as a change." The exceptions that become the norm.
Replace the lock with the guardrail, and teams no longer need to work around the system. They operate within the framework, because the framework lets them move forward.
The Moment of Truth
The transformation from a permission culture to an intent culture plays out in moments of tension. The first incident after an autonomous deployment. The first team that takes a bold initiative and gets it wrong. The first time a middle manager realizes they're no longer the one who approves.
Those are the moments where leadership is tested. If the response is "let's go back to the approval process," you've lost. If the response is "let's analyze what happened, adjust the guardrails, and keep going," you've won something far more valuable than a process: the trust of your teams.
Military organizations that practice Mission Command don't claim that mistakes don't happen. They accept that the cost of tactical errors is infinitely less than the cost of strategic inaction.
In IT, it's exactly the same equation. A production bug fixed in ten minutes costs less than a feature delivered two months late because it was waiting in the approval queue.
Are your teams spending more time asking for permission than creating? If the answer is yes, the problem isn't your teams. It's your system.