One Source of Truth Across Five Departments

The illusion of alignment

Every department thinks it's organised. Sales has its CRM. Engineering has Jira. Operations runs on spreadsheets. Marketing lives in Notion. Everyone's communicating in Slack. Each team has a system that works - for them.

The problem surfaces the moment two departments need to collaborate. Suddenly, nobody knows which version of the data is current. The spreadsheet doesn't match the CRM. The Jira ticket references a Notion doc that's six weeks out of date. Someone pastes a screenshot into Slack and that becomes the reference point for a decision that affects three teams.

This isn't a tooling failure. It's an architecture failure.

Why silos form by default

Departments don't choose fragmentation. They drift into it. Each team adopts the tool that solves their immediate problem, optimised for their workflow and their mental model. Over time, those local optimisations compound into an organisation-wide incoherence.

The deeper issue is that tools are bought, not designed. A CRM is purchased to solve a sales problem. A project tracker is introduced to manage engineering. A wiki is stood up because someone thought documentation was important. None of these decisions are made with cross-departmental data flow in mind - they're made with a single team's pain point in mind.

The result is an organisation where information exists in abundance but knowledge is scarce. Data lives everywhere. Understanding lives nowhere.

What "one source of truth" actually means

It doesn't mean one tool. That's a common misread, and chasing it leads to expensive, bloated platforms that nobody fully adopts.

One source of truth means one authoritative reference point per type of information. Customer status lives in the CRM - not in a spreadsheet, not in a Slack thread. Project status lives in the project tracker. Strategic decisions live in a shared document that everyone can access. The tool doesn't matter as much as the contract: this is where this type of information lives, and everywhere else is a reflection of it, not a substitute.

The discipline is social before it's technical. You can integrate every tool in your stack and still have five sources of truth if people don't trust the system enough to use it consistently.

The integration layer is the strategy

Once you accept that different tools will coexist - and they always will - the strategic question shifts. It's no longer "which tool should everyone use?" It's "how do we make these tools talk to each other in a way that surfaces the right information to the right person at the right time?"

This is where Slack, Notion, Jira, spreadsheets, and a CRM stop being separate products and start being nodes in a network. A deal closes in the CRM - does that automatically trigger an onboarding task in Jira? Does it update the revenue figure in the operations dashboard? Does it notify the relevant channel in Slack without someone having to remember to do it manually?

When these connections exist, information flows. When they don't, humans become the connective tissue - spending cognitive energy on routing information instead of acting on it.

Cross-departmental knowledge is a design problem

The reason teams reinvent the wheel, duplicate work, and make decisions in isolation isn't malice or laziness. It's that knowledge doesn't travel well across organisational boundaries. What engineering learned during a difficult integration never makes it to sales. What sales hears from customers every day never reaches product. What operations discovers about process inefficiencies stays in operations.

Every one of those gaps is a design problem. The question is whether the organisation has deliberately designed channels for knowledge to move, or left it to chance.

Shared tooling, when set up intentionally, creates those channels by default. A Notion workspace that both product and marketing contribute to isn't just a document store - it's a shared context. A Jira board that customer support can view isn't just a tracker - it's a window into what's being built and why. Slack channels that span departments aren't just chat - they're ambient awareness.

The value isn't in the tools. It's in the visibility they create.

Efficiency is a downstream effect

Organisations tend to frame this as an efficiency problem - reduce duplication, cut down on meetings, speed up hand-offs. Those outcomes are real, but they're downstream effects, not the goal.

The real goal is decision quality. When every department is working from the same information, decisions get made faster and with more confidence. When knowledge is shared, teams stop solving problems that have already been solved. When the integration layer works, the organisation starts to behave like a single system rather than a collection of competing units.

Efficiency follows from that. It's not a feature you bolt on - it's what happens when information stops getting stuck.

The uncomfortable prerequisite

None of this works without buy-in at the department level. A unified system imposed from above will be quietly ignored. Teams will maintain their shadow spreadsheets, their private Notion pages, their internal Slack channels that don't surface anywhere useful.

The prerequisite is a shared understanding that the cost of fragmentation falls on everyone. That the hour spent hunting for information, the meeting called to resolve a data discrepancy, the project delayed because two teams had different assumptions - these are not inevitable. They're the tax you pay for not designing how information moves.

When that understanding exists, the tooling decisions become straightforward. You're not choosing between products. You're designing a system.