The design idea
A common difficulty with business structure is that central control brings consistency but slows local response, while local freedom brings speed but inconsistency. Hub and spoke designs try to avoid choosing between the two by splitting the problem. The hub provides the shared platform: systems, data, standards, security and specialist support. The spokes, meaning the local units, make most of the day-to-day decisions about how to use that platform for their own customers and conditions.
This is a form of the hybrid operating models that many businesses end up with. The broader argument about whether centralization helps or hinders agility is covered in a separate article; this one looks at the design itself and what it takes to make it work.
What goes in the hub
The hub holds what benefits from being the same everywhere, and what is expensive or risky to duplicate. Typical contents:
- Core systems and infrastructure, so that each unit does not build its own.
- Shared data definitions and records, so that reports from different units can be combined and compared.
- Identity and security foundations, so access is managed consistently.
- Standards and guardrails, such as minimum requirements for data handling or financial controls.
- Specialist support, such as architects, analysts and security staff, available to the spokes on request.
- Common services, for example payroll, purchasing platforms or a service desk, where scale helps.
What goes in the spokes
The spokes keep what depends on local knowledge or must change quickly:
- Decisions about the local offer, such as prices within agreed limits, local promotions and service hours.
- Staffing and scheduling within the unit’s budget.
- Customer and supplier relationships that are local in nature.
- Configuration and extensions of the shared platform within agreed boundaries, for example local reports or workflows.
- Process improvements that stay inside the unit’s own area.
The line between hub and spoke is a choice, not a fact. Different businesses draw it in different places, and it can move.
Why this can improve agility
The main reason is that it removes two sources of delay. First, units do not have to build or buy basic capabilities before acting: the platform is there. Second, units do not wait for central approval on most decisions, because they have been told in advance what they may decide. Faster local response and a ready platform are the two ingredients of agility in this context.
There is also a learning benefit. When units experiment within guardrails, successful ideas can be adopted by the hub and shared, so that improvements spread. This works only if the hub is actually listening.
What makes it work
Clear decision rights
The design depends on people knowing who decides what. If it is unclear, units either ask permission for everything, which removes the speed, or act freely and surprise the hub, which removes the consistency. Writing down decision rights, perhaps using a RACI matrix, and revisiting them when they are disputed, keeps the arrangement honest.
Guardrails, not gates
A guardrail says “you may do anything within these limits.” A gate says “you may do this only after we approve.” Hub and spoke works better with guardrails, since they allow action without waiting. Examples include a spending limit under which a unit can act alone, or a list of approved tools it can choose among.
A responsive hub
If the hub is slow, spokes will bypass it. The hub should treat the units as internal customers, with agreed service levels for requests, visible queues and a habit of asking units for feedback. Agreeing internal service levels that people actually use helps both sides understand what to expect.
A platform that can be configured
If every local need requires custom development by the hub, the model reverts to central bottleneck. Platforms that allow safe local configuration let units adapt without opening a ticket every time.
Local input mechanisms
Forums where spokes can raise needs and influence hub priorities, such as a user group or steering committee with representation from the units, reduce the sense that the hub is imposing decisions. The article on balancing central control with local input covers this in more detail.
Handling exceptions
Some local needs will not fit the standard. A defined route for approving exceptions, with a fair and quick process, prevents quiet workarounds.
Risks and failure modes
- A hub that grows into a gatekeeper. Over time central teams may add rules and approvals. Reviews that ask whether each control still earns its cost can counter this.
- Spokes that drift apart. If guardrails are weak, units may diverge until the benefits of the shared platform are lost.
- Duplicated hub functions. Units may rebuild central services locally because they do not trust or cannot reach the hub.
- Unclear accountability. When the hub provides the platform and the spokes use it, a fault can be blamed on either. Agree in advance who is responsible for what.
- Single points of failure. The shared platform is still shared; an outage affects every spoke. Resilience planning is part of the hub’s duty.
- Cost allocation disputes. Who pays for the hub is often contentious. Some businesses charge units by usage; others spread costs evenly. Each has side effects, and neither is automatically fair.
- A mismatch with the business. For a small business with one location, a hub and spoke structure is likely more machinery than it needs.
Examples of the pattern in everyday terms
A retail chain may run a central inventory and payment platform while store managers decide local staffing and promotions within guidelines. A professional services firm may provide shared tools and templates while offices decide how to serve their own clients. A group of companies may share a finance system and security standards while each company runs its own sales approach. These are illustrations of the general pattern, not descriptions of particular businesses.
Starting points
- List the capabilities units currently build or buy separately, and ask which would be better shared.
- List the decisions that currently wait for central approval, and ask which could safely be delegated.
- Write the guardrails that would make delegation safe.
- Define how the hub will be held to account for its responsiveness.
- Pilot with a few units before applying it everywhere.
Hub and spoke is not a guaranteed route to agility. It is a practical design that, when the decision rights are clear and the hub is responsive, tends to give units the speed of local control and the benefits of shared systems. When those conditions are missing, it can combine the weaknesses of both.