As a company that specializes in providing data management and data governance services and software, we spend a lot of time speaking with and talking about data stewards. A lot of the work data stewards perform is prosaic and largely goes unsung, but it is essential for the continued functioning of any modern organization or business. A few months ago we wrote that data stewards are often put in a position where it's difficult for them to succeed, and we want to expand on that topic in this blog post.
Very few people have the job title of data steward, and in our experience not all that many more have a job description that actually features the phrases "data steward" or "data stewardship." And in all but very rare situations, being a data steward is a fractional assignment, part of a larger set of business duties and responsibilities.
When you name someone in your organization a data steward, whether as part of a formal data governance framework or somewhat more informally, the good news is that that person will already have been performing many of the duties we associate with being a data steward. As we noted in our earlier post, that doesn't mean these duties are performed equally well, or approached with the same expertise. So simply identifying someone as a steward, without properly elaborating the functions and expectations around that role, likely changes nothing.
It's worth pointing out that, yes, everyone in your organization who works with data is a data steward of some kind. In our webinars, and in our data governance practice, we have a sort of taxonomy of data stewards, reflecting which aspects of data these people specialize in or oversee.
The most visible data stewards tend to head up business units, and they exercise authority over data in a given domain, usually but not always from a functional or business perspective. If the organization is large enough, these stewards will often oversee several subject matter experts, who may well assume some of the operational duties of functional or domain stewards.
Elsewhere in the unit, or within the organization, we'll often encounter multiple varieties of technical stewards, whose duties in this area may revolve around information security, or data infrastructure, or business intelligence & analytics. This aspect of data stewardship is generally informal, sometimes to the point of invisibility!
Many organizations feature enterprise stewards, who are tasked with taking a cross-domain view of data and considering governance from an organizational perspective. Sometimes enterprise stewards take the lead on data policies, but other times organizations identify individuals or teams to serve as policy stewards.
One suggestion we make to clients is to consider a new type of hybrid steward, possibly a subset of enterprise stewards, who may be able to fulfill some basic steward duties but who also perform a triage function: routing questions, clarifying requests, performing initial research, etc. We're not sure what to call these people (Data Navigators? Data Concierges?), but the work is critical and can often fall through the cracks.
Should your organization feature this many categories of data stewards? Too many organizations default into assigning one data steward to cover a domain, and lump all of these types of stewardship into their portfolio of data responsibilities. We've been lucky to work with some incredible people over the years, but we've yet to encounter anyone who can cover all this ground successfully and still hold down a full-time job performing the actual work of the organization!
Your data steward matrix should undoubtedly reflect the people you have available to fill these roles, but it shouldn't be constrained by that. Some of your offices are tightly bound by laws, regulations, industry practices, and similar strictures, and they probably have great policy expertise. Other offices might be fairly minimally regulated, so perhaps policy stewardship for these areas is not an ongoing requirement. Some people have strong functional and technical knowledge in one domain, while others might have technical expertise only--but expertise that spans multiple data domains.
Thinking about these varying stewardship lanes, and who occupies them, and whether they might be spanned horizontally - across lanes - or vertically across domains, is a useful exercise. And if you haven't done it in a while, it's worth revisiting, given how quickly the data landscape shifts beneath our feet.
But let's come back to our earlier observation that data stewardship is fractional, meaning it's only part of a person's job expectations. If it were us, we'd want to make sure that our stewards were focusing that fraction on key data management issues: maybe that's fielding questions about data, maybe that's classifying data, maybe that's vetting data quality rules and standards, or investigating potential data quality issues. Data stewards with significant subject matter expertise probably ought to be deeply involved in creating and maintaining a business glossary, but stewards who are more technically oriented probably should focus their energies on curating data sets and certifying reports or dashboards that reference those data sets.
Ultimately, the question we are asking is, how do we make sure that data stewards are most productive and adding value as best they can during their fractional service? We think it might come down to three key principles: respect stewards' judgment, route work appropriately and consistently, and don't maroon stewards on an island.
Respect their judgment
Stewards' scarce resource is judgment, not hours. Protect it by making the role legitimate, giving their decisions weight, and keeping the work small enough to fit.
- Make the fraction official. Stewardship that isn't in the job description, the performance review, and the manager's expectations loses to everything else.
- Back their authority. People won't spend scarce time on decisions that get overridden or stuck in approval layers.
- Separate drafting from deciding. Approving a draft takes minutes; writing from scratch takes an hour and tends to sit unfinished.
- Size the work to the fraction. A backlog defeats part-time people; a steady trickle of real questions doesn't.
Practice triage
Every question should reach the one steward who can answer it, already framed so they can answer it. Unrouted questions waste fractional time on working out who should respond, and mismatched ones (a join-logic question sent to a functional steward) produce slow or weak answers.
- Start simple with triage. Sophisticated tooling is not a prerequisite. A static web page listing domains, stewards, and key links, plus a short request form per domain, is enough to begin; add workflow or automated routing as volume grows.
- Make the intake do the clarifying. A form or even a quick conversation that asks which report, which number, which term, and who is asking moves investigation onto the requester.
- Match questions to lanes. Send operational questions to functional stewards, logic and source questions to technical stewards, and complex business or policy questions to enterprise stewards. If there's a published answer to the question, have the triage team supply that answer before routing the question down the line.
- Keep a person on coordination. Tools route; people close the loop. Name a coordinator (even a few hours a week) who confirms each answer is recorded in the system of record, so the help desk doesn't decay into lost email threads.
Don't leave them alone with it
Much stewardship is done independently and asynchronously, but it should never be done in a vacuum. Each form of collaboration below does a different job, and none substitutes for the others.
- Staff domains with teams. No one person covers every lane well. Domain teams make sure each question reaches the right kind of expertise. If possible, pair at least one functional and one technical steward per domain, with enterprise stewards shared across domains.
- Plan for backup. A domain shouldn't stall when someone is out or leaves. Name a backup for each steward, and use the recorded answers to onboard a successor.
- Build a community of practice. It keeps stewards consistent across domains, so the same problems get solved the same way. Hold a short forum, perhaps only once a month, and use it to share solved problems and recurring questions, not as a status meeting.
- Record the answers to questions, or other written outcomes. Treat the shared record as the collaboration space. For asynchronous work, recorded answers are how a backup picks up a thread, a technical steward extends a functional answer, and a neighboring domain avoids contradicting it. (Pro tip: the Data Cookbook has been designed explicitly to address this need.)
- Make the payoff visible. Stewards keep investing when they see their work used, when their time isn't wasted with repetitive or irrelevant questions, and when their contributions are publicly valued.
This vision of data stewardship is designed to meet stewards where they are, to take advantage of their knowledge and experience, and to free them from the burden of tackling assignments they aren't suited for. And if you have a different name for answering technical questions, or reviewing policy suggestions, or managing a request queue, you don't have to change its name. Maybe you don't even need humans in all these roles. But without the role and the route, we're not sure you'll ever fully secure the responsibility.
We hope you found this blog post useful. Also check 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 their data governance, data intelligence, data stewardship, artificial intelligence, 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.
Image Credit: pexels-olia-danilevich-5313161_DS Coordination_BP #1336
