Ivara Labs
Growth in a multi-location operation rarely fails at the new location. The new site opens, hires, and starts serving customers more or less on schedule. What quietly breaks is the middle: the person or small team holding every site's status in their head, and the assumption that this arrangement scales because it always has.
Coordination does not grow linearly
The reason it stops working is arithmetic. Sites do not just report upward, they interact — sharing staff, referring work, covering each other, competing for the same central resource. The number of relationships that need coordinating grows as roughly n(n−1)/2.
Coordination paths
Relationships to keep straight as locations are added.
Doubling from five sites to ten does not double the coordination. It roughly quadruples it.
This is why the arrangement that felt comfortable at four locations feels impossible at eight, without anything having obviously gone wrong. Headcount rose by a factor of two. The thing the coordinator holds in their head rose by a factor of four.
The coordinator trap
What happens to your operation on the third day of that person's holiday?
If the honest answer is that things slow to whatever the inbox allows, quotes wait, and nobody is certain what was promised to whom, then the coordinator is not a role in your system. They are the system, and the system takes annual leave.
This is rarely anyone's fault. It is what competence looks like as it accumulates: each new location gets absorbed by the person who is good at absorbing things, and it works right up until it does not.
The instinctive fix is to hire a second coordinator. It helps for about two quarters, and then it makes things subtly worse, because now there is a handoff between them. Two people holding half the state each have to synchronise, and the synchronising is new work that neither had before. You have added capacity to a bottleneck without removing the bottleneck.
A coordinator is a person doing a system's job. Hiring a second one buys time. It does not buy a system.
What actually scales
Three shifts do most of the work, and none of them is about working harder.
State lives in the system, not in a person. Every job carries its own status, owner, and history. The question "where are we on this?" gets answered by looking rather than by asking, which is the single largest reduction in coordination load available. It is also, not coincidentally, one of the most expensive invisible workflows in most operations — the arithmetic is in what to automate first.
Requests route themselves. Work arriving through one door, classified, and assigned by rule rather than by someone reading it and deciding where it goes. The routing rules encode what the coordinator knows, which is the part of their expertise that should not have been in one head.
Exceptions escalate, the routine does not. The coordinator's attention should be spent on the cases that genuinely need judgement, not on the ninety percent that follow a pattern. That means designing the exception path deliberately, which is the argument in where automation should stop.
Centralise carefully
The failure on the other side is over-correction: centralising everything, so head office becomes a slower version of the bottleneck it replaced and sites lose the local judgement that made them work.
Worth centralising
- Data and definitions. One number set, one meaning, everywhere.
- Intake and routing. One door in, consistent classification.
- Approvals above a threshold. Spend, discounts, anything with real downside.
- Reporting. Read from live work, not rebuilt per site.
Leave local
- Scheduling detail. Whoever is on site knows their day.
- Customer relationships. These do not transfer to head office well.
- Small operational calls. If it is reversible and cheap, do not route it upward.
- Local knowledge. Suppliers, quirks, the things that never make it into a policy.
The distinction is roughly: centralise what needs to be consistent, leave local what needs to be fast.
Compliance is the clearest case for consistency. Where the rules genuinely differ by location — as veterinary advertising rules do across states and provinces — the check belongs in the centre. Leaving it to each site's judgement means the same asset is governed by a different standard every time it is reused.
What this looked like in practice
A back office that stopped needing a person to hold it
Quotes, scheduling and follow-up all ran through one coordinator. When that person was away, the operation slowed to whatever the inbox allowed. Nothing was broken exactly — it simply depended entirely on one person being present and remembering.
What was built: automated intake and quoting with an approval step, and a dashboard the owner reads instead of asking for updates.
- Follow-up happens without anyone remembering to
- The owner sees the pipeline without asking
- The coordinator does judgement work, not data entry
Client name withheld under NDA. We walk through the detail on a call.
The number worth tracking
If you want one measure of whether this is working, track locations per coordinator — or more generally, revenue per person in a non-delivery role.
In an operation held together by people, that ratio is flat: every few sites requires another coordinator, so overhead grows in step with the business and margin never improves with scale. In an operation held together by a system, the ratio climbs. Adding a location stops meaning adding a coordinator, which is the only version of scale that actually changes the economics.
Watch it over a year rather than a quarter. It moves slowly, and it is the clearest signal of whether growth is compounding or just accumulating.
How we approach this
We map how work really moves before building anything — including the parts that live in one person's head, because those are usually the parts that do not survive growth. What comes out is a written map you keep either way.
Then requests route themselves, every job carries its own state and owner, and the numbers read from the live work rather than a rebuild. That is what a command center does, and it is how the platform we run our own company on carries eighty-plus client accounts across two countries.
If adding a location currently means adding a coordinator, tell us how your operation runs today and we will give you a straight read on whether that is fixable.
Frequently asked questions
- Why does coordination get harder as we add locations?
- Because sites interact rather than only reporting upward, so relationships grow roughly as n(n−1)/2. Going from five sites to ten does not double coordination load, it roughly quadruples it.
- Should we hire another coordinator?
- It buys time rather than solving the problem. Two people each holding half the operational state have to synchronise, which is new work neither had before. It adds capacity to the bottleneck without removing it.
- What should a multi-location business centralise?
- Centralise what needs to be consistent: data definitions, intake and routing, approvals above a threshold, and reporting. Leave local what needs to be fast: scheduling detail, customer relationships, small reversible decisions, and local knowledge.
- How do I know if one person is a single point of failure?
- Ask what happens on the third day of their holiday. If work slows to whatever the inbox allows and nobody is certain what was promised, that person is the system rather than a role within it.
- What metric shows whether operations are scaling?
- Locations per coordinator, or revenue per person in a non-delivery role. If it stays flat, overhead is growing in step with the business. If it climbs, the system rather than headcount is carrying the growth.