Technology has a way of convincing us that everything is new. Every few years, the industry finds a new label for the same underlying challenge: big data, cloud, machine learning, data fabric, data mesh, semantic layers, observability, generative AI (GenAI), etc.

After more than a decade leading data at Synchrony, I’ve learned something that may sound counterintuitive in an industry obsessed with transformation: Technology waves matter far less than we think. 

What matters is whether you are solving the right business problem. That principle has helped me navigate every major shift without getting pulled off course by the noise.

One thing remains constant

No matter the technology wave, the conversation often gets centered around risks.

The risks we talk about today, be it data access, compliance, bias, or regulatory exposure, have existed for decades. They are not created by new technologies. They are shaped by how those technologies are used, or the likelihood and/or impact of those risks evolve.

The key question has always been the same: what business problem are we trying to solve, and how are we operationalizing the solution?

Before GenAI, we had machine learning, where we saw that, for example, organizations often invested in models without clearly defining how success will be measured or how the model will be governed once it enters production. Most issues emerged due to the gap between experimentation and operationalization.

In regulated industries, explainability becomes critical. Hence, you need to be able to demonstrate how a decision was made, what data was used, and whether the process meets compliance requirements.

Even in the earlier stages of analytics, the same principles applied. Model risk management, lineage, data quality, and governance have always focused on ensuring decisions can be traced and justified.

So, GenAI amplifies existing risks and forces organizations to be more disciplined about practices they should already have had in place.

In short, the real risk is not the technology itself. It is deploying it without clarity on purpose, process, effective controls, and accountability.

Generative AI changes interaction, not just capability

What makes GenAI different is how humans interact with it. For the first time in human history, we can converse with the models in natural language.

Unlike earlier waves that required specialized skill sets or infrastructure, GenAI is embedded into everyday tools and consumer experiences. It can be used at work, at home, and in informal settings without friction.

That ubiquity is important. When a technology becomes part of daily life, it stops being just an enterprise capability and becomes a behavioral shift.

The outputs are only as valuable as the human ability to interpret them. Hallucinations and inaccuracies are known limitations, but they are not new categories of risk in principle. They are modern versions of an old challenge: validating information.

We’ve always had to evaluate sources, compare interpretations, and make judgment calls. GenAI doesn’t remove that responsibility. It makes it more important. The danger is not that AI thinks for us, but the actual danger is that we stop thinking alongside it.

Only the vocabulary changes

One of the most consistent lessons from my career is that the underlying problems in data management also rarely change. What changes is the terminology and the tooling used to describe them.

I often think back to a large-scale mainframe migration I worked on in the late 1990s during the Y2K transition. If you strip away the technologies, the core requirements are exactly the same as today, which are mapping specifications, documentation, data quality validation, and disciplined execution.

What evolves is everything wrapped around them. Over time, the industry has moved through big data, data lakes, data mesh, data fabric, observability, and semantic layers. Many of these concepts are useful, but they are often re-expressions of older ideas.

Even Master Data Management (MDM), which once had its own category, has effectively been absorbed into broader data management disciplines. The terminology fades, but the underlying capability remains.

The real issue I’ve seen is that organizations tend to anchor too heavily on tools and labels rather than the processes they are meant to enable. At the core, most of what we do in data comes down to reducing friction between business processes and information systems.

When that friction increases, organizations interpret it as a “data problem.” But very often, it is actually a process design problem or a clarity-of-requirements problem.

For example, I don’t always believe organizations have “data quality problems” in the way they describe them. In many cases, they are trying to use data in ways they never explicitly defined requirements for.

If you never defined the need for a data element, its absence is a discovery issue, not a quality issue. That distinction matters, because it shifts the solution from fixing data to clarifying intent.

Big data was a naming moment

I was already working in the big data space before the term even existed. What actually changed was not the emergence of data at scale, but the acceleration of its creation once organizations became fully digital.

I joined the workforce at a time when email wasn’t universal yet. Communication was still paper-based.

Then came the digital shift. Email, digitized workflows, system-to-system communication; all of it fundamentally increased the volume and velocity of information being created.

And that is what “big data” captured. Not a new phenomenon, but a sudden visibility into something that had been building for years. It became a convenient label for volume, velocity, and variety. It helped organizations articulate a challenge they were already experiencing but hadn’t yet formalized.

We also began to reframe data as an asset during this period. Organizations increasingly treated it as intellectual property, something that needed to be managed, governed, and protected.

So in many ways, big data was less a technical revolution and more a storytelling moment. It gave language to a problem that was already there.

Technology waves don’t matter as much as we think

Technology waves do not matter in the way they are often described. What matters is whether organizations are clear about their business strategy, the outcomes they are trying to achieve, and whether they have the right capabilities to deliver those outcomes.

Each technology wave creates urgency, but it can also distract from the underlying work, which is building sustainable processes that improve how organizations operate.

Too often, companies treat technology adoption as a project with a beginning and an end. But data and AI are operating models. They only work when continuously maintained, refined, and aligned with business needs.

My experience has been less about riding waves and more about ignoring the noise around them. Underneath every technology wave, the core question remains the same: are we solving the right problem with the right capabilities?

Everything else is just terminology.

Take quantum computing, for example. When people ask what comes after GenAI, quantum is often the next technology mentioned. And yes, it has meaningful implications, particularly for encryption and cybersecurity. But that does not mean every company needs to rush into quantum investments.

The question remains the same: does this technology solve a business problem or address a meaningful risk?

If the answer is yes, lean in. If not, wait until the capability becomes relevant.

Key takeaways

• Focus on business problems, not technology waves: Evaluate emerging technologies based on whether they solve meaningful business challenges rather than the urgency created by industry hype cycles.
• Treat AI risk as an operational discipline: Build governance, explainability, lineage, and accountability into production processes instead of treating them as isolated compliance exercises.
• Close the gap between experimentation and operationalization: Define success metrics, governance expectations, and production ownership before scaling AI and analytics initiatives.
• Recognize GenAI as a behavioral shift: Prepare for the impact of natural-language interaction and widespread accessibility rather than viewing GenAI solely as another analytical capability.
• Strengthen human judgment alongside AI adoption: Build processes that reinforce validation, interpretation, and critical thinking as AI-generated outputs become more embedded in decision-making.
• Solve process clarity issues before blaming data quality: Distinguish between missing requirements and actual data quality failures before investing in remediation efforts.
• Treat data and AI as operating models, not projects: Continuously maintain, refine, and align enterprise data and AI capabilities with evolving business strategy and operational needs.

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.