Listen to this article:
Corporate leadership doesn’t care about data in the same way that we do, nor should they. They don’t care about the details of Data Governance or Data Quality. Certainly not data models. They don’t (or shouldn’t) select hardware, software, or database platforms. They shouldn’t be approving dashboards and definitely not developing them, regardless of the sales-speak that claims that Micro-power-objects-strategy Version 2.5 is so intuitive that a CEO could develop their own reports.
Executives rarely wake up thinking, “Today I need to improve Data Quality.” Instead, they wake up thinking, “I need to reduce compliance risk,” or, “I need reliable customer insights,” or “Does our sales forecast need to be revised?” Data Quality sits not just one but several layers beneath those concerns.
If we want leadership support, we need to change the way that we approach our conversations about data. Stephen Covey and St. Francis both stressed the importance of understanding first before being understood.” Seems like a good place to start.
This article considers Data Quality from an enterprise perspective. Not Data Quality itself, but rather what it tells us about an organization, and the impact that it has on what leadership does care about. Two areas in particular: culture and risk.
Data Quality is a mirror that reflects the choices that an organization makes that determine whether decisions compound value or compound risk over time.
The concept of Data Debt as a form of Technical Debt is generally well understood: short-cuts and other well-intended but imprudent choices made today, usually to satisfy immediate priorities, that can complicate future execution. But Data Debt is more than just that. It also increases the risk associated with the business actions and decisions made using uncontrolled data. Maybe everything will be OK. Maybe it won’t. But uncertainty increases risk, and unmanaged risk compounds over time.
AI amplifies this risk because errors scale faster yet appear more credible.
Data Quality, therefore, tells us something about our company, its values, and its culture. It is an organizational signal.
Viewed in this context, Data Quality is not a technical metric but an outcome.
The way that data is managed reflects how people behave, and in turn what the company believes is important. This is more than just claiming to be “Data Driven” or “Quality Focused.” It goes much deeper than that. It reflects what an organization chooses to examine and what it chooses to ignore, what employees are rewarded for delivering and what they are allowed to ignore without consequence.
Is accountability real or symbolic? Is risk being managed proactively or reactively? Are incentives aligned with long-term value or short-term box-checking?
Consider what it takes to implement an effective Data Quality program: precision, discipline, commitment, participation, etc. High Data Quality usually means that these characteristics exist in the company. To be fair, the inverse isn’t necessarily true. Poor Data Quality doesn’t always mean that these characteristics are absent, but it is a red flag. And without them, no tools, AI, analytics, or cloud platform will fix it.
Ask yourself how many of these you see at your company: sourcing analyses from spreadsheet data, proliferating local or even personal repositories, double-checking data in already published reports, and beginning meetings by asking, “where did the numbers come from?” These behaviors are often stronger organizational signals than any data defects themselves.
Here are three questions you can ask to get the conversation started:
Question #1: Do you already know who to mobilize if some number appears to be wrong?
It doesn’t matter which number. Any number.
Notice first that the question doesn’t presuppose that the number is wrong right now. It also doesn’t ask whether you can figure out who to contact. “Let’s see. The problem is in a Sales report, so let’s get in touch with the Sales Team Manager, but then again it’s an international volume figure but it’s rolled up within a specific vertical….” I have no doubt that in the moment you can find someone to call.
And if you’re thoughts have already turned to some variation of “who gets in trouble” or “throat to choke,” you’re focused in the wrong place. I talked recently about the importance of appropriately allocating beatings, and how the misalignment of beatings is counterproductive and can perpetuate behaviors that undermine Data Quality.
The focus should be on correcting the problem. It’s important to get this right, and it’s important to think about it before the firestorm hits. The clear assignment of responsibilities is one of the key benefits of Data Products. At development time. Not emergency time.
You should have a team at the ready to investigate data errors and anomalies, the same way the National Transportation Safety Board has teams ready to dispatch to aviation accidents. If you’re determined to assign blame, at least wait for the report. It’s irresponsible to say that the pilot was at fault while the wreckage is still smoldering.
Once you have the report, the next question becomes critical:
Question #2: Does the mobilized team have the wherewithal to correct the issue?
Identifying the source of a problem is one thing. Fixing it is another.
Responsibility without authority is frustration. Identifying root causes without correcting them is also frustration, plus it undermines trust.
What happens next when a defect is identified is a key organizational signal.
An error gets reported to the development team. The development team says “Thank you. Go ahead and put it onto the backlog, and we’ll get to it never. The data is good enough for our downstream operational consumers. We don’t have time to fix this analytical data stuff. We have new business functionality to deliver.”
Worse, this attitude is too often supported up the development management chain and the business customer management chain. Data Debt. Technical Debt. Decision Debt.
Sound familiar?
Every company is Data Driven and prioritizes Data Quality until leadership receives the slightest bit of pushback, then it’s all forgotten. But just this time. And the next time. And the time after that.
This is where you find out whether your company really is Data Driven and whether it really prioritizes Data Quality. I understand that there are priorities and you’re not going to win all of them, but you should win the majority of them, or at least the big ones.
Question #3: Why do I believe this data enough to use it to make a decision?
Ask the question sometime. Ask yourself. Ask your direct reports, “Why do you believe this data enough to use it to make a decision?” You’re like to get answers rooted more in “creative writing” than in facts. So many blind spots born of assumptions, most of which aren’t even conscious (because if they were we’d question them).
We assume we live in Data Lake Wobegon: our data is definitely above average. We rarely think about why we trust data. Most of the time we just use the numbers that are in front of us. The dashboard says revenue was $X so that’s what it was.
We assume that we don’t have the wherewithal to question the number. I’ve talked elsewhere about how data can be used as a bludgeon and it’s this tendency that is the soft spot that causes timidity, but we should always be able to ask where the number came from, how it was calculated, what assumptions were incorporated into it, and who owns it.
We assume that someone upstream validated it. But those upstream believe that someone downstream will validate it. Trust is no longer objective, it’s social and institutional.
We assume reliability until experience teaches us otherwise. Once we get burned, then maybe we start developing selective skepticism.
Perhaps we should ask the question in a slightly different way: Are you willing to bet your job on the quality of the data you use?
Notice that when an executive’s job is at stake, like financial data or SOX data, the level of attention increases considerably. I’ve talked with companies where more than a hundred people participate in the collection, validation, and aggregation of certain financial data. I’m sure there are companies with an order of magnitude more.
Would you tolerate treating your financial data the same way you treat other data? For most every company the answer is, “Of course not.”
Remember, an executive’s main job is risk management, and here is a huge source of unmanaged risk.The idea, though, isn’t for leadership to drill into the details of Data Quality and profiling and metadata. Instead, they need to ask questions and expect serious, fact-based answers in response.
Finally, I’m hesitant to mention it but I’ve seen it, if you decide you don’t need Data Quality that’s fine, but don’t lie to yourself about it and don’t act surprised when you have challenges that are born of poor Data Quality.
These three questions inevitably lead to a fourth:
Question #4: Are you fooling yourself believing that your company is “Data Driven” or cutting edge with AI?
Are you building on a solid data foundation, or are you just concerned with bullet points in the quarterly analyst call or annual report? Are you focused on looking good today at the expense of sustainability? Are you compounding value or are you compounding risk?
Be honest.
With yourself and with your people.
If you don’t like the answer, you now know what has to change.
