Skip to main content

How to scale standards without killing autonomy

At some point in every global organization, the same tension surfaces. Local teams feel slowed down by global standards. Central teams feel undermined by local exceptions. Both are usually right, and both are usually frustrated for good reasons. The conversation then drifts toward familiar caricatures: central IT as a bureaucratic brake, local IT as undisciplined cowboys. Neither description survives contact with reality for very long.

I’ve learned that the real issue is rarely about standards themselves. It’s about how authority is designed, expressed, and lived. Most organizations oscillate between two extremes. Either everything is centralized, which creates consistency but suffocates execution, or everything is left to local autonomy, which creates speed but erodes coherence. What gets lost in between is the idea that standards and autonomy are not opposites. They are complementary, if you design them properly.

That’s where the notion of design authority becomes useful, provided it is understood correctly.

Design authority is not about controlling every decision. It’s about defining what must be shared, protected, and consistent, and being explicit about where freedom begins. Architecture, identity, security principles, data foundations, and core platforms are not negotiable because fragmentation there creates systemic risk. At the same time, use cases, local processes, sequencing, and execution methods should remain close to the business and the field, where context actually lives.

When this boundary is clear, arguments tend to calm down. I often think of this model visually, using what some call the dandelion structure, a hub-and-spoke system popularized in ecosystem thinking by people like Jeremiah Owyang. The core provides stability, shared rules, and direction. The spokes are free to move, adapt, and innovate within that frame. The strength of the system does not come from rigid control, but from the fact that everything remains connected to the same root.

What matters here is not the metaphor, but the behavior it enables. Local teams know where they can move fast without asking permission, and where alignment is mandatory. Central teams stop micromanaging delivery and focus on maintaining coherence, security, and long-term optionality. Discussions shift from “who decides” to “what belongs where.”

This only works if authority is exercised with discipline. A design authority that constantly changes its mind, tolerates endless exceptions, or negotiates core principles case by case quickly loses credibility. Equally, local teams that systematically bypass shared standards are not defending autonomy, they are exporting risk to the rest of the organization.

Trust sits in the middle. When standards are stable and meaningful, autonomy feels safe. When autonomy is respected, standards feel legitimate. Without that balance, global IT becomes either a bottleneck or a suggestion, and neither scales very well. The organizations that get this right don’t eliminate tension. They channel it. They accept that global coherence and local relevance will always pull in different directions, and they design an operating model that makes that tension productive rather than destructive.

That, in my experience, is how you scale standards without killing autonomy.