The Disconnection Gap

Ten different complaints, one underlying pattern

Ask ten operating leaders what's wrong with their business and you'll get ten different complaints. Sales can't see what marketing is doing. Finance closes the month a week late because three systems don't agree with each other. Onboarding a new client depends entirely on one person's memory. Support can't see the order history that would let them resolve a problem in one call instead of three.

Read across enough of these complaints and a pattern shows up: the business doesn't have one operating model. It has several disconnected ones, each built at a different point in the company's growth, each a reasonable answer to a real problem at the time, none of them designed to work with the others. Strategy, sales, delivery, finance and reporting run as separate efforts instead of one system. That gap between them is where commercial value quietly leaks out: in rework, in decisions made on stale information, in customers who feel the seams even when they can't name them.

This is the disconnection gap. It's rarely visible as a single event. It shows up as a slow accumulation of small frictions that leadership has learned to route around rather than fix, until the cost of routing around it exceeds the cost of fixing it.

Why the gap widens with growth

Disconnection problems rarely start as an emergency. Each individual gap (a spreadsheet here, a manual handoff there) was usually the fastest, most reasonable choice available at the time it was made. The problem is that growth multiplies the number of handoffs, the number of systems in use, and the number of people who need the same information at the same time. A workaround that cost an hour a week at ten employees can cost several hours a day at fifty, and by then it's woven into how multiple teams actually operate, which makes it harder to see and harder to unwind.

This is why "we'll fix it later" is a more expensive strategy than it looks. The gap doesn't hold still while the business waits for a more convenient moment to address it.

What "disconnected" actually looks like

In practice, the disconnection gap tends to take one of three concrete forms, and most businesses have all three somewhere:

• Systems that don't share data. The CRM, the finance tool, and the delivery tracker each hold a partial, slightly different version of the truth, and someone has to reconcile them by hand.
• Handoffs with no owner. Work crosses from one team or tool to another at a point where nobody is formally accountable for confirming it actually arrived, so it depends on someone remembering to follow up.
• Information trapped in one person. A process runs correctly only because a specific employee holds context that was never written down, and the business quietly knows it can't afford for that person to be unavailable.

None of these are technology problems in the sense of "we're missing a feature." They're coordination problems that technology can help solve, once the underlying design is understood.

Why buying a tool doesn't close it

The instinctive response to a disconnection problem is to buy something: a CRM, a project management tool, an AI assistant, a dashboard. Sometimes that's the right move. Often it isn't, because a new tool dropped into a disconnected operating model doesn't reconnect anything. It becomes one more system that needs to be checked separately, one more login, one more place where data can drift out of sync with everywhere else.

The tell is familiar to anyone who has watched it happen: the business already owns more software than it uses well. The gap was never a missing tool. It was a missing architecture: a decision about how information and work are supposed to move between the systems and people already in place.

A tool added to a disconnected operating model doesn't close the gap. It becomes one more thing that's disconnected.

A short diagnostic

Before assuming a new system, tool, or hire is the answer, it's worth testing whether what you're looking at is genuinely a missing capability or a disconnection problem. Four questions tend to separate them:

• If the person currently responsible for this process left tomorrow, could someone else run it from what's actually documented?
• When two systems both hold information about the same customer or order, do they agree, and does anyone check?
• Can leadership answer a basic operating question (what's in the pipeline, what's overdue, what did that cost) without asking someone to go and look?
• Did a previous purchase of software, or a previous hire, actually solve this, or did it solve part of it and quietly create a new handoff?

A "no" to more than one of these is usually a disconnection problem, not a missing-capability problem. That distinction matters, because the two are solved differently, and priced differently.

Closing the gap is an architecture decision

Once the pattern is visible, the question stops being "what should we buy" and becomes "what should exist." For each part of the operating model, the honest options are the same five: keep what already works, improve what's underperforming, connect systems that should talk to each other but don't, replace what's fundamentally unsuitable, or build what's missing entirely. That decision framework is covered in more detail here. The short version is that the right answer is rarely "replace everything," and the businesses that get the most value tend to be the ones willing to keep what's already working and connect it properly, rather than starting over.

The point of naming the disconnection gap explicitly is that it changes what gets measured. Instead of asking whether a new tool was adopted, the better question is whether the handoff that used to depend on memory now depends on a system, and whether that shows up in the numbers that matter: time recovered, fewer errors, faster decisions, less risk sitting with one person.