Why size changes the question
“Should we centralize?” has no single answer, because the same decision means different things at different scales. In a ten-person company, nearly everything is already central by default: one owner, one set of tools, one place where people sit. In a company with many locations and divisions, centralization is a deliberate choice with real costs, and it usually has to be made function by function.
Three factors tend to matter more than raw headcount alone: the number of people, the number of locations or units, and the complexity of what each unit does. A 200-person firm with one site and one product line can often run happily on shared systems. A 200-person firm spread over five countries with different regulations may find that one-size-fits-all tools create more friction than they remove.
This article sets out how the case changes at different sizes. It is general information, not advice for a specific organization, and the boundaries below are rough rather than rules.
Very small organizations: central by default
With a handful of people, the main risk is not too much central control but too little structure. Passwords live in someone’s head, files sit on personal laptops, and one person quietly knows how everything works. The benefit of a single shared place for files, accounts and basic records is large, and the cost is low.
What small teams usually do not need is heavy process. Formal committees, detailed approval chains and elaborate tooling can consume more time than they save. The practical goal is a small number of shared tools, written-down basics, and clear ownership of each. Questions of small business IT support and how to cover duties without a full-time specialist tend to dominate here.
Growing organizations: the awkward middle
Somewhere between a small team and a mid-sized company, informal habits start to strain. Information is duplicated, nobody is sure which version of a figure is right, and new hires take a long time to learn where things are. This is often when the first real central systems earn their keep.
The risk in this stage runs in both directions. Waiting too long means retrofitting structure onto years of accumulated mess. Moving too early means buying and configuring tools for a scale the business has not reached. Reasonable signals include repeated errors from manual copying, key-person dependence, and difficulty answering simple questions about the business. The idea of scaling operations without losing flexibility is the central tension.
Multi-site organizations: shared versus local
Once an organization has several branches, the choice becomes a mix. Some things benefit from being identical everywhere, such as financial records, security settings and core customer data. Others depend on local conditions, such as staffing patterns, supplier relationships and customer expectations.
A common approach is to centralize what must be consistent or is expensive to duplicate, and leave local what depends on local knowledge. The result is often one of the hybrid operating models rather than a pure form. The details differ by industry, and the right line is usually found by trial, review and adjustment rather than decided once.
Large enterprises: coordination becomes the main job
In a large enterprise, the question is rarely “central or not”. Different business units may serve different markets, run different systems after past acquisitions, and answer to different regulators. Forcing everything into one design can be slow, costly and politically difficult.
Here the work shifts toward coordination: agreeing which standards are mandatory, which are recommended, and which decisions belong to each level. Clear decision rights matter more than the tools themselves, because without them every disagreement is escalated. A shared services model is one common way to pool routine functions, but it needs its own governance and a willingness to listen to the units it serves.
Costs and risks that grow with scale
Central systems bring risks that scale with the organization:
- Single points of failure. One central system that fails or is compromised can affect everyone at once. The larger the user base, the greater the impact, so resilience planning matters more as you grow.
- Slower local decisions. When every change needs central approval, local managers may wait or work around the rules.
- Change resistance. The bigger the group affected, the more varied the views, and people closest to the work may feel decisions are made without them.
- Cost of getting it wrong. A poor choice made for 20 people is a nuisance; the same choice made for 20,000 is a major project to undo.
A rough comparison
The table below is a simplification for orientation, not a rule.
| Situation | Typical leaning | Main risk |
|---|---|---|
| One site, few people | Central by default, light process | Key-person dependence |
| One site, growing | Introduce shared tools and written basics | Informal habits outgrown |
| Several sites | Share what must be consistent, keep local what needs local knowledge | Inconsistency or rigidity |
| Many units, varied needs | Agreed standards plus negotiated exceptions | Slow decisions, resistance |
| Franchise or network | Central standards with independent operators | Compliance and goodwill |
Practical ways to decide
A few questions help at any size:
- What problem are we actually trying to solve, and can we describe it without naming a tool?
- What would fail, and for whom, if this system were unavailable for a day?
- Who needs to decide locally, and who needs to see the same numbers everywhere?
- What is the cheapest version of this we could try first, and how would we know it worked?
Reviewing the answer periodically is as important as the first decision. A structure that fit 50 people may not fit 500, and a central design that made sense after one acquisition may need to relax after the next. Outcomes depend on the organization, its people and its industry, so treat any size-based guideline as a starting hypothesis rather than a conclusion.