When the Best Tool Is the 'Wrong' One

A few years ago, I was watching teams waste weeks requesting the same data over and over. Compliance was drowning in audit requests. Meanwhile, other departments didn’t even know what data existed in the first place.

We had tools. We had processes. But something fundamental was broken.

The problem wasn’t the technology — it was the mental model.

The Reframe

I started asking: what if we stopped thinking of departments as parts of one company and started thinking of them as separate companies that needed to share data?

It sounds simple, but that reframe unlocked everything.

Different departments had different data classification levels. Some required strict governance with monthly audit trails. Others had minimal requirements. Some teams were territorial about their data. Others couldn’t find the data they needed to do their jobs.

If departments are like separate companies — different needs, different trust levels, different governance requirements — then what we needed wasn’t an internal data sharing tool.

We needed an external data sharing tool.

The “Wrong” Solution

That’s when I looked at Analytics Hub.

Analytics Hub (now BigQuery Sharing) was designed for companies to share data with external partners. The whole premise: you provide the data storage, they use their own compute to query it. It was built as a marketplace — publish datasets as listings, others subscribe to them.

This was not what it was designed for. Using an external sharing tool for internal departments felt backwards.

But once I saw departments as separate entities, it became obvious why this was actually perfect:

• Discoverability: A marketplace model meant teams could browse what data existed
• Governance: Each listing was controlled by its owner with clear access rules
• Audit trails: We could see exactly who subscribed to what
• Mental model: Everyone understood “publishing” and “subscribing”

The external sharing architecture wasn’t a bug. It was a feature.

The Resistance

Not everyone saw it this way immediately.

Data owners didn’t want to give up control. They’d built their own systems, their own processes. Why should they have to publish to some marketplace?

Compliance was worried about audit trails. How would they track who had access to sensitive data?

But here’s what made Analytics Hub so powerful: it solved both problems because it was designed for external sharing.

Data owners retained complete control — they managed their own listings, set their own access rules, decided what to publish and when. They actually had more control than in our previous fragmented system.

And compliance? The “wrong” tool gave us better governance than our internal tools ever had. Every subscription was tracked. Every access point was visible. The external sharing model forced the kind of transparency and control that compliance actually needed.

Building Momentum

I started with early adopters — teams who were feeling the pain most acutely. Once they saw how it worked, they became advocates.

Then I created a forcing function: whenever someone made a data request, we pointed them to Analytics Hub first. If the data wasn’t there, they were instructed to ask the data owner to publish it.

This made adoption self-reinforcing. The more people looked for data in the Hub, the more pressure there was to publish there. The more data that was published, the more valuable the Hub became.

We expanded beyond the initial use case: raw data exchanges, beta exchanges where teams could collaborate on data products before official release, sandbox GCP projects with more team autonomy. All listings went through a centralized repo so we could publish metadata to different catalogs and verify quality before anything went live.

The Validation

Then came the acquisition.

By the time our company merged with another, Analytics Hub was mature. And suddenly, the “wrong” tool became the only tool that made sense.

We had two companies with completely different governance models that needed to share data. What would have been months of integration hell — reconciling two systems, duplicating data, rebuilding governance frameworks — became a non-issue.

Analytics Hub was already built for this. Two entities. Different rules. Clear boundaries. Controlled sharing.

The system we’d built for internal departments adapted to an external acquisition without breaking a sweat.

The Proof Was Already There

Here’s the kicker: BigQuery Sharing (what Analytics Hub evolved into) now includes features specifically designed for internal sharing use cases.

Turns out I wasn’t the only one thinking this way.

See Problems Clearly

My job as a platform engineer isn’t just to implement tools as intended. It’s to see problems clearly enough that unconventional solutions become obvious.

The best solution often comes from questioning the boundaries we’ve drawn:

• “Departments are part of one company”
• “External tools are for external use”
• “Data sharing needs to be simple and frictionless”

These assumptions feel obvious until they’re not.

I didn’t wait for someone to assign me this problem. I saw the pain points, researched options, and built consensus around a solution that felt wrong to most people at first. That’s what principal-level thinking looks like — having the conviction to propose the unconventional approach and the strategic vision to make others see why it’s right.

Don’t start with the tool. Start with the problem. The right solution might be the one that looks wrong on the surface.