If you’ve ever led a data program, you’ve probably felt it, that quiet resistance. Not outright rebellion, but a kind of organizational inertia. People nod in meetings, maybe even agree in principle, but nothing really changes.

Adoption stalls. Momentum fades. And eventually, someone asks the inevitable question: why isn’t this working?

Well, here’s the uncomfortable truth. Most data programs don’t fail at adoption. They fail long before that, at how they’re conceived.

In my conversation with a seasoned Chief Data Officer, one idea kept resurfacing: adoption is not something you drive. It’s something you earn. If you’re trying to force it, you’ve already lost.

Start with risk, not requirements

Let’s begin with a common mistake. Many data leaders launch programs by defining controls, policies, and responsibilities upfront. They assign data owners, create governance councils, and outline workflows; then expect the organization to fall in line.

But in my experience, it rarely works. Why?

Because from the business perspective, it feels like extra work with unclear payoff. A more effective starting point is surprisingly simple: ask questions, not impose answers.

• Do we have critical data?
• Where does it live?
• Who is accountable for the risks associated with it?
• Who is affected when things go wrong?

These questions shift the conversation entirely. Instead of pushing a “data program,” you’re uncovering shared exposure to risk. And here’s the key insight: everyone is affected by bad data. That creates a natural alignment.

But not all data is equal. Treating everything as critical is another trap. The goal is to identify what truly matters, data elements that impact compliance, operations, or decision-making across the enterprise.

Once that’s clear, something interesting happens. You’re no longer asking people to do more work. You’re asking them to help define what already matters to them. That’s a much easier sell.

Make adoption a choice, not a mandate

Here’s where most programs quietly break down. Leaders assume adoption requires enforcement, policies, mandates, and governance structures that compel participation. But forced adoption creates resistance. Always.

A better model borrows from an unlikely place: marketing.

Think about how companies handle customer consent. You’re invited to opt in. The value is clear. And if you don’t see the benefit, you simply don’t engage.

Data programs should work the same way. Instead of mandating participation, focus on building capabilities, standards, tools, and processes that solve real problems. Then make them available.

When one team sees improved data quality for a critical process, others start asking: Can we use this too?

That’s organic adoption. And it scales far better than enforcement. There’s only one exception though, compliance. If something is required by law, it must be enforced. No negotiation.

But everything else should be positioned as a benefit, not a burden.

When governance becomes a “police state,” it alienates the very people it depends on. But when it becomes a service, something that helps teams reduce risk and improve outcomes, it attracts participation.

Rethink what “failure” actually looks like

Let’s challenge another assumption: how do you know if your data program is failing?

Many leaders instinctively look at adoption rates. If only a fraction of the organization is using the program, it must not be working, right?

Not necessarily. Imagine this scenario: only 10% of the organization is actively engaged, but that 10% represents 90% of your most critical business processes.That’s not failure.

Data programs shouldn’t aim for universal adoption. They should prioritize where risk and value are highest.

The real signs of failure are far more operational:

• Critical processes are not engaging with the program
• Defined policies and standards are not being followed
• The organization is not keeping up with the pace of change
• New data assets are created without visibility or controls
• Key roles (like data stewards) are left unfilled for extended periods

At its core, data management is less about strategy decks and more about operational discipline. It’s about detecting what’s happening in the data landscape and verifying that it aligns with expectations.

Think of it like information security. You don’t assume everything is secure, you continuously monitor, detect anomalies, and respond.

The same principle applies here. If a new database appears and no one knows about it, that’s not a minor oversight but rather a breakdown in the system. Success, then, is not perfection. It’s awareness, responsiveness, and consistency.

Change fatigue is real, but misdiagnosed

Every organization today is dealing with change fatigue. New technologies, evolving regulations, shifting market dynamics, it’s relentless.

Data programs often get blamed for adding to that fatigue. But the real issue isn’t change itself. It’s meaningless change.

When people don’t understand the value behind an initiative, it feels like noise, just another demand or distraction. But when change is clearly tied to outcomes like better decisions, reduced risk, and improved efficiency, people lean in.

This is why standalone “data projects” often struggle. They exist in isolation, disconnected from business goals. They ask for effort without delivering visible value.

A more effective approach is to embed data into broader business initiatives. Instead of funding a data quality program, tie it to a regulatory requirement or a revenue-driving objective.

Now the conversation shifts:

• Not “we need better data governance”
• But “we need to meet this this regulatory or contractual obligation”

Data governance becomes part of the solution rather than the goal itself. Hence, when that happens, resistance drops significantly.

Communicate the what and why; be flexible on the how

If there’s one principle that consistently separates successful programs from struggling ones, it’s clarity of purpose.

People don’t resist change because they’re difficult. They resist because they don’t understand or don’t agree with the reason behind it.

That’s why communication matters. Not just broadcasting updates, but engaging in real dialogue.

• What are we trying to achieve?
• Why does it matter?
• How does it benefit the affected or their team?

These questions need clear, simple answers. Once there’s alignment on the what and why, something powerful happens: the how becomes negotiable.

Many data programs fail because leaders become too attached to their implementation approach. But feedback is inevitable and often valuable.

If teams push back on how something is being done, listen, adjust, and improve. In fact, involving people in shaping the solution has an unexpected benefit: it turns skeptics into advocates.

When someone sees their input reflected in the final approach, they feel ownership. And ownership drives adoption far more effectively than mandates ever could.

The role of leadership

No data program succeeds in isolation. Executive support isn’t just helpful, it’s essential. But not in the way many assume. Sponsorship isn’t about occasional endorsements or attending steering committee meetings. It’s about empowerment.

When leaders understand and believe in the what and why, they can reinforce it across the organization. They can resolve conflicts, align priorities, and ensure that data initiatives are taken seriously.

And sometimes, they play a more subtle role of surfacing the real reasons behind resistance.

What looks like pushback might actually be:

• Conflicting priorities
• Resource constraints
• Misaligned timelines
• Or simple miscommunication

These are not problems a data leader can solve alone. They require executive alignment. When leaders engage with each other, clarifying goals and resolving tensions, it creates a ripple effect throughout the organization.

Suddenly, adoption isn’t a struggle. It’s an expectation.

Where to draw the line: Enablement vs. mandate

One of the trickiest parts of driving adoption is knowing when to push and when to step back. The guiding principle is straightforward: enforce only what is legally required.

Everything else should be treated as a best practice. Of course, this doesn’t mean abandoning standards. It means being realistic about their role.

Policies that aren’t tied to regulatory requirements are, ultimately, self-imposed. And if they’re not working, they can and should be revisited.

Trying to enforce them rigidly often backfires, turning governance into an adversary rather than an ally.

Instead, focus on making best practices compelling:

• Show how they reduce risk
• Demonstrate how they improve efficiency
• Highlight how they simplify work

When people see the value, enforcement becomes unnecessary. In the end, if there’s one idea to take away from this conversation, it’s this: adoption is not something you chase directly. 

It’s the natural result of doing the right things.

Key takeaways

• Start with business risk, not governance structures: Frame data programs around shared exposure to operational, regulatory, and decision-making risk instead of leading with policies and controls.
• Focus on critical data, not all data equally: Prioritize the data elements that materially impact compliance, operations, and enterprise decisions rather than attempting universal governance.
• Earn adoption through value, not mandates: Build capabilities that solve real business problems so teams choose to participate because they see measurable benefits.
• Measure success by operational impact, not participation rates: Evaluate whether critical processes are governed effectively rather than aiming for organization-wide adoption metrics.
• Monitor continuously instead of assuming compliance: Treat data management like information security by detecting gaps, anomalies, unauthorized assets, and policy drift in real time.
• Tie data initiatives directly to business outcomes: Connect governance and data quality efforts to compliance, revenue growth, efficiency, or risk reduction to increase organizational alignment.
• Align teams on the “what” and “why,” then stay flexible on the “how”: Build ownership by clearly communicating objectives while adapting implementation approaches based on stakeholder feedback.

About this series

This article is part of a CDO Magazine series co-created with seasoned data leader Justin Heller, exploring how to make the Chief Data Officer role durable, effective, and embedded within the enterprise. The series covers:

• Succeeding as a Long-Term Chief Data Officer: Turning a temporary mandate into an institutional function, building trust across the leadership table, and evolving from transformation leader to operating executive.

• Creating Data Management Processes at Enterprise Scale: Moving from ad hoc fixes to standardized, scalable operating models embedded into business workflows.

• What to Base a Data Governance Program On: Shifting from tool-driven governance to principle-based frameworks grounded in risk, accountability, and decision rights.

• How to Make the Organization Actually Use Your Data Program: Overcoming resistance, aligning incentives, and ensuring governance is both effective and unobtrusive.

• Leading Through Technology Waves: Navigating shifts from big data to cloud to AI while maintaining a consistent operating foundation.

• Becoming and Growing as a Long-Term CDO in an AI-Driven World: Building the skills, mindset, and adaptability required to succeed and stay relevant as the role evolves.

About Justin Heller: 

Justin Heller is a seasoned financial services executive and former, longest tenured Chief Data Officer with more than 30 years of experience helping organizations succeed through data strategy, governance, and risk management. He is widely recognized for guiding institutions in strengthening data governance, advancing AI adoption, and enhancing regulatory, privacy, and risk frameworks, including work with G-SIB, D-SIB, and other systemically important financial institutions.

A respected voice in the industry, Heller has spoken at leading conferences and forums such as FIMA USA, CDAO Financial Services, and CDO Magazine, as well as numerous webinars, addressing topics including data governance, artificial intelligence, risk management, privacy, and data minimization. He also holds multiple patents related to data management and innovation in enterprise data practices.

His areas of expertise include financial services, AI and data strategy, data governance, regulatory compliance, risk management, and privacy.