It's almost impossible for data to be effectively governed without the participation of data stewards, who work at the nexus of business strategy, data knowledge, and institutional memory. We think of data stewards as middle managers, people who head up business units or departments but who often sit a rung or two below senior executives. Now, your organization may have a different name for these people (data owners, data custodians, etc.), and, depending on the size and complexity of your organization, data stewards might exercise more or less managerial authority. Let's not get hung up on labels--the important thing is that these people are in your organization somewhere, and meaningful data governance is likely DOA without them.
These people make decisions about what data will be collected, how data will be used (at least operationally), and when and by whom this data can be accessed. Will some data stewards be more technically savvy than others? Of course. Some data stewards will be animated by policy, while others will experience this aspect of their authority as an irritant. From where we sit, that's OK. You want a diversity of opinions and experiences in this group of people, if for no other reason than avoiding groupthink.
It's all well and good to say data stewards are essential to data governance, but what does this participation actually look like? We have long been skeptical, mainly for practical reasons, of a model of data governance that is bureaucratic, meeting-intensive, and rules-oriented. People are busy. If they're forced to attend meetings whose topics don't pertain to them, they'll check out, and perhaps even grow resentful. If data governance looks like a series of edicts issued by distant leadership committees, people will observe them as minimally as possible, while focusing on completing tasks that they think are more important.
It's nearly a new year, and nearly everyone we talk to knows of, or is deeply involved in, some data initiative. Maybe migrating to new software, maybe adding new software applications and data sets to the existing mix, maybe revamping the business intelligence stack, almost certainly trying to improve analytics and grow data literacy. (More and more it's all of these at once!) At least some of your data stewards are going to be heavily involved in, or strongly affected by, these initiatives, and we continue to observe that these are among the best opportunities to exercise and grow meaningful data governance practices.
It's worth being somewhat specific about what it looks like to engage data stewards and other stakeholders. If you're mapping data in advance of a migration, it's essential to make sure data definitions are consistent. If you're adding new software to your ecosystem, that probably means adding new integrations; integrations are a well-known culprit for data quality issues, particularly around consistency and validity. Changes to the way you do BI mean new opportunities to curate data sets, to validate products, to revise business processes. It's hard to imagine doing any of these things properly without taking advantage of your data stewards' knowledge.
However, even opting for just-in-time data governance, or practicing data governance at the point of engagement, is no guarantee that you'll get the buy-in or participation you're looking for. In the past month, two different clients have come to us with complaints that their data stewards still aren't engaged. Without going into too much detail, we'll say that one client reports that data stewards are uninterested in key foundational work, such as defining data quality standards , or documenting procedures around knowing what kind of data they're capturing and what gets done with it, while the other client tells us their data stewards are unwilling to sign off data governance artifacts such as business glossary entries and possibly afraid to complete user acceptance testing (UAT) around data products.
This is certainly not the first time we've encountered situations like these, although they do seem less common than they used to be. Still, it only takes one or two reluctant data stewards to turn just-in-time data governance to just-about-never.
Where does this reluctance come from? Are they afraid of being held accountable for their decisions about data, or their explanations? Are they so accustomed to information hoarding that this is just second nature? Is this a peculiar way of ensuring job security? We doubt that malice or intransigence is the issue. It could be, of course, but we have worked with thousands of people who exercise stewardship over data, whatever their title, and overwhelmingly what we have seen is that they want their organizations to succeed, and they want data to be part of that success.
One of our colleagues is a job coach, and he tells us that a common problem among managers is the inability, unwillingness, or even downright refusal to delegate. We suspect that this data steward reluctance isn't dissimilar.
One enemy of delegation is the desire to protect employees, even though that can prevent them from learning and growing. This can be a case of protecting a particular set of employees, or it might be more a case of protecting a unit or department. So when a data steward is slow to sign off on some aspect of data governance, it may be that they have legitimate worries about data being misused or misunderstood. So business glossary entries go uncompleted, for fear of having overlooked something; key dashboards don't get certified, for fear of sharing them with people who'll misinterpret them. Data quality assessments don't get shared until the data steward is certain all the affected data, no matter how old or irrelevant, has been cleaned, for fear that a subordinate will get in trouble for inputting erroneous data. But the fact that the data quality assessment is happening is the critical data governance activity!
Another motivation might the fear of becoming irrelevant. If someone else can do my job, what do I bring to the table? We see this sometimes with data stewards who can get hyper-focused on details, especially if they have a technical bent. We have seen entrenched employees who can tell you how long things have been a certain way, but who don't seem particularly interested in why, and whether there might be a better way. We lean towards believing this isn't a fear of irrelevance, but instead a concern about investing time and energy for little if any return.
A third motivation might stem from a lack of trust: I'm afraid they won't do it right, or that they won't do what I want, or they won't do what I want in the way I want it done. We've talked in previous posts about how trust and a lack of trust manifests in data management and usage, so we won't dig deeply into that in this post .
When asked, intransigent data stewards often say they don't have time to do extra work. We observe that they are already spending time explaining data, making data decisions, using data in the course of their daily work. Our argument is that just-in-time data governance isn't really extra work, it's more the formalization of activities and conversational outcomes that have to happen. But it is somewhat different work, it might require the use of new tools, and while it's likely to save you time and effort in the future, "future you" isn't here right now, behind schedule and overburdened with assignments.
The payoff for making data governance activities part of your everyday data operations is what it makes possible. Data stewards have a wide range of responsibilities, and they need to exercise judgement and maturity around what they focus on. If data analysts can take care of something, then stewards can deal with other matters, or have better input into planning and decision making. The challenge is how to make that payoff attractive and attainable.
Organizations can probably compel some level of participation by reluctant data stewards through changes to job descriptions, by including this work in performance reviews, by restricting access to data applications and products. In the short term, steps like these might move the needle a little bit, but in the long term they're almost surely counterproductive.
If your data stewards think they have to protect their team, why might that be? If they are skeptical that extending their effort and knowledge in a new direction will be productive, how might you persuade them? If data stewards don't trust that colleagues will act appropriately on their shared expertise, or that subordinates won't fulfill data governance tasks to an acceptable level, what steps might you take to build and maintain that trust?
When we work with clients, we try to focus on those tasks and activities that solve problems, and that relate to and provide benefit for the data needs right in front of them. If your stewards aren't exactly jumping at the opportunity to get involved in your data governance activities, are you sure you're solving problems and addressing needs?
We hope you found this blog post useful. Also check our our data governance spotlight resources located at https://www.datacookbook.com/spotlights. IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance, data intelligence, data stewardship and data quality initiatives. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
Photo Credit: StockSnap_LERRJPTMHP_SadWoman_ReluctantSteward_BP #1302