Centralised Control Compulsion: When One Team Dictates How Everyone Works

Some dysfunctions arrive dressed as good intentions. One of the most common? The desire to create consistency across the organisation. But when consistency becomes control, and enablement turns into enforcement, a new disease emerges:

Centralised Control Compulsion (CCC)

"A behavioural disorder marked by an uncontrollable urge to standardise others’ workflows, regardless of context."

It begins innocently enough. A central team (platform, security, architecture, or even delivery) finds a way of working they think does works. They package it up as a best practice. Then they scale it. Then they mandate it.

Soon, every team must report in the same format. Every kickoff must follow the same template. Every initiative must fit the same stage-gate, no matter how different the context.

What started as a helpful structure becomes a straitjacket.

It is a bit like the old fable of the three blind people describing an elephant. One feels the trunk and says, “It is clearly a snake.” Another touches the leg and insists, “No, it is a tree.” The third feels the ear and declares, “You are both wrong. It is a bat.” In most versions of the story, the disagreement is the punchline. But in organisations gripped by CCC, the real danger is when one blind person’s view becomes the mandate. When a single interpretation is declared as universal truth, nuance is lost, and with it, effectiveness.

Real-World Manifestations

Meta (formerly Facebook), known for its strong engineering-first culture, introduced a wave of centralised developer experience tools and workflows as it scaled. While these were intended to increase efficiency, teams reported increased friction from overly prescriptive tooling, deployment restrictions, and changes imposed without local team consultation. The focus on alignment slowly shifted towards enforcement, limiting experimentation and agility.

Large banks and legacy financial institutions are frequent hosts of this syndrome. Enterprise PMOs or central risk teams often dictate delivery frameworks across hundreds of teams. As a result, engineers and product teams spend more time navigating compliance documentation than iterating on customer outcomes. Teams lose the ability to adapt, even when their domain demands speed or flexibility.

In both cases, the central body sees adoption as success. But on the ground, autonomy, and most often, morale, suffers.

Where It Comes From

Often, CCC is born out of historical trauma. The organisation may have lived through a period of chaos, unscalable practices, misalignment, or runaway complexity. In response, control becomes the coping mechanism.

But sometimes it is not just fear, it is ambition devouring itself. The teams that define the “how” of working begin to see themselves as more essential than those doing the actual work. Influence becomes a currency. Mandates become tools of self-preservation. In environments where calibration is missing, and incompetence goes unchecked, control becomes a shortcut to perceived value.

There is also the political layer. Owning “The Way We Work” becomes a subtle form of empire-building. It can elevate roles, create visibility, and protect budgets. But it rarely protects outcomes.

Symptoms in the Organisation:

• Teams spend more time complying with frameworks than solving problems.
• Local context is erased in favour of a single “source of truth.”
• Innovation stalls as teams optimise for conformity.
• Central teams measure adoption as success, even if outcomes degrade.

Why It Happens:

• Fear of chaos: After early-stage disorder, leadership swings the pendulum toward heavy-handed control.
• Scaling anxiety: Uniformity is mistaken for alignment.
• Status signalling: Owning "The Way We Work" becomes a power centre.
• Cargo culting: Copying mature organisations without their context or culture.
• Loss aversion: Central teams cling to influence by making others dependent.

The Real Cost:

The impact of CCC goes far beyond inefficient processes or slow delivery. Over time, the architecture of the organisation itself begins to mirror its dysfunction. A catastrophic example of Conway’s Law in action. When one team’s worldview dominates, it becomes embedded not only in templates and tooling but in the very structure of the systems we build.

Engineering teams may be forced into monolithic patterns because that is what the org structure reflects. Product platforms may grow inwardly complex as central teams prioritise governance over usability. Sales-led thinking may infiltrate engineering backlogs, leading to "spray and pray" opportunism rather than coherent product strategy. The company gradually shifts away from customer outcomes and towards internal optics, chasing alignment at the expense of value.

• Autonomy erodes. Teams lose the ability to think, adapt, and evolve.
• Morale drops as top-down dictates replace trust.
• Silos harden as resistance builds in the shadows.
• Architecture rigidifies. Systems become harder to change, just like the culture that created them.
• Transformation efforts stall under the weight of uniformity.

A Story: When CCC, Conway’s Law, and the Watermelon Effect Coalesced

Nokia, once the global leader in mobile phones, is a cautionary tale of how multiple dysfunctions, CCC among them, can silently compound into collapse.

In the mid-to-late 2000s, Nokia was struggling to compete with new players like Apple and Android. Internally, the company was deeply hierarchical, with top-down control mechanisms dictating not only process but also product decisions. Central governance groups enforced rigid development frameworks and long release cycles. Local teams had little say in adapting to the rapid changes in mobile tech.

Technically, this translated into monolithic architecture and painfully slow delivery. Organisational silos became mirrored in software silos : classic Conway’s Law. Innovation was stifled not because talent was lacking, but because freedom was.

Meanwhile, the Watermelon Effect flourished. Reports were green on the outside. Senior leadership saw progress and alignment. But internally, teams were struggling. Delays, quality issues, and loss of customer relevance were hidden beneath layers of presentation.

The result was not a sudden failure, but a slow implosion driven by overconfidence in centralised control, underinvestment in adaptability, and an organisation that stopped listening to itself.

The Cure:

• Principles over prescriptions: Define the why, not just the how. Let teams adapt responsibly.
• Local empowerment: Trust teams to evolve practices that suit their domain as long as outcomes align.
• Feedback loops: If a process is truly valuable, teams will opt in. Adoption should be earned, not enforced.
• Leadership courage: Resist the allure of control. Embrace the messiness of growth.

Centralised Control Compulsion may feel like alignment. But beneath the surface, it creates friction, resentment, and fragility. True transformation happens not when everyone works the same way, but when everyone works with the same purpose.

Let go of control. Rediscover trust. That is where scale lives.

Because when one worldview dictates the system, the organisation stops learning—and starts locking itself in.