20 Lessons from 20 Years as an Enterprise Data Leader
I planned to be an engineer. And I was – first at the College of Engineering Guindy in Chennai, then inside IBM, building data warehouses for consumer finance systems that processed transactions for 20 million+ cardholders. What happened next was not a career plan. It was a series of hard problems, bigger teams, and decisions where the cost of being wrong was measured in millions of dollars and millions of customers.
By the time I counted the stops on the map – IBM, Accenture, Ingersoll Rand, The Hartford, Ally Financial, Popular Bank – the numbers had become significant in a way that still surprises me. More than 200 data professionals led. A $54M P&L managed. Systems serving 8.5M+ customers running at 99.99% reliability. A $953M acquisition integration where the data architecture decisions made in six months determined whether the business outcome succeeded or failed.
These numbers are not in this article to impress you. They are here because every lesson below came from a real situation behind a real number – not from a framework document, not from a conference keynote, and not from a business school case study.
I have watched enterprise data and AI transformations succeed and fail across banking, FinTech, insurance, and manufacturing. The pattern in both directions is consistent enough that after 20 years, I can tell within the first two conversations with a leadership team whether their data program will produce results or produce reports about why results are delayed.
The 20 lessons below are what I know now that I did not know when I started. Some of them I learned by doing things right. More of them I learned by doing things wrong, fixing the damage, and documenting what I would never repeat.
If you are earlier in your data leadership journey, read all 20. If you are a CDO or Chief AI Officer already in the work, skip to the lesson that matches the problem sitting on your desk right now. Either way, none of this is theory.
Let us get into it.
Foundation Lessons – What Nobody Tells You at the Start
Lesson 1: Data is Never Just a Technical Problem
The first time I inherited a data quality crisis as an enterprise data leader, I went looking for a technical fix. Bad pipelines. Broken ETL. A schema design that made sense in 2004 but had metastasized into 17 unconnected source systems by the time I arrived.
The tools were part of the answer. But the real problem was that nobody owned the data. No business leader had signed their name to it. No executive had said: this data represents us, and we are responsible for its accuracy.
Every data quality problem I have encountered in 20 years has a technical surface and an ownership root. Fix the technical surface without fixing the ownership structure, and the problem comes back. Always.
Before you buy another data catalog tool, ask who is accountable for each critical data domain. If the answer is “the data team,” you have not answered the question.
Lesson 2: The Most Dangerous Word in Data Strategy is “Pilot”
At three separate organizations, I watched enterprise data transformations stall at the pilot stage. Not because the pilots failed. Because they succeeded – and then nothing happened.
Pilots succeed in controlled environments with hand-picked data, motivated teams, and senior sponsorship. They are designed to succeed. The question is never “can we build this?” The question is: can this survive at production scale, with real data, inside a real organization that has competing priorities?
When I joined Ally Financial, one of the first things I asked was not “what have you built?” It was: what did you build that is actually running in production today, and what fell apart after the pilot closed? The answers told me everything I needed to know about organizational readiness.
Pilots prove technical feasibility. They do not prove organizational readiness. Treat them accordingly.
Lesson 3: Your First Job as a Data Leader is to Build Trust, Not a Platform
I spent the first six months at every new organization doing something that made my team uncomfortable: I talked to business leaders. Not about data. About their actual problems.
What kept them up at night. Where they did not trust the numbers they were getting. Which reports they stopped using because the data was wrong once and they never forgot it.
A data platform that business leaders do not trust is worthless – regardless of how elegantly it is architected. At Ally Financial, we built Customer 360 for 8.5M+ customers. The technology – Snowflake, AWS, unified data pipelines across auto, mortgage, deposits, and credit – was genuinely impressive. But the moment that mattered was not the architecture review. It was the first time a business president used the platform in a live meeting and did not immediately question the numbers. That took 18 months of trust-building before the technology was ever deployed.
Business leaders do not adopt data platforms. They adopt data platforms they trust. Build the trust before you build the platform.
Lesson 4: Governance is Not a Tax on Speed – It is the Infrastructure for Speed
I have heard this argument a hundred times: governance slows us down, we will add it later, we need to move fast now.
Every team I have seen operate this way has eventually paid a governance debt that cost far more than the time they saved. I have seen it in banking, insurance, and manufacturing. The pattern is identical.
At Popular Bank, I implemented 3,000+ data quality rules, PII governance, CCPA/GDPR controls, and enterprise lineage capabilities. This was not done after the platform was built. It was built into the platform from the beginning. The result: 60% data quality improvement across the Customer 360 platform for 2.9M+ customers, and $30M+ in measurable business impact. Governance built in from the start is cheap. Governance retrofitted into a production system that is already serving millions of customers is extraordinarily expensive.
Governance is not the enemy of velocity. It is the foundation that makes velocity sustainable.
Lesson 5: Hire Leaders, Not Titles
Scaling a data and AI organization from 1 to 200+ professionals – as I did at Popular Bank – is the most operationally complex work in enterprise data leadership. It is not about finding people with the right technical skills, though that matters. It is about finding people who can translate between worlds.
The best data engineers I have hired are genuinely curious about the business problem they are solving. The best business analysts I have worked with are honest when the data does not support the conclusion the business wants to reach. These qualities are harder to interview for than technical skills. But they are more important.
When you are building a data team, hire for intellectual honesty first, technical depth second, and title last.
The Hard Lessons – What Failure Actually Teaches You
Lesson 6: Nobody Agreed on What a “Customer” Was
At one major financial institution, I inherited a data organization where every business unit had its own definition of a customer. Retail had one definition. Mortgage had another. Cards had a third. We had $2B+ worth of data platforms and could not answer the most basic question: how many customers does this bank actually have?
That is a Master Data Management problem. But more than that, it is a leadership alignment problem. The technology fix – MDM implementation – took eight months. Getting six business presidents in a room to agree on a single definition took three weeks of uncomfortable conversations. And those three weeks were the prerequisite for the eight months.
The hardest data architecture problems are not solved in architecture reviews. They are solved in rooms where business leaders agree on definitions. That is your job too.
Lesson 7: Every Model Has a Failure Mode – Design It Before You Build the Feature
I deployed a churn prediction system at a $75B banking institution that performed at 94% accuracy in staging. Within 24 hours of going live in production, it started degrading. The root cause: a 3% variance in feature encodings between the staging and production data pipelines. A difference so small that nobody caught it in QA.
We rolled it back in four hours. The damage to organizational confidence in AI took months to repair. After that, I implemented two rules that we never reversed: every model runs in shadow mode for a minimum of two weeks before it takes any production action, and every model requires a completed model card as a hard go-live gate – not optional documentation, a hard stop.
Before you design what a model should do when it works, design what it should do when it does not. Production is not staging. Design for that difference explicitly.
Lesson 8: Agentic AI is a Different Category of Risk
Static machine learning models make predictions. An Agentic AI system takes actions. That distinction changes everything about how you govern, monitor, and deploy it in an enterprise data environment.
In banking and financial services, an AI agent that hallucinates a customer’s loan eligibility is not just an inaccurate output – it is a compliance event. It may be a consumer protection violation. It lands simultaneously in front of your Chief Risk Officer and your regulators. The teams building durable Agentic AI systems that survive 18 months in production share one characteristic: they design the failure modes before they design the features. They build observability – LangSmith, MLflow, Arize – as core infrastructure, not optional add-ons. They treat model governance as a product requirement, not a legal checkbox.
Responsible AI is not the enemy of fast AI. It is the only thing that makes fast AI sustainable at enterprise scale.
Lesson 9: The $953M Lesson – Data Strategy is Business Strategy
In 2022, I led the Fair Square Credit Card acquisition integration at Ally Financial. $953M in transaction value. 1.2M customer accounts. The data architecture decisions made in the six months before that integration closed directly determined whether the business outcome succeeded or failed.
This is the work that does not appear in CDO career lessons books or conference keynotes. It is the unglamorous intersection of data pipelines, M&A timelines, regulatory requirements, and business continuity. It is also where data leaders prove their value to the C-suite in language that CFOs and CEOs actually understand.
When you can connect a data architecture decision to a dollar outcome, do it explicitly. That connection is your seat at the executive table.
Lesson 10: Build for the Regulator You Have Not Met Yet
I have operated under SR 11-7, FDIC Part 370, NYDFS requirements, GDPR, CCPA, and PCI-DSS across my career. Each framework has specific requirements. But underneath all of them is one common principle: every decision made by your systems must be documentable, defensible, and auditable.
The organizations that struggle most with regulatory scrutiny are not the ones that built bad systems. They are the ones that built good systems without documentation. A model that performs well but cannot be explained to an examiner is a model that will be challenged.
Build your data and AI systems as if a regulator you have never met will review every decision they make next quarter. Because they might.
Leadership Lessons – What Separates Good CDOs from Great Ones
Lesson 11: The Best Data Infrastructure Decision I Ever Made Was Saying No
Early in my tenure at Ally Financial, there was significant organizational pressure to build a particular real-time analytics capability on infrastructure that was not ready to support it. The business case was compelling. The timeline was aggressive. The platform it would have been built on had fundamental data quality issues that had not yet been resolved.
I said no. Not forever – but not yet. Six months later, after the data quality work was completed and the platform was stabilized, we built the capability properly. It ran in production for three years without a significant incident. The version we would have built under pressure would not have lasted six months.
The most important word in enterprise data leadership is sometimes “not yet.” The pressure to move fast is constant. Your job is to distinguish between fast and reckless.
Lesson 12: Your Data Team is Not a Service Desk
The single biggest limiting belief in enterprise data organizations is that the data team’s job is to answer requests from the business. Report requests. Dashboard requests. Data extract requests. That model produces a data team that is perpetually behind, perpetually reactive, and perpetually undervalued.
The shift – and it is a cultural shift, not a technical one – is from request fulfillment to data product ownership. Business domains own their data products. The data team builds the platform, sets the standards, and enables self-service. This is the model I implemented at Ally Financial for 8.5M+ customers, and the business outcomes – 22% cross-sell uplift, 20% churn reduction, $40M+ ROI – came from the platform, not from fulfilling individual report requests.
A data team that operates as a service desk will always be too small. A data team that enables self-service will scale.
Lesson 13: Measurement is a Leadership Discipline, Not a Data Team Task
In 20 years, I have seen AI and data programs fail to secure continued investment for one consistent reason: they could not demonstrate business impact in language that a CFO understood. “We improved model accuracy from 87% to 92%” is not a business outcome. “$24M in net charge-off reductions driven by improved credit risk modeling” is a business outcome.
This translation – from technical performance metrics to business impact – is one of the most important skills a chief data officer can develop. It does not come naturally to people trained as engineers or data scientists. It requires deliberate practice and genuine understanding of how the business makes money and manages risk.
Learn to speak P&L. Your technical credibility gets you hired. Your financial fluency gets you funded.
Lesson 14: Cloud Migration is Not a Strategy – It is a Means
I have seen cloud migration positioned as a data strategy, a digital transformation, and an AI enablement program. It is none of those things. It is infrastructure work – important, necessary infrastructure work, but infrastructure nonetheless.
The organizations that extracted the most value from moving to AWS, Snowflake, and Databricks were the ones that arrived at the cloud with clear answers to three questions: what business problems are we trying to solve, what data do we need to solve them, and what data governance leadership standards will we apply? The technology was the last decision, not the first.
Before you procure a cloud data platform, articulate the business problem it will solve. If you cannot articulate it clearly before the contract is signed, the platform will not solve it.
Lesson 15: The CDO Who Does Not Communicate Will Not Survive
I have watched technically excellent CDOs lose their seats because they could not communicate their work to a board. Not because the work was bad – the work was often exceptional. Because the board did not understand what was being built, why it mattered, or what the risk of not building it was.
Board-level communication is a distinct skill from C-suite communication, which is a distinct skill from team communication. The board speaks risk, return, and competitive positioning. The C-suite speaks quarterly outcomes and operational efficiency. The team speaks technical architecture and delivery timelines. All three require fluency in the language of the audience.
A CDO who speaks only one language will eventually lose the audience that matters most. Develop all three fluencies deliberately.
Influence and Scale – What the Second Decade Teaches You
Lesson 16: Recognition Follows Results – But You Have to Make Results Visible
CDO Magazine named me a Global Data Power Woman six consecutive years, from 2020 to 2025. DataIQ recognized me as a Top 50 Data and Analytics Professional. I share this not to self-promote, but to make a point that took me longer than it should have to understand: results that are not made visible do not compound.
The work I did at Ally Financial – Customer 360, $40M+ ROI, 40+ production AI models – was not noticed because I submitted it to award programs. It was noticed because I wrote about it, spoke about it, and taught it at George Washington University. Visibility in enterprise data leadership requires deliberate investment, not just excellent execution.
Doing exceptional work is necessary. Making that work visible is what turns execution into influence.
Lesson 17: Beware the AI Transformation That Starts With a Tool
I have been approached by many organizations whose AI transformation began with a vendor contract for a specific platform. The platform was selected before the use cases were defined, before the data readiness was assessed, and before the organizational capability to absorb the change was evaluated.
Tools do not transform organizations. Leaders transform organizations, and then select the tools that support the transformation they are executing. The sequence matters enormously. An AI governance framework built around a tool you were sold is not governance – it is a roadmap written by a vendor.
If your AI strategy reads like a vendor roadmap, it is not your strategy. Define the business outcome first. Then find the technology that supports it.
Lesson 18: The Best Investment in Data Quality is Upstream
Every data quality program I have seen that focused exclusively on downstream remediation – cleaning bad data after it entered the system – was fighting a losing battle. The data kept arriving dirty because the sources were never fixed.
The highest-leverage intervention in data quality is always upstream: fixing the data entry processes, the system integrations, the APIs, and the source system controls that determine data quality before it reaches the platform. This is harder, slower, and requires more organizational alignment. It is also the only intervention that actually solves the problem.
If your data quality team spends more time cleaning data than fixing the systems that produce dirty data, you are treating symptoms, not causes.
Lesson 19: Great Data Governance Starts With a Business Question, Not a Framework
I have seen data governance programs built around DAMA frameworks, DCAM assessments, and detailed operating model documentation that did not produce a measurable improvement in data quality for 18 months after launch. The documentation was thorough. The business did not notice.
I have also seen enterprise data governance start with one question: which three data domains, if they were reliable and trusted, would change how this organization makes decisions? And then work backward from that question to the processes, ownership structures, and quality rules needed to answer it. The second approach produces outcomes faster because it is anchored in business value from the beginning.
Start governance with a business question, not a framework. Frameworks are scaffolding, not foundation.
Lesson 20: This Work is Not Technical – It is Human
The longest-running lesson across 20 years as an enterprise data leader is this: data and AI transformation is not primarily a technology problem. It is a human problem.
Getting a business president to agree on a data definition. Rebuilding trust in a reporting system after one bad number destroyed years of credibility. Helping a risk officer understand why a model’s recommendation is defensible. Building a team of 200+ data professionals who are aligned around the same standards, the same values, and the same understanding of why their work matters. The technical work is necessary. The human work is what determines whether the technical work produces value.
In 20 years, the problems I could not solve with better technology, I solved with better conversations. Invest in both equally.
