The case for a thinner operating system

“We need one system where everyone works” is a reasonable reaction to an unreasonable amount of fragmentation.

The project tool has the delivery plan. The CRM has the customer and pipeline. Staffing information lives somewhere else. Financials are maintained in another system. Documents are spread across shared drives, and the explanation for all of it lives in the heads of a handful of people.

The obvious answer is consolidation. The practical answer is usually more complicated.

One source of truth is not one system

Different systems are authoritative for different things. A CRM should probably own the opportunity. A delivery tool should probably own the task. A financial platform should probably own the invoice. Trying to force all three into one application creates a larger system with weaker versions of each capability.

The real need is not one database. It is clarity about which source owns which information and a way for people to move between those sources without reconstructing the map every time.

A thin layer can do enough

A thinner operating layer does not attempt to replace the underlying systems. It helps people find the right information, understand the relationship between records, and continue the work in the correct place.

At the simplest level, that might mean a shared view with stable links into the source systems. With more access, it can include unified search, cross-system reporting, identity mapping, and carefully selected write-back. The important part is that the layer remains honest about authority. It should not create another mysterious copy of the truth.

This is the idea behind Switchboard, a proof of concept I built around client, pipeline, staffing, and delivery information. The interesting question is not whether every integration can be built. It is how much value can be created before the organization commits to a large integration program.

Start with navigation before automation

Organizations often jump quickly to synchronized data and automated actions. Those capabilities are valuable, but they also introduce ownership, security, error handling, and reconciliation problems.

A useful first step is often simpler: show the information people need, identify its source, and take them directly to the correct record. That alone can remove a surprising amount of searching, duplicate entry, and institutional knowledge.

Automation can then be added where the transaction is stable, the ownership is clear, and the benefit justifies the maintenance. Not every connection needs to be real-time. Not every action belongs in the hub.

Build around the work, not the application map

People should not need to know that project status is in one system, contract information is in another, and resource availability requires a message to someone with access to a third. They should be able to begin with the client, project, decision, or task they are trying to understand.

A thinner operating system accepts that the underlying landscape is messy. It does not pretend the mess can be erased in one implementation. It creates enough shared context to make the organization usable while leaving specialized systems to do the jobs they are actually good at.