Why growing companies centralize, fragment - and centralize again
Every startup begins the same way.
One shared document. One spreadsheet. One place where everything lives – customer notes, product ideas, bugs, pricing experiments, roadmap thinking. All of it, in one place.
At this stage, coordination is almost free. The team is small. The customer list is short. The processes are few. A single document works beautifully – because it can.
But growth changes the equation.
As a company scales, that single source of truth starts to crack. What once felt like clarity starts to feel like chaos. The document multiplies. The spreadsheet forks. Ownership blurs. And suddenly, the very thing that made you fast is slowing you down.
This is where the real challenge begins – and where we see companies move through a series of distinct stages, each with its own coordination problems, its own breaking points, and its own solutions.
Stage 1: Centralized simplicity
In the early days, the company is small enough that information travels on its own. Sales talks directly to product. Support sits a few desks away from engineering. The founders know every customer by name – and often by story.
No one needs a system, because the team is the system.
A shared Notion page or Google Sheet becomes the de facto source of truth – not because it’s powerful, but because it doesn’t need to be. When the team is small and the problems are few, centralisation works effortlessly. Everyone sees the same thing, updates the same file, and stays in sync without trying.
This is coordination at its most natural. Cheap, fast, and surprisingly effective.
Stage 2: Functional specialization (The “Tool Bloom”)
Growth brings specialisation. And specialisation brings new people – a Head of Sales to drive revenue, dedicated support staff to handle customers, product managers to own the roadmap.
Suddenly, the team is no longer five people who share everything. It’s a collection of functions, each with its own focus, its own language, and its own needs. And a single Google Sheet can’t hold all of that.
Each new function reaches for its own tools. Sales wants a CRM. Support wants a ticketing system. Product wants a proper roadmap tool. These aren’t unreasonable asks – they’re the natural consequence of doing serious work at growing scale.
But here’s the problem: every new tool is also a new silo.
This is the “best-of-breed” era. And for a while, it works brilliantly.
The results are hard to argue with. Sales moves faster and closes more. Support gets structure where there was once chaos.
Product finally has the visibility to plan ahead. Each team is operating at a level that simply wasn’t possible with a shared spreadsheet.
This phase can carry a company surprisingly far – through 50 employees, past 100, sometimes all the way to 200. Every function is humming. The org chart is filling out. The metrics are moving in the right direction. It feels like the hard part is over, but, It isn’t.
Stage 3: The fragmentation tax
A subtle but significant deterioration begins when cross-functional communication fails. Symptoms manifest in phrases that reveal organizational misalignment and information asymmetry, such as, “That’s not what the CRM says,” “Support never told us that,” “We promised that feature last quarter,” or the fundamental question, “Who owns this customer?” The business, in its pursuit of functional efficiency, has inadvertently sacrificed cross-functional coherence.
The result is predictable: vital customer knowledge gets trapped in departmental silos. Product roadmap commitments live in tools no one else can access. Critical escalations dissolve into unsearchable Slack threads. Integration, in practice, becomes a calendar full of reactive meetings.
This is the “fragmentation tax” – the hidden cost of structural inefficiency, paid in lost context, duplicated effort, and slow decisions.
Management theory has long named the underlying tension: centralization delivers standardization, economies of scale, and coordination; decentralization delivers speed, specialization, and responsiveness – but at the risk of duplication and silos. Neither model wins permanently. So organizations do what organizations do: they swing between the two, endlessly.
Stage 4: Re-centralization (The “platform moment”)
When the fragmentation tax becomes too steep, the instinct is to recentralize. The playbook is familiar: a sweeping ERP implementation, a suite consolidation, an enterprise data warehouse, a standardization program. The management pendulum swings back toward control.
But monolithic re-centralization carries its own cost. In the effort to unify everything, organizations often smother the specialization and agility that drove their growth in the first place. That trade-off, eventually, becomes unsustainable.
So the cycle continues. The enterprise breaks itself apart again – into autonomous business units, regional structures, distinct product lines – and the pendulum swings back the other way.
The real pattern: coordination cost vs. specialization benefit
The pendulum doesn’t swing on ideology. It swings on economics.
When teams are small, coordination is cheap – so centralization works. As organizations scale, the returns on specialization grow, and decentralization becomes the smarter bet. But as complexity compounds, coordination costs surge again, and the pressure to recentralize returns.
This isn’t a philosophical preference. It’s a structural response to shifting economic realities – the same forces, playing out at every stage of growth.
The modern resolution: shared memory, federated execution
Neither decentralization nor centralization is the villain. The real mistake is subtler: confusing workflow tools with organizational memory.
The next phase of enterprise architecture won’t be another swing of the pendulum. It won’t be a return to monolithic systems. Instead, it will look like specialized execution layers – each optimized for what it does best – operating above a single, unified memory layer that holds context across all of them.
Teams should stay free to use whatever tools serve their workflows best. But the company as a whole needs something different: a shared, queryable, structured model of the things that matter most – customers, users, issues, product work, roadmap items, revenue impact, support history, usage signals.
This isn’t a spreadsheet. It isn’t a ticketing system. It isn’t a CRM. It’s something more fundamental – a connected layer of knowledge that cuts across every team and every tool.
That’s what a Knowledge Graph is.
The DevRev perspective
At DevRev, we don’t solve this by forcing everyone into a single rigid interface. We solve it by centralizing memory, connecting signals, and letting federated teams execute independently.
DevRev’s Computer model – powered by a knowledge graph – unifies customer, product, and revenue context into a single layer that every team operates above. Sales sees the product reality. Support influences the roadmap. Product understands the revenue impact. No meetings required.
But the path there doesn’t have to be a rip-and-replace. The land strategy is simple: start with the teams feeling the coordination pain most acutely – typically Support, Product, or Revenue – and let the value of shared context pull the rest of the organization in. The knowledge graph grows with adoption, not ahead of it.
This is the next evolution: shifting the pendulum away from centralizing UI, and toward centralizing context.
