Silos Aren’t the Problem—Connections Are
Simplicity, meet reality
In my last article I argued that real simplicity comes from doing the hard work on complex details. Those details become manageable when they follow shared, standardized, granular definitions. Most organizations don’t have that alignment. Terms and definitions vary by team, data isn’t broken down to the right level of granularity, and it’s cataloged for narrow, immediate purposes. The result: data doesn’t travel well—and when it does, the context needed to interpret it lives in people’s heads or slide decks. Before we tackle fixes, it’s worth asking: why is this so?
Why the gap exists: silos
Focus Creates Depth; Depth Creates Divergence
Most organizations run through silos. A silo is any group, process, or practice that operates semi-independently to deliver a specific task. It can be as small as one person (owning a newsletter or customer satisfaction survey) or as large as a department (Sales, Marketing, Customer Service). Any sustained effort to solve a particular problem tends to become a silo.
Silos are a good thing. They let teams tackle hard problems with speed, craft, and clear accountability.
The rub: specific problems produce specific solutions—and the data follows suit. Silos adopt categories, definitions, classifications, and IDs tuned to their local goals, tools, and timelines. That’s not “wrong”; it’s optimized for their job.
As businesses grow—more products, segments, channels, and regulations—silos multiply and their data patterns diverge. The result is depth within each silo and divergence across them.
Where the friction comes from
Silos don’t operate alone; they sit inside a business and must engage other silos to get work done. That’s where local, bespoke data becomes a problem—other teams can’t easily interpret, reuse, or contribute to it. Handoffs slow, rework rises, and the organization’s effectiveness drops.
Adjacent teams often patch the gap with manual, bespoke fixes—meetings, long email threads, spreadsheet “definitions,” and reliance on institutional knowledge. Painful but workable—until distance grows.
Distance grows in two ways:
Relational distance. Teams that rarely interact still rely on each other’s data. Context degrades as it passes through intermediaries; meaning changes, and decisions ripple without the needed metadata.
Temporal distance. Months or years later, the people and memory move on, definitions drift, and artifacts go stale. Even close partners lose the original context needed to reuse the data confidently.
Don’t break the silos
Leaders fixing cross-silo data often default to two fixes: flatten the silos or mandate a single standard. Neither works.
Flatten the silos. This triggers massive disruption and still doesn’t solve the problem. Silos exist for craft, speed, and accountability—and they’ll re-form as soon as new challenges appear.
Mandate one standard. One size won’t fit all. Teams will avoid a framework that doesn’t serve their work or, worse, misapply it—creating more friction, mistrust, and inefficiency.
The better path: keep each silo’s local language and make it translatable into terms other silos can use. In short, fix the bridges instead of tearing down the silos. Doing that well rests on four principles.
Principle 1 — Respect the local language
Don’t force one vocabulary. Let teams keep the terms that work and translate those terms into language everyone can understand. By embedding the translation tasks into operating processes translation efforts can be minimized (see Principle 3).
Principle 2 — Lay out the standards
If the translated framework is going to scale you can’t make it up as you go. It must be robust enough to describe every data need – the ones you have, the ones you expect, even the ones you can’t foresee – from the start. Schema6’s 6Qs (WHO, WHAT, WHERE, WHEN, WHY and HOW) is designed as a universal framework for customer engagement. A complete set of descriptions that can be implemented as and how the business requires. We’ll dig more into the 6Qs in our next article.
Principle 3 — Map locally, and make it worth it
The best people to describe data context are those who created and collected the data to begin with—the silos themselves. Downstream or governance teams lack the proper context. And the best time to capture context is the point when it is created. The longer between data creation and data description the more likely critical nuance will be forgotten or overlooked.
So the silos should be describing data as they create and capture it. This can be a big ask, and one teams will be reluctant to take on. To address these concerns efforts should be taken to:
Make it easy
The easier the task is to accomplish, the more likely teams are to do it and do it well. The less they are aware there is an extra task the better. Some common techniques to minimize description work include:
• Define once. Map a term to the standard and reference that mapping going forward. Don’t make teams map the same thing repeatedly.
• Embed in existing work. Add small fields to briefs, tickets, and asset forms; keep extra effort minimal.
• Simplify and standardize templates for current tools (brief forms, ticket types, CRM objects).
• Offer smart defaults to minimize effort – make sure popular selections are highlighted and easy to find.
• Automate lightly. Use business logic to auto-tag answers based on previous entries. Identify likely errors and warn users early rather than block entry later.
Make it worth their while
Teams are much more likely to take on work if there is something in it for them. Collecting context upfront is not only easier, but it means the context can be used sooner. Used for tasks like:
• Automatic routing & distribution to the right channels/teams, no manual work required.
• Faster approvals via built-in checks (brand, legal, compliance), to improve time to market.
• Eliminating rekeying at handoff—IDs and context follow the work, to eliminate unnecessary work and errors.
• Ready-to-use measurement—dashboards and reports that don’t require extra work to translate context, so insights are available sooner.
• SLA-backed support from Shared Services for mappings, templates, and fixes, so teams don’t waste time tracking down work still being delivered.
Making it easy takes work
This is where the real work happens. Change requires work and work doesn’t come for free. But properly implemented, the benefits of having clean, useful data available across the enterprise can far outweigh the investment. In order to ensure maximum reuse and value. This effort is one that should be taken on by a centrally managed shared service. We’ll go deeper on Enterprise Shared Services in a future article.
Principle 4 — Keep it unique and accessible
Unique IDs
When you combine data across silos, records must not conflict or overwrite one another. As silos create new data with its own unique context, standardized processes are necessary to ensure the IDs that represent these datapoints are unique (ProjectID, MaterialID, SegmentID, CampaignID, etc). A centralized Data Governance service can be invaluable in designing IDs and ID assignment processes that work across the organization.
Accessible Definitions
The power of the 6Qs is the shared data framework to describe context. As simple as it is, it is imperative everyone have a shared understanding of what each term means. In addition, the system works because context doesn’t have to be embedded into data – it is mapped to unique IDs. For this to work, data must be accessible, requiring:
• A shared definitions registry for the context that is complete, searchable, and versioned.
• An ID lookup service where anyone can retrieve the full description tied to a given ID.
Both can start as simple spreadsheets accessible on a shared drive. Later it can evolve into sophisticated catalogs/context layers in a data lake/warehouse, with bespoke granular access controls and APIs that pull context to where work happens throughout the enterprise. The best bet is to start small and add more as needs evolve.
Next-level benefits
Follow these principles and meaning—not just data—moves cleanly across teams and time. Beyond local wins, you get enterprise-level outcomes:
Shared language, fewer meetings. Shared IDs and a definitions registry let teams connect data safely across functions and time — fewer reconciliation meetings, easier audits, faster diligence.
Automation you can trust. With consistent context, you can automate distribution, tagging, and approvals — shorter cycle times and lower risk.
Apples-to-apples performance. Compare results across quarters, segments, teams, and channels — clearer trade-offs and quicker resource shifts.
AI you can explain. Models built on consistent definitions and IDs produce predictable, auditable results without brittle custom joins.
Built-in resilience. Capturing context at creation reduces dependence on institutional memory — turnover or reorgs don’t break analysis.
Easier integration. New products, brands, markets, or acquisitions plug into the same backbone — faster integration without starting from scratch.
Closing thought
Silos create depth. Standardized bridges—built by respecting local language and mapping it to a shared framework—let the enterprise use that depth together. The playbook is simple: respect the local language, lay out the standards (the 6Qs), map locally at creation, and ensure unique, accessible data (shared IDs plus a definitions registry and ID lookup). That’s how simplicity shows up at creation—not in a slide after the fact.
Missed earlier pieces? Article 1 argued that data abundance ≠ advantage and made the case for clean, consistently described data captured at creation (6Qs + process + governance). Article 2 contrasted real vs. superficial simplicity and showed how to embed the 6Qs in everyday workflows so rigor becomes practical.
If you want a practical starter pack—6Qs field prompts, a definitions-registry template, and an ID design checklist—or you’re ready to pilot this across a couple of high-value handoffs, reach out and I’ll share the materials to get you moving.
