^{READ TIME: 9 MINUTES}

As organisations grow, their data capability almost always becomes distributed. Analysts embed in business units, domain expertise deepens locally, and teams evolve into some variation of hub and spoke, or federated structures.

There are good reasons for this. Proximity to stakeholders improves responsiveness, the added context improves the quality of their insights, and the business feels more supported overall.

However, once you distribute capability, you also distribute decision making around definitions, logic, tooling, and governance. Without a deliberate coordinating mechanism, a degree of fragmentation becomes an inevitability.

This is where many data leaders start to struggle. They recognise the need for alignment but are unsure how to go about it. Two common options are to establish a Community of Practice, a Centre of Excellence, or some hybrid of the two.

In reality, distributed models require both. They need the learning energy of a community and the authority of governance.

I learned this the hard way earlier in my career. I was running a federated team structure when I discovered that different business units were reporting conversion rate using slightly different logic (One team had excluded certain low value traffic sources from their denominator, which made their performance appear significantly stronger than it was). When we aligned the definition across markets, the numbers shifted materially. A simple governance layer would have prevented this situation entirely. Lesson learned.

The cost of misalignment across teams has the power to damage trust, credibility, and ultimately, your influence as a data leader.

Unfortunately, many data leaders only recognise this once the damage is already causing havoc.

P.S. You too can sponsor this newsletter. The sooner you do, the cheaper it is. Learn more here

When distributed data teams operate without a clear Community of Practice or Centre of Excellence, the following challenges start to emerge:

1️⃣ Core business metrics begin to drift as teams adapt definitions locally to suit context, creating subtle inconsistencies that are difficult to detect until they surface at executive level.

2️⃣ When shadow data teams emerge within business units, they wind up developing their own logic, documentation, and reporting approaches without visibility across the wider enterprise.

3️⃣ Decision-making forums become dominated by debates about definitions and calculation methods rather than focusing on strategic action.

4️⃣ Trust in the data function weakens when numbers differ between regions or presentations, reducing the perceived authority of the team, and your leadership.

5️⃣ Labour scaling across teams becomes difficult because analysts cannot easily move between domains when standards, documentation, and business logic vary significantly without there being a steep learning curve.

Over time, this erodes not only operational efficiency but also the strategic standing of the data function.

The encouraging part is that this is solvable with deliberate design.

(P.S. last week’s poll results are down at the bottom)

If you lead a distributed or semi-distributed data capability, the objective is not to centralise everything. It is to coordinate intentionally.

The first step is to define the scope of your Centre of Excellence. This should focus on the non-negotiables of your data enterprise. Definitions for core business metrics sit here. Minimum governance standards, documentation expectations, shared tooling principles, and clear decision rights when disputes arise should all be explicitly owned. The Centre of Excellence does not need to control delivery, but it must control what needs to be consistent around the org.

The second step is to establish a structured Community of Practice that meets regularly and has a clear mandate. This community should not exist as a passive forum. It should actively surface edge cases, stakeholder challenges, duplication risks, and emerging inconsistencies. Discussions should be documented and fed back into the Centre of Excellence so that standards evolve in response to operational reality.

The third step is to make documentation a shared responsibility. Core definitions, business logic, and governance decisions should be visible, accessible, and version controlled. When analysts move between domains to support areas under excessive load, they should be able to orient themselves quickly because the logic and expectations are consistent.

The fourth step is to clarify decision rights explicitly. When disagreements about definitions occur, there should be a known escalation path. Ambiguity around authority is one of the primary drivers of metric drift.

The fifth step is to monitor alignment proactively. Periodic reviews of key metrics across business units can help detect divergence early before it becomes a political issue.

Taken together, these actions create a governing spine supported by a learning layer. The spine provides consistency and authority. The community ensures relevance and shared understanding.

Even centralised teams benefit from this approach as they scale. Informal variations inevitably emerge once analysts align closely with different stakeholder groups. Without a deliberate governance and community mechanism, internal fragmentation can develop quietly.

Shadow data teams will always exist in some form. The goal is not elimination but alignment. A well-designed Centre of Excellence combined with an active Community of Practice reduces the risk they pose and channels their efforts productively.

If you are leading in a distributed environment and find yourself repeatedly resolving disputes about definitions or defending metrics at executive level, it may be time to look beyond structure and towards coordination.

The right model is rarely either community or control.

Sustainable data leadership requires both.

If you would like support designing this kind of coordinated structure in your organisation, I would be happy to explore it with you.

Tristan Burns

Find me on LinkedIn or Book a 1:1 call

Last week, I asked you What does your team primarily measure success by?

Here’s how you responded: