A ten-person company can coordinate through memory, direct messages and proximity. The founder knows every customer. One experienced employee knows how exceptions are handled. A spreadsheet is enough because the person who built it understands every column.
Growth changes the mathematics. More customers create more transactions. More staff create more handoffs. More services create more exceptions. More software creates more dependencies. The operating model that felt fast begins to feel chaotic, often without any single decision having made it worse.
Growth does not only increase workload. It multiplies coordination.
Why coordination grows faster than headcount
The arithmetic is simple. Among ten people there are 45 possible one-to-one working relationships. Among thirty there are 435. Not every pair needs to talk, but every additional person, team, product line or system adds more paths along which information has to travel correctly. Informal coordination works when most of those paths run through a few people who see everything. It stops working when they can no longer see everything.
Guidance from the UK's National Cyber Security Centre on shadow IT makes the same point about one specific system. It notes that in very small organisations, of around 20 people or fewer, an asset register can be as simple as a manually maintained spreadsheet, but that larger organisations need more advanced tooling, and that the larger the organisation, the more automated the register needs to be to stay accurate. The method was not wrong at 20 people. It simply does not survive at 200.
Organisational writers have described this for decades. Larry Greiner's Harvard Business Review article on how organisations grow argues that structures suited to one stage of growth can be held on to long after they have served their purpose. The same is true of workflows and systems.
The systems were not necessarily bad
Informal processes are often rational at an early stage. Formalising everything too soon creates bureaucracy and slows a business that needs to move quickly. The mistake is assuming that an operating method remains appropriate after the conditions that made it effective have changed.
The signal is usually repeated coordination cost: managers chasing updates, staff asking who owns a task, customer information being re-entered, reports requiring manual consolidation and senior people becoming approval bottlenecks.
What tends to break first
Handoffs
When one person can no longer follow work end to end, information has to move reliably between roles. Unclear handoffs create delays and dropped commitments. See why broken handoffs are systems problems.
Visibility
Leaders lose the ability to know what is happening by observation. They need systems that make work, exceptions and performance visible without constant meetings.
Ownership
Shared responsibility that worked in a small team becomes ambiguous. Processes need explicit owners and escalation paths.
Data consistency
More users and systems create more ways for records to diverge. What was once a minor spreadsheet issue becomes a reporting and integration problem.
Key-person dependency
Growth increases the cost of having critical logic in one person's head, because more work now depends on that knowledge. Key-person dependency is a systems problem, not only a staffing one.
An illustrative example
Consider a hypothetical installation business that grows from one office to three. At the start, the operations manager allocates jobs from a shared calendar and remembers which customers need special access arrangements. After the second office opens, two schedulers work from copies of the calendar. Jobs are occasionally double-booked, access notes live in someone's inbox and invoices wait until someone confirms the job was finished. Nobody has become less competent. The coordination load has simply outgrown the method.
The obvious response is to hire another scheduler. The more useful response may be to give jobs a single record, a clear status and an owner, so that each office works from the same information.
Warning signs
- Meetings exist mainly to find out what is happening.
- The same customer or order data is typed into more than one system.
- Month-end reporting takes longer each quarter.
- A small number of experienced people are copied into almost everything.
- New starters take longer to become productive because the process is learned by shadowing rather than from the system.
- Customers notice inconsistency between teams or locations.
Do not solve every scaling problem by hiring
Additional capacity is sometimes exactly what the business needs. But hiring people to perform avoidable coordination, repeated data entry or manual status checking scales the inefficiency with the organisation.
Before adding headcount to a strained process, separate capacity problems from design problems. If demand doubled but the process is sound, capacity may be the issue. If people spend their time compensating for disconnected systems, unclear ownership and rework, the operating model needs attention first.
A practical diagnostic
Pick one core workflow, such as order to invoice or enquiry to onboarding, and answer five questions honestly.
- Can someone outside the team describe the stages, owners and handoffs without asking the person who runs it?
- Is each key piece of information captured once and reused, or re-entered along the way?
- Can a manager see stuck or overdue items without asking anyone?
- What happens to the work if one named person is away for two weeks?
- Has the time spent coordinating grown faster than the volume of work?
Two or more uncomfortable answers suggest the workflow has crossed from a capacity question into a design question.
Standardise the repeatable, preserve judgement where it matters
Scaling does not require turning every activity into a rigid procedure. The objective is to make routine work predictable while keeping appropriate space for human judgement and exceptions.
That means defining core workflow stages, ownership, required information, system boundaries, escalation rules and what can be automated. Exceptions should be designed into the operating model rather than treated as evidence that no standard process is possible.
The trade-off runs both ways. Formalise too early and the business loses speed and flexibility it still needs. Formalise too late and growth becomes expensive, because every new customer and every new hire adds coordination cost. The aim is to formalise what is repeated, high-volume or high-risk, and leave the rest light.
What better looks like
A scalable operating system makes work understandable beyond the people who created it. Information is captured once where possible. Important handoffs are explicit. Managers can see exceptions. Systems have defined roles. Automation removes repetitive coordination. Documentation preserves operating knowledge.
As businesses redesign work around automation and AI, cross-functional workflow design becomes more important, not less. Automation built on unclear ownership simply moves confusion faster.
When to act
If growth is increasing meetings, reconciliation, customer delays, management intervention and dependence on a few experienced people faster than it is increasing productive capacity, the business has reached an operating-system threshold.
Digital Operations Improvement redesigns workflows and handoffs for scale, and a Digital Systems Architecture & Roadmap can align the supporting technology environment so that growth adds capacity rather than coordination.
Sources and further reading
- Shadow IT guidance (last verified 10 October 2026)
- Evolution and Revolution as Organizations Grow (last verified 10 October 2026)