How Disconnected Tools Quietly Limit Scale

Observable condition

The business wants to grow, and in most respects it can. There is demand. There is a sales team that can win work. The owners have the appetite to open a second branch, add a product line or take on a larger client. Yet every growth step seems to arrive with an unexpected tail of internal work that nobody planned for.

A new branch needs its own spreadsheet copied from the head office template. A new product has to be set up separately in the quoting tool, the stock sheet, the accounting package and the website. A new salesperson needs access to five tools, and somebody has to explain which of them holds the real customer list. A large new client means a weekly export from one system, a clean-up in Excel and an import into another.

None of these tasks is difficult. Each one is a few hours here and a recurring half-day there. But the business notices, over a year or two, that it grows more slowly than its demand would allow, and that each new step feels heavier than the last.

Realisation

The common explanation is that growth is simply hard and that more people are needed. The more useful realisation is that the tools themselves are setting the pace. When systems do not share information, every new unit of business (a customer, a product, a site, an employee) has to be introduced to each tool separately, and every transaction that crosses from one tool to another has to be carried across by a person.

That means the cost of growth is not only proportional to volume. It is proportional to volume multiplied by the number of places where information has to be moved, re-keyed or reconciled. A business with four disconnected tools and two hand-carried transfers per order has a very different growth ceiling from one where the same order flows through once.

Google's site reliability engineering guidance gives this kind of work a precise name. It describes toil as work that is manual, repetitive, automatable, tactical and without enduring value, and notes that it scales linearly as a service grows. Disconnected tools manufacture exactly that kind of work, and they manufacture more of it every time the business succeeds.

Realisation prompt: the last time you added a branch, product or major client, how many separate systems had to be told about it, and who told them?

Identification

This is a scalability constraint created by fragmented information flow. The visible symptom is growing administrative load and slower expansion. The structural issue is that the business's tools have no shared path for information, so people act as the connection between them and become the limiting resource.

It is related to, but different from, the everyday frustration described in when your staff become the integration between software platforms. That pattern is about the daily experience of moving data by hand. This one is about what that arrangement does to the business's capacity to grow.

Diagnosis

Several mechanisms usually combine.

Setup multiplies by the number of tools. Each new product, site or user must be created in every system separately, often with slightly different naming, so the effort to introduce anything new rises with every tool added.
Transfers multiply by volume. Every order, invoice or job that crosses from one tool to another needs a person to carry it. Double the volume and the carrying doubles.
Reconciliation grows faster than either. When the same customer or item exists in several places, differences creep in. Finding and fixing them takes more effort as the number of records and systems grows.
Knowledge concentrates. The people who know which export feeds which import, and in which order, become essential. Growth then depends on their availability.

IBM's description of data silos captures the outcome: isolated collections of data that prevent sharing between departments, systems and business units, leading to duplicated workflows, redundant storage and a partial or inconsistent view for decision-makers. IBM also lists business growth itself as one of the ways silos form, because new teams, sites and acquired businesses bring their own tools. AWS makes the same point from the integration side: when data is fragmented, teams must manually clean, filter and reformat datasets from different sources before they can use them, and that causes delays.

An illustrative example

The following scenario is illustrative and does not describe a specific organisation. A Gauteng-based distributor of building supplies runs quoting in one cloud tool, stock in a spreadsheet, invoicing in its accounting package and deliveries on a shared calendar. With one depot, the operations manager keeps it together with a morning routine of exports and updates. When the business opens a second depot in the Western Cape, every one of those routines doubles. Stock now has to be reconciled across two spreadsheets, quotes need a manual check against the right depot's stock, and the delivery calendar has to be split. The new depot is profitable on paper, but the head office team spends the first six months absorbing the extra coordination, and the plan for a third depot is quietly postponed.

Commercial impact

The commercial value at stake is scalability, labour, speed, error rates and customer experience. The direct cost is the staff time spent carrying information between tools, which grows with every new customer and site. The less visible cost is opportunity: expansion that is delayed, clients that are not pursued because onboarding them would overwhelm the back office, and products that are not launched because setting them up everywhere is too much work.

There is also a margin effect. If administrative effort rises in step with revenue, the business does not gain the efficiency that growth should bring. This is the mechanism behind why revenue growth requires more admin staff, and it is why scaling by adding headcount eventually becomes expensive. The size of that effect differs by business and should be measured from real hours and real volumes, not assumed.

Common misidentification

The constraint is often misread as a people problem: the team is not efficient enough, or the business needs a stronger operations manager. Hiring may relieve the pressure for a while, but it also adds to the coordination load, because more people now need access to more tools and more handovers between them.

A second misreading is that the business has outgrown a particular tool and needs a bigger one. Sometimes that is true. More often, the individual tools are adequate and the problem lies between them. Replacing one system without designing how information flows between all of them tends to reproduce the same seams in a new place.

Possibility

A better operating state does not require one system that does everything. It requires that each important item of information has a home, that the other tools receive it from that home rather than from a person, and that adding a new site, product or user is done once and propagates.

In that state, growth still brings more work, but the work is mostly the business itself: serving customers, delivering products, managing people. The administrative overhead of introducing each new unit is small and roughly fixed, rather than multiplied across every tool. As explained in why growth breaks systems that worked when the business was smaller, arrangements that were sensible at one scale often become the constraint at the next; recognising that early is cheaper than discovering it during expansion.

Intervention

Map the seams. List the tools the business relies on and draw every place where information moves between them. Mark which transfers are done by people and how often.
Count the growth multipliers. For a typical new customer, product, site and employee, record how many systems must be updated and how long it takes. This shows where growth is most expensive.
Decide where each item of data lives. Customer, product, price and stock each need one authoritative home. Other systems should read from it.
Connect the highest-volume transfers first. Use the integration capabilities that existing tools already provide before buying anything new. Prioritise by volume and error rate, not by which connection is easiest.
Make setup a single action. Where possible, adding a new product, site or user should happen once and flow to the other tools.
Assign ownership. Each connection needs a named owner who knows when it fails and what to do about it.

Diagnostic questions

How many systems must be updated when a new customer, product, site or employee is added?
Which recurring tasks exist only to move information from one tool to another?
If volume doubled next year, which of those tasks would double too?
Which growth plans have been delayed because the back office could not absorb them?
Who are the people whose absence would stop information moving between your tools?

Disconnected tools rarely fail loudly. They simply make each step of growth a little heavier than it should be. Recognising that pattern turns a vague sense that growth is hard into a specific, fixable set of seams.

Sources and further reading

Google SRE - What is Toil in SRE: Understanding Its Impact (last verified 10 October 2026)
What Are Data Silos? - IBM (last verified 10 October 2026)
What is Data Integration? - Data Integration Technologies Explained - AWS (last verified 10 October 2026)