Data collaboration across organisations is less a technical problem and more a trust problem. The technology is the easy part.
The Berlin Trip
A couple of months ago, I flew to Berlin to present at a conference on cross-organisation data sharing. The talk covered how two companies, one in Melbourne and one in Berlin, could meaningfully share data to drive better outcomes - not through massive data lake mergers or expensive platform consolidation, but through careful, contract-driven sharing that respected each side's autonomy.
It was my first time presenting to an audience that largely did not share my context. In Melbourne, I can lean on shared understanding - people know the product, the constraints, the history. In Berlin, I had to tell the story from first principles. That constraint turned out to be a gift, because it forced me to strip away jargon and focus on what actually mattered.
What I Learned About Data Mesh
The data mesh concept - treating data as a product, with domain ownership and self-serve infrastructure - had been gaining traction in the industry for a few years by then. What struck me, working across two organisations, was how the philosophy held up in practice but the implementation required far more human coordination than the thought leadership suggested.
Data mesh assumes that domains will own their data products. But ownership requires incentive, and incentive requires visibility. If a domain team produces data that nobody visibly consumes, ownership withers. The real work is not in the architecture diagrams but in creating feedback loops - making it visible who uses what, where quality gaps exist, and what downstream decisions depend on upstream reliability.
In our case, shared analytics between Melbourne and Berlin worked best when we had three things in place: clear data contracts defining schema and SLAs, a shared semantic layer so both sides spoke the same metric language, and regular human touchpoints to discuss what was working and what was not. The technology - BigQuery, Analytics Hub, dbt - was the scaffolding. The bridges were built through trust.
From RAG Bots to Agentic Tools
One thing I presented in Berlin that generated a lot of discussion was our early use of LLM APIs to build a RAG-based Slack bot for our data platform. The idea was straightforward: index our data documentation, Confluence pages, and schema metadata into a retrieval layer, then let people ask questions in Slack and get contextual answers grounded in our own knowledge base.
It worked, and it was genuinely useful for a while. But over time, the limitations became clear. The bot was brittle - every time documentation changed, the retrieval quality degraded. Prompt engineering was a constant tax. And the bot could only answer questions; it could not act on them.
Since Berlin, our thinking has evolved considerably. We have moved away from monolithic RAG chatbots toward scoped AI agents that are given specific tools and guardrails to perform distinct roles. Instead of one bot that tries to answer everything, we now have agents that can query Looker, interact with BigQuery, summarise incidents, and assist with data exploration - each with clear boundaries on what they can and cannot do. The shift from retrieval to agency has been a step change in usefulness, and it maps well to how teams actually work: different roles, different tools, different permissions.
Cross-Org Collaboration Lessons
Working across time zones and organisational boundaries taught me a few things that now inform how I approach any collaboration:
1. Start with a shared problem, not a shared platform. If both sides do not feel the pain of the problem you are solving, alignment will be superficial. We succeeded because both organisations genuinely needed better visibility into the same metrics.
2. Contracts before code. Defining what data will look like, how fresh it will be, and who is accountable for quality - before writing a single pipeline - saved us months of back-and-forth debugging.
3. Document for the stranger. Write documentation as if the reader has zero context. Berlin forced this discipline on me, and it made everything better for Melbourne too.
4. Celebrate the small wins. The first time an analyst in Berlin could query a metric that was defined in Melbourne and get a consistent answer - that felt like a genuine breakthrough. We made sure to call it out because momentum in cross-org work is fragile.
The Broader Point
I came back from Berlin with a renewed conviction: the hardest problems in data are not computational. They are organisational. They are about getting humans to agree on definitions, to respect each other's constraints, and to build trust incrementally. The technology enables collaboration, but it does not create it. People do.
This is true beyond data. In consulting, in startups, in any endeavour where multiple parties need to work together - the bridge is always built from both sides. And the first material is not steel or code. It is trust.