Look closely at a bicycle wheel. The hub is small. The rim is where the road is. Between them run a few dozen thin spokes, each one useless on its own, and together strong enough to carry a rider over cobblestones. What keeps the wheel true is balanced tension. Tighten one spoke too far and the rim pulls sideways. Let one go slack and the wheel starts to wobble, slowly at first, then all at once.
I think about that wheel more often than I think about org charts. Every board eventually asks a version of the same question: are we structured to move faster than our market, or is our own organization the thing slowing us down? For a CIO running technology across borders, the answer lives in the operating model. You can have the right strategy, the right budget and the right people, and still lose a year because every decision travels too far before it turns into action.
I have worked on that problem for most of my career. First running application services across France and Switzerland during a major merger in the energy sector, where two ways of working had to become one while the business kept running. Now leading the information system of an international engineering group, around 300 people in 15 countries. The model that has held up through both is hub-and-spoke.
I wrote earlier about governance as a sport rather than a ceremony, and the idea that you standardize the road, not the runner. This piece goes one level down, to the question underneath it. Which parts are road, and who gets to decide?
Two ways to build a bad wheel
Put everything in the hub and you get a very heavy center. One architecture, one security posture, clean reporting, and a queue. Every country waits its turn. Every local nuance becomes an escalation. The business, which has quarterly targets and little patience, quietly starts buying its own tools. Shadow IT is rarely rebellion. It is what people do when the official channel is slower than their deadline.
Remove the hub and the spokes have nothing to hold on to. Each market moves at its own pace, close to its customers, and for a while it feels like freedom. Then the bill arrives: fifteen versions of the truth, uneven security, integrations patched together by whoever was available that quarter. Run a due diligence on your own estate, the way an acquirer would, and you will see it clearly. It is a sobering read.
Hub-and-spoke refuses that choice. The hub owns what must be common. The spokes own what must be close to the business. Everything depends on where you draw the line between the two, and on how you hold it once it is drawn.
The blast-radius rule
I draw the line with one question. If we get this decision wrong in one country, who gets hurt? If only that country, the spoke decides. If the whole group, the hub owns the standard.
It sounds almost too simple, and it settles most arguments. A weak identity setup in one subsidiary is an open door into every other one, so identity is central. A data definition that drifts in one market corrupts the group consolidation, so definitions are central. Which local process to digitize first, or how to sequence a rollout around a local peak season, fails locally if it fails at all. That belongs to the spoke.
The rule also changes the tone in the room. A turf discussion is about power, and nobody gives up power gracefully. A blast-radius discussion is about consequences, and people can usually agree on consequences. Plenty of « the hub wants to control everything » arguments go quiet once someone asks what breaks in São Paulo if this goes wrong in Bangalore.
A small hub, on purpose
The hub is the smallest part of a wheel. I judge mine by how much faster the spokes move because it exists, and in an ideal world I hold it to five responsibilities.
The first is architecture and standards: the reference architecture, the integration patterns, the data model and the approved platforms. That is what stops every country from inventing its own stack and handing me an integration problem three years later. Security and risk come next, with one posture, one set of controls and one incident-response chain. A single unpatched site, or one foreign dependency that can be switched off overnight, becomes a group problem the day it breaks, so it has to be a group responsibility every day before that.
Data is the third. Boards have no patience for debates about whose numbers are right, so the hub owns the definitions, the governance and the pipelines, while the spokes feed the data and use it without redefining it. The fourth is the shared platforms every spoke would otherwise rebuild on its own: the ERP core, identity, cloud landing zones and, increasingly, AI tooling. Built once in the hub, they let each spoke start from something that already runs. The last is portfolio and capital allocation, meaning where the money goes and how we check whether it created value.
What the hub leaves alone matters just as much. It does not run local projects, own local business relationships or approve every decision. The day it starts doing any of those things, it becomes the bottleneck it was built to remove.
Where the wheel meets the road
The rim is where the wheel touches the road, and the spokes carry the load there. Each spoke owns three things, starting with local delivery: building and running what its market needs, on the shared platform, at the pace the local business sets.
The second is the business relationship. The spoke lead is the face of IT to the local executive committee, someone who speaks the language, understands the commercial reality and is trusted because they are in the room when it matters. A hub two time zones away cannot earn that trust by proxy. The third is adaptation inside the guardrails. Regulation, language and market specifics all vary, and the spoke flexes to meet them within the standards, which themselves are not renegotiated country by country.
This is why spoke leads are the most important hires in the whole design. With a strong one, I can hand over real autonomy. With a weak one, I end up recentralizing by stealth, pulling decisions back to protect quality, until the model becomes slow centralization with a hub-and-spoke label on it. I made the longer argument in The case for a strong N-1 layer: the strength of that layer caps how far you can decentralize, and it is the single biggest constraint I manage.
Keeping the wheel true
Every operating-model slide looks clean. Wheels look true in the workshop too. The test is the road, and on the road the pressure comes from both sides.
The hub wants to grow. Central teams see risk everywhere, and each new sign-off feels responsible on its own. Add enough of them and the spokes stop running businesses and start executing tickets. I treat every new central mandate as a tax on speed. It can exist, but it has to earn its place, and it should arrive with a clear idea of what we stop doing to make room for it.
The spokes want to drift. A team under deadline finds a standard inconvenient and routes around it. One exception looks harmless. Twenty leave you with a fragmented estate. Policing helps less than people think. What works is making the compliant path the fastest one: a landing zone ready in days, an integration pattern that already exists, a security review with a clear turnaround time. When the standard is also the shortcut, most drift stops without anyone having to chase it.
I also watch a handful of signals, the way a mechanic spins a wheel and watches the rim against the brake pad.
- Exceptions. How many come in, how fast we settle them, and whether the same ones keep coming back. A recurring exception usually means the standard is wrong, and fixing it is the hub’s job.
- Time to value. How long a spoke takes to go from a business request to something live on the shared platform.
- Shadow IT. What the audits find, and where. It shows me exactly where the official path is too slow.
- Hub weight. Whether central headcount grows faster than the spokes it serves.
- Escalations. How often a spoke lead pushes up a decision that was theirs to make. Too many, and either the line is unclear or the lead is not ready yet.
None of these is dramatic. Together they tell me whether the wheel is still true.
What AI does to the shape
AI is pushing more capability into the platform layer, and that suits this model well. The hub can now offer richer shared services without adding people: governed, secure AI tooling, built once and used everywhere. A spoke that would never have funded its own data science team can start from a working capability on day one. The hub gets stronger and the spokes get faster, which is exactly the trade the design exists to make.
AI also raises the governance bar, and governance belongs to the hub. Where a model came from, whether a decision it influenced can be explained, what happens if a provider changes its terms or cuts off access: those questions cannot be answered fifteen different ways. Run them through the blast-radius rule and the answer is obvious. A badly governed AI tool in one country is a group exposure. The use cases belong close to the business. The rules sit in the hub.
What I tell boards
Structure decides how fast strategy becomes results, and how much risk you carry on the way. Hub-and-spoke, run with discipline, gives a global business three things a board can track. Speed, because execution sits next to the market. Coherence, because what must be common actually is. Resilience, because security, data and architecture are owned once, and owned properly.
Drawing the model is easy. The job is to keep the hub small, hire spoke leads strong enough to trust, and keep the tension balanced when everyone is pulling to blur the line.
When someone asks why we cannot simply centralize everything and keep it simple, I think of that wheel. A solid disc with no spokes is simpler. It is also heavier, and a handful to steer the moment a crosswind picks up. Simple and slow is still slow. The board never asked for simple. It asked whether we can move faster than the market, and that takes a wheel that stays true under load.
