Why I Have Come to Dislike the Word ‘Pragmatic’ When Talking About Data Governance
If you’ve worked in Data Governance for any amount of time, there will have been a time when a client or employer told you to be pragmatic. Hell, you may have used the term yourself. I sure know I have. But lately, I have come to dislike the word and avoid it like the plague.
Words and smells
In software engineering, developers sometimes talk about code smells. Code smells are patterns or surface phenomena in code which by themselves are not necessarily wrong, but often indicate underlying problems exist. Long functions are an example of this. When we are talking about Data Governance, similar smells exist: statements or opinions that appear more or less harmless to an outsider, but are indicative of underlying problems. The use of the word pragmatism is such a smell.
In my experience, the more a sponsor or stakeholder insists you be pragmatic when embarking on a Data Governance program, the smaller your chances are to achieve anything. That is because when they use the word pragmatic, what they really mean is often something quite different.
What’s wrong with being pragmatic?
By itself, there is nothing wrong with being pragmatic, of course. If anything, it is a good idea to focus on the concrete and the actionable rather than the purely theoretical. But what is theory and what is not? Are data practitioners truly locked in their ivory towers, completely detached from the reality in which they operate? My claim is that the large majority is not, and that many, of not most, people using the term pragmatic are confused about the nature of Data Management and Governance.
So what does this look like in practice?
“Be pragmatic, but do it right. Just put some process around it.”
So you go to work and start designing a lightweight operating framework, but now someone steps on the breaks and tells you that setting up an operating framework is exactly the kind of non-pragmatic stuff they wanted to avoid. Key here is that planning and designing a TOM is not a theoretical exercise at all (after all, deciding who will work on what and how these activities should be coordinated is as practical as can be), yet it is quickly dismissed as non-pragmatic. Similarly, you may try to put together policies, standards or plan an approach … definitely too theoretical. Maybe you want to run some awareness sessions with the business … when can we start cleansing data already?
Clearly, none of these things are theoretical. So what’s going on here? Well, it seems that in these contexts pragmatic has become a synonym for easy. Theoretical, heavy or non-pragmatic, on the other hand, are synonyms for hard. Cultural change is notoriously hard. But cultural change is also the at the very center of implementing Data Governance.
A large part of the nature of Data Governance is that it deals with formalizing already existing, but informal activities, collaborations and processes. These things are Data Governance, not merely theoretical concepts that can simply be ignored in favor of the practical bits. Realistically, if being pragmatic means “doing things with data” to you, you really are talking about Data Management, not Data Governance, which is primarily concerned with creating and formalizing the context to do things with data.
How do we move on?
Recently, I have begun asking people what they mean exactly when they talk about being pragmatic. If they mean we should have clear business-related goals, then of course, these are a precondition for any successful Data Governance initiative. Ironically, those insisting the most on being pragmatic, often don’t have such specific and measurable goals, probably because they considered putting them together as something too non-pragmatic. If, on the other hand, they insist that any degree of formalization equals non-pragmatism, then we need to have a long talk.
We also need to be clear about this: Data Governance is, whether you like it or not, fundamentally concerned with both formalization and cultural change. Dismissing these pivotal characteristics will only ensure that your data will not be governed at all. It being hard does not mean we should not be doing it, it just mean we have to work harder to achieve our goals.
For more thoughts about data and other assorted topics, visit my blog Not The New Oil.
