When your software systems don't talk to each other — Laurie Young.

When I sit down with someone running a growing business, there’s a frustration that comes up again and again, even though they rarely describe it as a technology problem. It usually surfaces as a small, nagging thing. They ask a simple question, like what’s the profit on this product, how much of the budget is left or did that customer actually pay, and suddenly it isn’t simple at all. Not without opening three different apps, exporting a couple of spreadsheets, and squinting at numbers that don’t quite agree with each other.

It often shows up as one of these issues:

They are using too many bits of software, and they’re feeling tired of all of them.

They’re not sure where to look for a particular piece of information.

The same number lives in two places, and the two places disagree.

They keep wishing the team would just use one tool properly (often Trello or Slack) as the thing that holds everything together.

Someone is always locked out of something.

It feels like a problem with the tools (buy a better platform or app) or a discipline problem (if only people followed the process). In my experience, it’s often neither of these. So I want to lay out a calmer way of thinking about what’s happening and how to decide what to do about it, including recognising when the right answer is to do nothing for now.

The numbers that don’t agree are a real problem

Let me start by agreeing with something the technically minded people around you might be saying. When the same piece of data lives in two systems, and they don’t match, that’s a genuine operational problem. It isn’t fussiness, nor is it just a feeling. A business that can’t trust its own numbers makes worse decisions, time and time again. So the urge to fix it is a good one.

What’s usually wrong is the diagnosis. The disagreeing numbers are a symptom. The underlying cause, nearly every time, is that nobody has decided which system is to be trusted and which is allowed to be wrong.

The real problem isn't the software. It's that nobody has decided how it's all meant to fit together.

The enterprise software world has a name for this: “data silos” — every team and every tool sitting on its own copy of the information, none of them talking to each other. It’s the same thing you feel as the same number living in two places. The large vendors describe it in almost exactly the words you’d use yourself: spreadsheets everywhere, disconnected apps, every team with its own system. They’ve understood the problem perfectly well. They’re just selling the answer to a five-thousand-person company, not to you.

If “data silos” is the name for the problem, “single source of truth” is the name for the goal: one home for each piece of information, so there’s never a question about which copy is correct. It’s a software development phrase that sounds grand, but on your terms, it’s quite simple. For every important number, someone has decided where the trustworthy version lives. That’s a strategic decision, not a tactical one. You don’t fix the disagreeing numbers by wiring every tool to every other tool. You fix them by deciding where the truth is allowed to live in the first place.

That decision is exactly what I mean by a technical strategy. Not an impenetrable document, but a choice about how the technology is meant to serve the business. The tools-that-don’t-talk problem is almost always that decision never having been made.

Why “just connect them up” is the wrong instinct

When you notice these issues, the natural instinct is to start joining software systems together — after all, the symptom is that they’re disconnected, so connecting them looks like the obvious cure. I tend to see three versions of it. The first is to coordinate everything by hand, often with the help of a master spreadsheet kept up to date by copy-and-paste. The second is to glue the tools together with something like Zapier. The third is to lay down strict rules and hope the team sticks to them.

Any of these can be the right move in the right place. The trouble comes from reaching for them automatically, because the connections they create tend to be fragile. They assume the world stays exactly the same shape as it was on the day you set them up, rather than accepting the ever-changing reality. Logins expire. A tool changes something about its behaviour, and the connection breaks without anyone being told. These connections are hard to inspect and hard to hand over. In many cases, only one person really understands how the whole arrangement hangs together, or worse, a few people each understand a different bit of it.

The bigger issue is that each little connection is a small permanent debt that isn’t being tracked. Nobody sends you an invoice for it, so it feels free. It isn’t. The cost is just invisible, which isn’t the same thing.

So the shift I’d encourage is small in wording but large in practice. Stop trying to wire...