Control instead of

Enablement

Governance that responds to uncertainty by restricting what people can do, rather than making the system structurally safer.

This is the most subtle of the four patterns, because it is born of good intentions. Governance teams respond to the genuine risks of a large migration - data loss, security incidents, service disruption - by introducing controls that limit what delivery teams can do. Each individual policy seems reasonable. Cumulatively, they create an environment where progress requires navigating an ever-expanding obstacle course.

The distinction matters enormously at scale. at scale, restricting people cannot keep pace with a well-run migration programme.

The fundamental error is a misdiagnosis of the problem. If the risk is that a developer might inadvertently break a production service, the instinct is to prevent developers from accessing production. The correct response is to build automated safeguards that make it structurally difficult for anyone (not just developers) to break production.

The first approach restricts people. The second approach improves the system. This distinction matters enormously at scale. Governance that relies on human intervention and approval gates cannot keep pace with the speed at which a well-run migration programme operates. It creates bottlenecks, frustrates capable people, and pushes risk underground as teams find ways to work around controls they regard as obstacles..


The consequences

  • Capable teams are slowed by approval processes that add time without adding insight.
  • Trust erodes between governance functions and delivery teams, reducing the flow of information both ways.
  • Bureaucracy expands over time, as new incidents generate new policies without retiring old ones.
  • The organisation becomes less responsive to real risks because teams have learned to see all governance as noise.


Watch for this signal

Ask the governance team how each approval gate addresses the specific root cause of the risk it was designed to manage. If the honest answer is ‘it manages the nearest person to the risk rather than the risk itself’, the pattern is active.

Root error: restricting people rather than improving systems. Policy should make bad outcomes structurally difficult, not create checkpoints that can be circumvented by anyone sufficiently motivated.

NEXT: The Structured Migration Approach
Visit icpnet.com

Share on social