In this article from 2022, we explained why in Data Engineering we should aim for a better balance between Autonomy and Governance.

However, finding a metaphor to explain why scaling data products in large organizations is very difficult proved challenging. Until recently, it was like trying to explain gravity to kids.

Scaling data product management across an enterprise is not just a question of tools or organizational models.

It’s a question of force. And force, as Newton showed us, is a matter of mass and distance.

Gravity Doesn’t Lie

Sir Isaac Newton gave us a formula that has stood the test of centuries:

F = G × (m₁ × m₂) / r²

Where:

• F is the gravitational force between two objects
• G is the gravitational constant
• m₁ and m₂ are the respective masses
• r is the distance between the objects

If you’re wondering how this relates to data product management, hold on — we’re getting there.

The Two Bodies in Orbit

Let’s call the first mass m₁ = People Autonomy.

And the second one, m₂ = Governance & Compliance.

• People Autonomy: teams with ownership of their domain data, fast iteration, product thinking, and innovation.
  
  
• Governance & Compliance: standards, security, lineage, cost controls, consistency, auditability.

Different tribes in your company usually handle them. One calls itself agile. The other calls itself safe. And they usually don’t talk much.

The other variables:

• F = The success of Data Products in the organization
• G = The Organizational Maturity, a constant
• r = The disconnection between People Autonomy and Governance

Well, let’s look at how the gravitational force behaves in an organization trying to establish Data Products

Case 1: One Mass is Zero

If either m₁ or m₂ is close to zero, then:

F = G × (0 × m) / r² = 0

No force.
No pull.
No alignment.
No scalability.

This is what happens in most organizations:

Strong Autonomy, Weak Governance

The domain teams are blazing forward, deploying data pipelines, APIs, models, and dashboards.

They move fast. They feel empowered.

But no one is watching.

• No lineage.
• No standard schema.
• No reusability.
• No interoperability.
• No one even knows who owns what after a few months.

It’s a beautiful mess until the auditors arrive.

Or until another team asks: “Can we trust this?”

(The answer is usually “…ehhh maybe?”)

Strong Governance, Weak Autonomy

Now let's flip it.

Central teams have defined golden standards.

They’ve built a “platform.” They’ve rolled out guidelines, procedures, security policies, naming conventions, and manual processes.

But adoption? None.

Because the people closest to the data are stuck waiting for approvals, meetings, and tickets to be cleared. There’s no energy, no initiative. Only passive compliance.

Case 2: Large Distance

Maybe both your masses are non-zero.

You’ve got motivated teams and a solid governance framework. But if they’re far apart? If autonomy is happening in silos while governance sits in another galaxy?

Then:

F = G × (m₁ × m₂) / r² → becomes very small as r increases

Even strong structures fall apart without proximity.
You’ll hear things like:

• “We didn’t know that policy existed.”
• “We weren’t involved in defining those standards.”
• “It’s too late to apply that control now.”
• “We ship fast and fix governance later.”

Spoiler: You rarely fix governance later.

Case 3: Mass and Proximity in Harmony

Now imagine you have:

• High autonomy: teams own their data products, understand consumers, and iterate quickly
  
  
• Strong governance: trusted automatic policies, self-service capabilities, and standards that reduce risk and increase reusability
  
  
• Minimal distance: The two forces interact constantly, by design

Now the gravitational force is strong.

The system aligns. People build fast, and governance scales with them.Reusability goes up. Data quality improves organically.  Security doesn’t slow you down — it’s baked into your dev flow.

That’s what scaling looks like.

So, What Do We Do With This?

You solve it by engineering the relationship between autonomy and governance.

• Define autonomy with accountability, not detachment.
• Create Guardrails instead of Guidelines
• Build governance with empathy and attention, not control.
• Apply computational governance with low impact on Autonomy
• Reduce the distance. Involve your domain teams in defining the rules they’re expected to follow. Reduce the effort to stay within the guardrails
• Create shared gravitational pull: a reason to care about autonomy and governance.

So, to scale Data Product Management in your organization, you need to build an ecosystem where this balance is possible from the beginning; working in one direction first or another is utterly useless because the result will always be near zero.