Growth changes the question
Centralization is not a single decision made once. As a business grows, the right balance between shared and local keeps moving. What works for one site and ten people usually fails at five sites and a hundred, and an arrangement suited to a hundred people may be too heavy for a business that later shrinks or splits. This article follows that path and looks at what tends to trigger a change. For the broader definitions of centralized, decentralized and hybrid, the pillar article on centralized business systems is the place to start.
Nothing here guarantees that centralizing supports growth. Plenty of businesses grow successfully with highly independent units, and others have been held back by a central structure that was too rigid.
Stage one: a single site
At this size, “centralized” is the default and rarely a deliberate choice. The owner or a small group decides most things, and people know each other. Systems may be informal: a shared inbox, a few spreadsheets, accounts kept by one person. That is often fine.
The main risk is not too little structure but dependence on individuals. If one person holds all the knowledge, their absence is a problem. The first helpful steps tend to be modest: write down the key procedures, keep important information somewhere shared and make sure it is backed up. These steps relate to when a growing business should formalize its systems, and doing it too early can slow a small business without much benefit.
Stage two: a growing team
As the team expands, informal ways of working begin to strain. Typical signals include:
- the same question being asked repeatedly;
- different people doing the same task differently;
- the founder or one manager becoming a bottleneck for approvals;
- information stored in personal files that others cannot find.
Here a little central structure usually helps: agreed tools, a shared record of customers or orders, and clear responsibility for key processes. Standard operating procedures begin to pay for themselves. The aim is to remove friction, not to build a headquarters.
Stage three: a second and third site
Adding sites is a common turning point. The question becomes what each site decides and what they share. Without any agreement, sites drift: different prices, different suppliers, different software and different standards of service.
Reasonable first candidates for sharing are things that are similar everywhere and costly to get wrong: financial records, payroll, core software, security basics and purchasing of common items. Things closely tied to local conditions, such as day-to-day staffing, local marketing and relationships with nearby customers, often stay with the site. The balance is covered in more detail in the article on multi-site operations.
A common mistake at this stage is to copy the structure of a much larger company. A business with three sites rarely needs a large central department; one or two people with clear responsibility for shared functions may be enough.
Stage four: many sites or business units
With many sites or units, coordination itself becomes a significant task. The differences between units grow, and so do the costs of inconsistency: reports that cannot be compared, duplicated software, uneven customer experience, and gaps in compliance or security.
This is where formal shared services, common data definitions and clear decision rights tend to appear. Scale makes the economies of a central team more plausible, since the cost of a specialist is spread over more activity. But it also raises the cost of getting the design wrong, because a mistake is repeated everywhere.
Large organizations often adopt a hybrid design, in which central teams provide the platform and standards, and units keep authority over local decisions. Business unit coordination is its own challenge, and there is more to say about it than fits here.
Growth by acquisition
Growth by buying other businesses raises a separate question: whether to integrate quickly into the central systems or leave the acquired business running as it was. Fast integration can bring consistency, but it can also disrupt a business that works and drive out key staff. Leaving it alone preserves what is working but keeps duplication and inconsistent data. Neither answer is always right, and the choice often depends on how similar the businesses are and why the acquisition was made.
A way to judge each function
Rather than asking whether the business should centralize in general, ask function by function. A simple set of questions:
- Is the work similar across units? The more alike, the stronger the case for sharing.
- Is there real scale benefit? Check that the unit cost falls as volume rises, rather than assuming it.
- What does a mistake cost? High-cost errors favor central control.
- How much does local knowledge matter? If it matters a great deal, keep decisions close.
- How fast must local responses be? Slow central approval is costly where timing matters.
- Do we have the capability to run it centrally? A central function with too few or unsuitable people can be worse than the local arrangement.
An illustration with simple, invented numbers: suppose three sites each pay 1,000 per month for the same software, and a shared licence for all three would cost 2,400 per month. The saving is 3 x 1,000 - 2,400 = 600 per month. But if the shared version requires one day a month of coordination effort valued at 800, the net result is a cost, not a saving. The numbers here are purely illustrative; the point is to count the coordination cost as well as the headline price.
Signs you may have centralized too early or too far
- Local managers spend more time getting approvals than serving customers.
- Central teams are busy but local units do not see the benefit.
- Workarounds multiply as units build their own tools around the central ones.
- Good staff leave, citing lack of autonomy.
These are among the centralization warning signs worth watching, and they suggest a need to loosen some controls. A business can also swing the other way: if units cannot be compared, costs are duplicated and incidents repeat, more central coordination may be due.
Sequencing
When centralizing, it is usually safer to begin with one function, learn from it and then continue, than to restructure everything at once. Deciding which functions to centralize first is easier when guided by the questions above and the business’s own priorities.
Growth strategies rest on many things: customers, products, people and capital. Operations structure supports them but seldom drives them alone. A good approach is to revisit the central-versus-local balance at each stage, and to be willing to move in either direction.