 My name is Jim Johnson. I currently work with higher right. I just started that job last week, so I'm not giving this presentation on their behalf. This is a amalgamation of best practices I've learned on my own from a couple different governance programs as well as participating with DGPO. So, this is the most boring slide we have. I'm just going to highlight one fun fact. My first college job was in the manufacturing plant where the COVID Pfizer vaccine is being manufactured. So, it's kind of cool. We spent a couple of years digitizing decades of clinical research and drug trials, and I'd like to think that somehow, that little catalog kind of got them on their path to where we are today. So, very interesting. The rest is, we'll just kind of skip past it. Okay, we have four topics and 45 minutes to cover them. So, do my best to stay on time. This is what it looks like. We're going to talk about four different areas. Oops, the roles and responsibilities, traits and skills, find, go and retain, and then community and success. So, they kind of like stack on top of each other, start with a foundation, and then really increasingly help your stewards succeed and bring them all together and celebrate all that. And then we'll get to the end. We'll have some open forum. Okay, so let's talk about purpose. So, understanding, how many of you are new to data governance first time? Okay, plenty. How many people are a team of one? Okay, yeah. I feel your pain. Yeah, that's not easy. Okay, so these comments, I love this slide because these comments, I actually heard during meetings and I use this for onboarding, both owners and stewards. And I can't tell you how many people would say, oh my gosh, I just heard these comments this week. I'm like, yes, because they're from our company. And this is how we talk in meetings and argue over our data. And what they reveal is like this really critical gap in strategy. I don't, hang on a second. This is not the right deck. This is a deck you might have seen yesterday. Yeah, this is not, I have one here. So what's the best way to, don't worry, let me get to where it is. Do you want me to keep talking? So, the way we start, sorry about that, a little snafu. When we bring up the slide deck, what I typically do is define stewardship up front. So the first slide will show the definition of stewardship from Miriam Webster. And I link that then to data, right? So stewardship, if you like, there's two definitions and they both revolve around a steward is entrusted with taking care of something conscientiously and responsibly, it's words along those lines I'm paraphrasing, something of value, right? And so you have a person who is taking care of something of value and the people are stewards and the something of value that they're taking care of is data. So if you can help people understand that, that's really important. It's really no different than HR people taking care of employees or finance taking care of money or IT people taking care of technology, same kind of concept. So that's where we would start. And as soon as I get my clicker, we will catch up and we'll make faster progress. Okay, so this slide looks better. So here are the four areas we'll do faster than 10 minutes each this time. So here we go, there's the definition. You can see the two parts and if you can help people connect to that, that's great. You work with a financial advisor, he takes care of your money. There's lots of examples that you can use to help people connect to these concepts. Okay, what they really, when we talk about the data itself, we're really talking about data assets, right? A single piece of data here at the bottom or any of these containers of data at the top. And that is exactly what they're going to steward or carefully take care of for the company. And if you can, you might wanna think about unstructured data as well. I'm gonna focus mostly on structured data, which is much easier to handle, especially from the early days of building your data governance program. You can rearrange them and then you can pick which stewards are responsible for which data assets. A variety of titles that you can use. I choose to go the simple route and use titles that are kind of self-explanatory. If you're an analytics steward, it's one of your analytics thingamabobs. If you're an application, then you've got the GUI front and everything behind it, kind of a thing. The name, the title that you give them is really not as important as clearly defining what you expect from them, okay? So you'll see a whole bunch of titles. All stewards are responsible for helping build your glossary of business terms and then documenting their tribal knowledge. All that rich context of, well, this column is XYZ, but we really use it for this other thing kind of stuff, right? That phone of friend, NOAA guy network kind of content that we're always trying to chase down. Here is an example of all the titles that I found at data governance conferences, as well as out there in literature from some of our experts. There's no science behind this. I just kind of laid them out where I think they made sense because the two dimensions that for me are relevant are whether you think local or think enterprise and whether you're business or IT because there's different types of data assets you're gonna have access to and your understanding is gonna change. So may not be exact, but you can see there's a variety of titles, right? And some of them like data object one is an interesting one, like isn't every data a data object? So Siner uses that term, particularly for master data sets. So if you're gonna use a term like that and it's not self-explanatory, you really have to be clear with your stewards what exactly they're responsible for managing. So the point here is, choose the titles that work in your culture. There is a variety to choose from, but you have to define exactly what they are responsible for. And here's kind of a high-level overview of what they're responsible for. I see sort of four major functions, primarily they're knowledge keepers. I mean, these are the people that hold a lot of knowledge around data that we go to for help. If we can get them to digitize all that knowledge inside their heads, awesome. So they really want to keep that knowledge and keep it accurate, right? Document and keep it accurate. They also are gatekeepers. We want to make sure that people are using data for the right purposes, that they have access to data. I worked in one company where our corporate analytics team, we had SQL backend and a Cognos BI front end, and they went in and created a report and then sent it out to all our field operations managers and we were like, oh God. But they didn't send out the report, they sent out the report results in Excel, completely bypassing our security system and our setup because in Excel it's everything, right? They could see everything but the people in the field could only see their little slice of the operations pie. And that error, that sort of accidental error, almost cost us a million dollars in licensing fees for Microsoft. We got around that, fortunately, but that's the reality. So they might have access to a lot more data and they need to be aware of exactly what that is and gatekeep correctly. They're also quality inspectors, make sure the data's right. They oftentimes have a lot more knowledge around what data's good, what data's bad, et cetera. And then they're change agents. We want them out there evangelizing, promoting data governance. They're the front end ambassadors for your program. So four major functions. This is an example of a framework we used for a one week RIE, Rapid Improvement Event, which is a lean term, get things done in a week kind of a thing. And it shows sort of how all of the pieces come together for a variety of, excuse me, stewards and owners that we leveraged during that one week process. So everything is connected. There's no line that is disconnected because it's a team sport. They all have to work together. They all have pieces of that pie. And if we have time at the end, I might be able to give you some statistics around what that looked like. Number of data elements, data sources, that kind of stuff. It was pretty effective actually. Having that big picture helped several stewards really understand how they fit into the bigger mechanism. Okay, potential. So we have to figure out who is really fit to be a steward. Not everyone is, right? So what does that look like? Well, we're gonna go back to 2015. Deloitte has this analogy called purple people. And it starts out with, you know, the business speaks red, IT speaks blue. They're sort of different languages, different cultures. And you put them together and it's like Chinese and Greek. They just don't really talk to each other very well. And so incomes, the purple people and they're bi-cultural, bilingual and multi-skilled. And they're the translators. They're the ones that help business and IT sort of get along. If you hear me say biz, what I really mean is not IT. It's all the other lines of business outside of IT. So purple people are analytics folks, anybody that's crunching data all the time, your EWBI people, data governance people, or purple people, those are the people to look for to activate a steward. Really, really well suited. They're bridges, really. I mean, my perspective is your stewards are the folks that help everybody at the table sort of get on the same page. Make sure we're talking about the same terms, the same definitions, all of that, right? So they translate, from simple to complex, whichever is necessary for the audience, they're able to quickly and adeptly sort of transition between simple and complex. They also separate fantasy from fact. I had this longstanding argument with one coworker who insisted that all of the data's bad because this other department has really bad processes and she kept saying that, it was driving me nuts. And I pressed her on it, I finally got her to answer after about, I don't know, six weeks of really just dinging this other department. There were six facts numbers that were bad and that six was leading her to blame that that other department for all of their processes around this data. And there were like something like 80,000 records. So six out of 80,000 is not a bad defect rate, but for her it was like chicken little kind of a thing. So we need to understand hard facts and separate that from some of this anecdotal stuff. And stewards really are great people to do that. They should have really good written and oral communication skills. They're gonna be liaisoning with everyone across the organization, representing DG across the organization, so good communication skills. And then they have to see not only the future of where we wanna get to with data governance, but also perceive the risks along the way and be willing to take risks sometimes to help us get to that future. And some of those risks revolve around people, culture, politics, that kind of stuff. So look for people that get excited for data, right? You know who they are? Their eyes light up, they get all like super energized. Enterprise thinking is a really good trait for stewards. Not me, my department, my cheese, don't touch my stuff or don't peer into my black box operations. Those are not good. Those people probably are gonna struggle to start thinking enterprise, but there are people that already think enterprise and they're kind of frustrated with the sloppy processes and stuff like that. You hear those kinds of comments, talk to them. See if they're sort of enterprise thinkers. See if they have adoption spirit, right? Like I'm gonna cheerlead, I want change. This is painful. I wanna do things differently. Great, let's talk. Maybe you can be a steward in the program kind of a thing. And then last but not least, obviously passion for data. They're gonna be the ones that are going to help you grow your data literacy and help you become more data driven, right? Everyone outside of the purple people, they'll have to learn what data driven really, really means. Okay, now we're gonna get to proficiency. So we kind of explain who they are and what they're responsible to do. Now we're gonna get into ways of finding and growing and retaining them. If you don't keep, it's like an employment, right? If we don't have good employee retention, people are gonna leave, they take all that tribal knowledge with them. That turnover is pretty big. Stewards have a difficult job. They're out there facing the business. I don't know how many of you have cultures where business blames IT for all the data problems, right? Every company I've worked at does that. There's somebody in the business that does that. And IT on the other hand is like, they don't know what they want. They never ask for the right things. It's this back and forth kind of a thing. Gotta cut to the chase on some of this and have a conversation that revolves around maybe a repeval kind of process. And one of the ones that we use is, here's six questions. Just let's answer them about what you're trying to accomplish and help us understand what that looks like. If we can get to really concrete answers and have consensus on all these questions, you're halfway there. Just get agreement on definitions and what data source are we gonna use? And is that data any good? Have you actually profiled that data to make sure? So Stewards will help facilitate that conversation. So we, in my last job, we were starting to train our Stewards on this kind of rubric. It was very successful. You can also take this and translate it, right? So you have people in your organization today that are answering those questions called at the PhonaFriend network, right? You activate one person. They talk to two more email threads, conversations by the end of that sort of chain of events. You've got like 25 people in two weeks of pass and you still don't have an answer. At your PhonaFriend network, unless you know the right experts to call and you can cut to the chase and get an answer directly from them, these people are your Stewards, right? So we want them to digitize how they're tackling all those questions and answering them. And we're gonna map all of that too. Basically, the data dream team, right? If you can elevate your Stewards to be those experts and position that, communicate that. They're no longer hidden behind, you know, un-invisible walls. You know, that guy back in the corner that's been here 30 years that knows everything. No, we want them out in the forefront. Advertise your Stewards. Communicate who they are. Publish a directory of who they are and what they're responsible for so that everybody can much more easily and quickly find experts to talk to. These are your data experts across the organization. And each of these questions sort of maps to a data governance function you can see at the bottom. Okay, so you might want to consider certification processes as well. So this is a really good idea. For any of your data assets, what does good look like? If I am not a Steward, I'm on the consumer side. Executives, managers, other lines of business. How do I know how to trust this asset that you're putting in front of me, this report, this dashboard? You can come up with your criteria and if all those criteria are met and the Stewards are executing all that, you can call that good. And that is the sign for deploying it to the production environment. Now these are just examples. You want to keep everything as simple as possible. If you get overly technical or overly specialized in jargon, you're really going to lose people. The best common thread across the organization is keep things in plain English. Of course, behind the scenes in your tools, you're going to use the specialized jargon. But when you're meeting together, if you can keep everything as plain as possible, you'll have more people understand what you're talking about. So come up with your criteria and then you're going to, if you saw Scott Pichy's keynote this morning, he talked about workshops. Great idea for hands-on training people how to do this. Come up with some dummy data sets or real data sets, walk them through the process a couple of times until they're comfortable with it and then have your centralized, if you have a hub and spoke model or a centralized team that manages your production environments, have them just double check that all of these items are met before they deploy anything to the production environment. Incorporate that in your change management process. Your stewards are going to be the nuts and bolts of all of this. Obviously, here we've got analytic stewards for the left two for A and B and then on C, that's all of our stewards, right? So it's kind of an example. And these are criteria that we were actually using in my last job for. It was a healthcare job. So if you're in healthcare, we were on Epic and we had a slew, actually the report checklist was about five times longer than this. So these were the key highlights that really relate to data governance. But you can keep it simple. You can grow it over time. Don't overcomplicate it at first. The point is, fulfill all these and that's what gets you that symbol or that certification verified mark in your catalogs or on your reports and dashboards. One of the things that we did in a previous job on all of our reports and dashboards, we put a couple pieces of metadata on the reports and the header, we had the last update date, last refresh date for the data. And then in the footer, we printed the corp ID so we know who ran it and the runtime. So that anytime we got questions, invariably you'll have questions like, I'm looking at the report and the data is not there. And what's going on? It's wrong. It's like, well, you're looking an hour before the job runs, right? So there's education behind all that and surfacing some of your metadata, that might be requirements on this checklist, right? That was our version of catalog and we didn't have a catalog tool. So we said, you know what? We're gonna help some of our users understand more about what's going on behind the scenes. We got to get all this data in and loaded and we might have errors along the way but here's the time that you can expect that data. Make that visible. I mentioned that there are, you can add symbols. Your catalogs might have status fields with category codes. You can also add visual symbols onto some of your assets especially reports and dashboards. If you have this little, little moniker up in the right hand corner or somewhere on the report that tells me, yeah, this is good and certified and I can go look up stuff, that's gold. That symbol alone is gonna convey a whole lot of meaning underneath the iceberg and it's gonna help build trust for everyone. We did a version of that in one of my jobs and people knew to look for that and in meetings, if people came with their own reports that they had manually processed in Excel, it was music to my ears the moment someone said, no, that doesn't have the symbol. We're not using that. Love it, great, you've learned, right? Use the trusted data for your decisions. This other stuff, caveat, emptor, be aware that it's not up to snuff the way we're doing it here in the data governance world so can't guarantee the data. You wanna connect stewards to your vision. They're change agents, right? Data governance is change management at the enterprise level and change management is not easy. It's strategy, culture each strategy for breakfast. So they're out there on the front lines and we gotta connect them to the fact that we wanna become data driven and in order to do that, we're gonna have to change your mindsets because we can't change behaviors until we change your mindsets. So we're gonna onboard you, educate you, get you comfortable and then we're gonna start changing your behaviors through the processes that we define and train you up on. So you might think in terms of a training curriculum, beginner, intermediate, advanced kind of a thing. That would be great. Maybe certify these roles when they fulfilled all the training requirements. Maybe even giving them some sort of reward system. Talk to HR and see if they can kind of help out. Annual recognition, stipend, something like that. What you're really doing is helping your expert, your data, your stewards rather, become your enterprise-wide data experts, that go-to team, published, known, completely transparent phone-a-front network. You wanna promote the data lifecycle. A lot of folks that don't work with data don't understand a data lifecycle, but if you look at a lot of other major business functions, HR, finance, IT, there are some version of a lifecycle for those assets. This is really no different. From the point of collection or recording to the point where you gotta purge the data from your systems, there are various stages. There's a lot of different models of lifecycle. Choose one, apply it, help your stewards understand it and sort of form all your processes around that. Sort of like, if you're familiar with DevTest, PROD migration or SDLC processes for IT projects, same kind of concept. You can do that with data. It's not overly complicated. It's difficult to adopt though, so it takes a lot of hand-holding. Your stewards are also gonna champion data transparency. So this idea of democratization, what we really are talking about is, we're gonna open the hood and let you peer inside, kick the tires, and really understand what's going on. And do that in a very safe and transparent way so that you, with your own eyes and your own hands on, experience can build trust in what you're seeing. If you can't see it, there's a lot of distrust around that. And I've been to meetings where folks argue or your team came up with this number and our team came up with this number and I don't know what you do and that black box operations does nobody any good. You gotta sort of open that up and let people see what's going on. Cataloging really helps with that. And then obviously data trust. The end game really is we wanna trust our data because if we don't, how do you trust the decisions that you make on the data? That's a much more difficult conversation to have. So if your stewards are doing their job, they're trained up, they're smart, they've passed your certification processes if you have those and they're really comfortable having all these conversations, they're going to help you build data trust across the organization. And that's exactly what we wanna see. So I love this slide. I've used this a lot. You hear me say biz and IT. There's actually a third side of the triangle which is sort of your audit and compliance services. So your InfoSec folks, your privacy, your policy, all that. Big brother, oh my gosh, I don't like them. I'm 100% integrating with Scott this morning when he said, I want the compliance folks to be my best friends. That was the approach I took in my last job, healthcare. They were notoriously viewed as difficult and I repeatedly told people, I don't think they're being difficult. I think they just have a lot of challenges that they have to deal with. And then when the problems happen, they've got the onus of sort of investigating and researching and trying to figure out why did it happen? Did we violate our processes, et cetera. Not the easiest job, but they are very, very much purple people oriented, especially when it comes to data protection, making sure that people have access to the right data in the right places. And so these three areas, if we take that red and blue, I'd love for there to be like another color that didn't mess it up, but I think ACS sometimes comes in and doesn't necessarily speak IT and business either, but I think they'd do a better job than a lot of business and IT folks, at least the departments I've worked with because they've had to dabble in technology. And so they've learned a lot. A lot of their policies will relate to that. Data governance sort of sits in the middle. I look at that as sort of the pendulum that swings inside the triangle and we don't want to get too extreme any of those points on the triangle because you can see each area wants different things and some of them are in contention with each other. And so if we can kind of keep them in the middle, be the glue at the table that gets everybody together and talking and let's agree on a sort of a common approach and decision then you're gonna keep everyone somewhere in that middle and that's where it's gonna be easiest. Okay, props. How do you position your stewards and your community for success? I said earlier, this is a really difficult job. They're front lines people. They're in the trenches. If the data's wrong, they might be getting blamed for it, right? There's gonna be, they might, would definitely already be getting kudos too for everything that's working correctly. I think as human beings, we tend to sort of look at what's wrong a lot more than what's right. We sort of call that out. We should really be celebrating what's right a little bit more. They're on the front line. So we really need to help them come together and feel like they're part of this really important role in team across the enterprise. One way that you can help with them is to build sort of a data defector or data issue or data challenge or data quality tracker, whatever you call it. What are your data problems? Your executives, I guarantee you, do not know all the data problems that people at the lower levels are faced with. I've had this conversation with so many CXOs and it's problematic. So the accidental other slide deck that showed that comment bubble, there was one comment on there that came from our CFO. And we had a lot of conversation on whether to include that on the slide. And our council chair said, you know, we want to include it, but we're gonna put it in the lower right where it's like not so prominent and maybe no one will notice. And his comment was, I don't have any data problems. My team fixes all my data problems. I'm like, wait, you don't have problems but your team fixes them? So you personally don't have problems? It was kind of contradictory. But his point was my people repeat all of the analysis that all of the other lines of business do because when I see a number I don't trust, I have my people do it all over again. And they were the only people that he trusted. I really don't know what the problem was because we never really got down in the nuts and bolts of the data to say, okay, what's wrong with the numbers? Now when you have multiple teams coming back with different answers, there's obviously something wrong somewhere. They have different business logic or something. But this tracker becomes really important. Get everything in there and organized and then categorize it. Make it searchable and transparent to anyone. SharePoint lists, for example. You can have all your metadata on there, completely transparent read-only to everybody. Let people go in there and see what's going on. Trace it back to your source systems. Trace it to your line of business. Trace it to your data sets. Whatever categories you want, these are just examples, but you figure out which ones will work. You definitely wanna have a sense of how many regulated or sensitive data elements are involved in your challenges because that's risk. If you have too much PHI, PII, PCI rolling around, you might prioritize those a little bit higher on the list. And you're gonna have to prioritize them somehow, right? So when you triage them, you wanna have some sort of objective rubric to apply. If you do it in something like SharePoint or Excel, you can use formulas to do that. Make it objective and numerical based. Come up with a score and use that to drive your prioritization. It's much better and easier and more efficient than having subjective conversations and arguments over it. Measure the impact of those problems. This is kind of difficult to do in some areas, but the number of defects and a lot of time that people spend talking to others about the problem, that's a double labor hit if you think about it. So if I have to go to someone else, if someone comes to me and says, I have a problem, can we talk? It's two people talking and those two people are talking about a data problem and not doing their jobs. That's time. And if you can get a sense of that time, know what their hourly rate is or come up with a super, I call it a super mega blended rate. We used $100 an hour in our IT shop for all estimates of resources. It sort of factors in electricity and all that kind of stuff from labor all the way up. And it tended to be pretty close. Use something like that, but get to a dollar amount and start showing that as well. And that sometimes is surprising. There was one exercise we did. We ended up with four. We had problems with two metrics and there were four financial analysts that spent on average about 10 hours a week doing this every month. And at the end of the year, it was like 120 spreadsheets. I mean, imagine that with all the data inside because they were downloading from the transaction systems, processing it all and then still fixing things later. There's a lot of cost to that. And if you could figure out all the business logic and automate that, that is time savings back for them to reallocate to more value add activities. Defect rates, make sure you track status. And if you have any ability to track the amount of time you spend on remediating it, that is insightful as well. Lot going on here, but the whole point is create that transparency because if you're not doing it, it's invisible. If you're in IT, you're kind of familiar with the concept. You know, we have incidents and requests and things like that if you use service now or remedy. What does the business do for all their issues? We don't really have traditionally a data defect tracking solution at the level of remedy and service now unless you build that out. Service now is not a bad option. We were actually starting to explore that in my last job. Didn't get too far because I left, but we were on the right track. Sensitivity label. So this is about data classification. Be aware of what regulations you have. Those all require much more attention and you're gonna have some rubric like this. Your stewards should be experts in this. Your analytic stewards are gonna have to understand for all of the data feeding into their reports and dashboards what is the classification for all of this and are the consumers of these reports and dashboards already in the role-based security system allowed to see all of these data elements. If they are not gatekeeping that you are going to eventually expose data to the wrong people. So you'll see different rubrics for this three, four, five, six levels, whatever it is. I like the polar opposites. It's either public or regulated. These are clear. If it's regulated, there's a law. If it's public, it's on your annual report. It's on your website. These are clearly reported things. Everything else is sort of in the middle. Start with internal and then work with your stewards and owners to decide what's gonna be confidential. Some of us are no-brainer. I typically use the example of I wanna see HR salaries. You're not gonna get access to that unless you're in HR. HR management is probably gonna say only my people should see that data. Great, let us know which one so we can tag those and then train all our stewards or update our catalog to reflect that so that they're aware of all that. If you don't do it, you might end up in crisis mode. The majority of breaches happen from inside so all of your stewards are helping you mitigate those risks. Very important. If you can do all, a lot of what we've already been talking about, you can move from role-based security into more attribute-based security. So this data is X, it's Y, it's Z, it's confidential. It comes from HR and it's for management eyes only. And when you get those attributes well-defined, you can actually move into policy-based security where you will be automating all of that. So you can take your HR data about employees, pipe it over to your security system, upload some of these rules, munch it together. I'm vastly oversimplifying this. And then automatically, dynamically, you can apply some of the security on the fly. If you're in California and you hit websites and you see all those cookie alerts, that's part of that, right? I'm either a repeat visitor or I'm a new visitor. If you clear your cookies, you can go back. Sometimes you'll have a slightly different experience. That's what they're doing. It's really cool, in my opinion, I'm from San Diego so I love the fact that California leads the way on some of these things. I like having control over what cookies, big brothers, is spying on me with. Okay, here's a list of common regulations. Now this is not comprehensive. Just examples of federal, state, local, here in the United States, those kinds of laws and regulations that our stewards need to be aware of. And then a couple international. So there's way more than this and I think going forward, there's gonna be an ever-increasing amount. So many data breaches these days. I think it's just a matter of time before we get much better at all of this. So make sure your stewards are aware, the right stewards have to be aware of some of these rules and regulations and definitely partner with your compliance side. If you have a company policy that calls out which data elements are regulated, that policy has teeth, your classification has teeth and you can create much more accountability across the organization and have those conversations with folks to, you know, we need to protect this data because it's regulated. Show value, your stewards are doing all the work, right? The data governance office doesn't do data governance. We're sort of coaching everyone else in a DG role what DG is and how to go about doing it. So if you can measure progress in your program, particularly any of the metrics that relate directly back to steward work and attribute it either to stewards by domain or stewards by business, line of business, you'll get a lot more accolades. It's really important to position them as people who are helping change the culture and also get a much better handle on data. So just examples of metrics up there. So you also wanna build a community. This is probably the most important slide in the deck about your stewards. You gotta bring them together. You know, if you don't, how do they sort of commiserate and celebrate? How do they learn from each other and share best tips and tricks that they've learned and some of the tools that they use? Variety of ways to do that. Here are some examples. You know, maybe you have an annual reception where you bring them all together and toot your horn and maybe get a couple photos up there and some awards or something like that. That goes miles. Sometimes the intangible rewards that we give our employees that work the hardest go way further than the tangible, right? Give me accolades. Don't give me a dollar raise. I'd rather have like, you know, recognition for the hard work I've done. That's the concept behind annual reception. You could have blogs, have them tell their own stories. That's great because anyone else can go consume all that. You know, maybe put a character limit or a paragraph limit on it. So in a couple paragraphs, I could consume that in a couple minutes. Pretty effective. Monthly forms bring them together so they're aware of what's going on. Any sort of changes in company direction or strategy or crises or fires that are popping up. The monthly forms are a great place for them to learn and network with each other. Newsletters, if you have, if Markham or HR or any sort of internal communications are going out from your lines of business, tap into those. I've worked at companies where they have like a manager hot sheet that goes out once a week. I love that because it sort of gave me a warning of what was coming and what we would have to talk to our employees about. That's a great vehicle for communicating some of these pieces and celebrating the steward successes. Success stories, these are always, always effective. If you can have people tell stories in their own words, that is awesome. Your stewards, based on their role, are gonna have different stories, right? We had, my last job we worked, I helped the DBA manager, they had already inventoried, I think over 25,000 SQL database instances across our organization. He was having a hard time managing all of that. I worked with him to sort of meta tag that catalog. He kept saying, I asked him, where is he? He's like, well, it's in SQL. That's what we do. And I'm like, okay, that's cool. Maybe we can get it into service now so it's more visible to other people because only your team can see that right now, right? So that visibility was missing. But I worked with him and his team was so elated over how we made, with a couple tweaks, add some metadata columns on that table, made it a lot easier for them to work with it. They're thinking IT-like and DG comes in and helps them learn a little bit more business, make it easier for these people that don't understand IT. So that was a good success story. We actually shared that across our IT department and he got some kudos for that. That was kind of cool. Okay, this is an example of, in healthcare, we did that one week RIE I talked about earlier. We translated COVID to the language of data. So we got this definition from Health and Human Services. This comes from the federal government. Midweek, they changed the definition on us. So if you think back to all of the news media about like, oh my God, the numbers keep changing. Well, part of it was because the definition was changing. This is literally what we were dealing with. The three caveats that we had to sort of qualify the definition with in order to make sense of it because there's words in here, like what's impatient mean? What's the time the data's collected? So put some anchors there and then translate that to a data definition, right? So if we break that down, you can kind of see all of these different areas. So I walked all of our stewards through this process because each of these is gonna map to like a different piece of data and maybe a different data domain, okay? Very important because we have this definition. Our infection control expert was the expert in all of this. Anytime someone had a question, she'd go back to HHS for clarification. We also had California to deal with at the same time. It'd be great if those definitions were the same but they weren't, that was part of the problem of aggregating all the data, but there we were. So where do we end up? Well, we ended up kind of here. You can see in the yellow and the purple boxes, the yellow words are our data domains and then inside was in white font is the data elements that we needed. So we needed about six, seven, eight different data domains across the organization plus a whole bunch of glossary terms like what's an outpatient area in a hospital? Depends on what's happening to you and where you are located and some beds are inpatient and some are and so there's all this business logic we had to work through. Crazy, crazy, crazy stuff. We did that in a week though and I think we ended up with, it's on my laptop, I think we ended up with something like 10 data domains. We found a new one. We had over 121 data elements that we needed to crowd for two COVID metrics and it was number of COVID patients and number of COVID deaths. You think there's a number of hospitalized COVID patients, excuse me. We had over 40 different COVID metrics that we were tracking, counting patients. Only one for deaths. That's the sad part of this whole story. That was a little bit easier. Although there was complications in the logic of if I had a heart attack while I was in the hospital, what was the real cause of death? Things like that. There were some nuances that had to be worked out and we relied on our HIM, our Health Information Management Department. They're the ones that reconcile the patient chart, make sure all the coding is correct. They were the ones that ensured that whatever is on the death certificate match what the doctor said, this is the primary secondary tertiary cause of death. So there was a lot of complication in that and those definitions changed as well. Very, very, a lot more complicated than it looked. Our council was like, oh, it's just two metrics. Can we get that done in a week? I went, well, we can try. And then when we went back and shared it, one of the council members said, I thought we were doing all 36 metrics. And I'm like, yeah, no, team of one can't do that. Like it was a 73 hour work week. I won't do that again, by the way. That was way too much. Here are the results. So we use our EDW, the health record platform. It was over nine applications. You can see all these numbers. These were, I was quickly trying to pull this together up here so I had the numbers. So it's not really formatted that well but that's everything that we cover in a week. We actually built this in SharePoint with lists and stitched together the different inventories to emulate a catalog functionality to illustrate that for some of our management leadership. So two metrics and that was everything under the iceberg that was going on that most people that aren't involved in this had no idea of it. And then of course mid-week it changed. So that was always fun. Okay, that brings us to the end. So four areas define what their role is. Give them a sense of purpose. Bring them together and help grow and retain them and then celebrate, celebrate, celebrate. You want these people to be championed across your organization. If people go to them instead of that other phone a friend, invisible phone a friend and know a guy networks, you're gonna have a lot better outcomes. And so with that we'll open it up to questions if anybody has any. Any questions? Yes sir. Do we, are we just doing a mic or anything? Go ahead. So when you talk about the data stewardship and where those stewards come from, you talk a little bit more about the analytics side. People who do analytics reporting, they're probably your best best. They understand the data and so on. What if the analytics area sits outside of the business area? What then do you do with stewardship? Yeah, that's a good question. So you're getting into more of like a bit of a hybrid model, right? Where if you have multiple teams across the organization. So a couple strategies. Number one, every analytics team has to have at least one steward. They all have to be tied to your program. I'm a fan of like primary, secondary, so you have a backup in case that the first one's unavailable. So designate two, have them be your connection to the DG office, train them up and hold them accountable for training their peers. And the DG office being the central function is still gonna be the one establishing all the standards and processes, but you're gonna leverage these two stewards per team to help train up their people and hold them accountable, their peers on the team to help them follow all those standards and processes. So you can take that approach. So would you say they need the business area themselves? They can. Oftentimes you will see an owner with stewards in that same line of business, but they may not be the only ones consuming that data. They may not be the only ones in that chain of processing, right? So ideal state would be, you can always pull in stewards from across the organization into a domain. It just depends on from point of collection to point of purging. Who all is editing or changing that data? Who's collecting it and what are they doing with it? If they're modifying it, they should be attached to the DG program somehow. If they're consuming it, it's okay. That's read only. You don't have to worry about them. Does that help? Great. So I can't see if hands are raised in the back because those lights are really bright. Yes, sir. I'm sorry, elaborate on the what? A data analytics steward. Like I would separate that into a data steward and an analytics steward. I wouldn't call anybody a data analytics steward, right? An analytics steward. Okay, yeah. So if I'm an analytics steward, someone comes to me, someone comes to my department submits a request and then suddenly what pops on my lap is we need this report by X time. So my job would then be I'm gonna understand the request. I'm going to work through that, just like that COVID definition, start deconstructing that into what it means and what data sets we need, map that back to the data owners or information owners, whatever you call them, we're gonna go to those people and start working with them. So that's one really important responsibility. Get them to work with the right people. They need to know how to identify that. So train them up on data domains, how to look up the owners, and then they are gonna have to work with other stewards. They're gonna need to work with application stewards. I'm gonna use the terminology that I'm familiar with. They're gonna have to find the right application stewards for the source systems in case we have to dig into that business logic. They're gonna work with the data stewards in the business that are collecting and processing that data. Ideally, they're gonna speak on behalf of the data owners when the data owner is not around if they're in that same line of business. And they're the ones that are gonna, you're gonna crowd all of them to make all these decisions. Triage that report, make sure the data's all right, make sure that the people consuming that data are the right ones to have access to it. It gets more complicated with dashboards and reports that pull data from multiple data sets. If it's a couple of data sets, it's a lot easier, but it's the larger ones, the really complicated, everything's on one page kind of visualizations. That's a lot more work. Your people are doing it today. They kind of know the people to go to, but you haven't really formalized that and published that as a directory. So your stewards is your official directory of everybody to go to, whether they're data stewards, analytics stewards, application stewards, whatever you call them, you make that directory transparent to everyone. Does that help? Thank you. And they're following all those certification guidelines too. Make sure everything's up to snuff, whether you're putting a symbol on it or not. Make sure everything is good before you deploy it. And then document catalog like crazy. That's a good question. So if we have a visualization team and a different data science team, we'll get the data science team on board eventually. I would not designate them as stewards per se. I'd see them more as just like super duper power users, but they're gonna have to have a lot of the same base knowledge. So I would give them a lot of DG training. You probably would benefit from having at least one or two people on that team more attached. You could call them a data science steward or an analytics steward, give them a title and bring them in as your choice. The visualizations are definitely an analytics team that need to be involved. Data science depends on your setup. If they're dealing with a bunch of de-identified data and don't have any of the sensitive data sets, they're consumers. They're gonna build their own models and whatever. It depends on if they're gonna push data out for consumption, then we worry about that. Yeah. Yeah. And if they're deriving data from all that, they're actually creating their own data. They definitely need to be stewards of some sort. Yeah. So I look at the people that collect or edit data. If you think in terms of crud rights, if you have create, update, or delete, you gotta be a steward of some sort because you're doing something to the data. If you're read only, that's fine. You don't have to be a steward. That might, that rubric might help you a little bit more. Good questions. Any others? I'm gonna walk over here so I can see past the lights. Yeah, I will coordinate with Tony and Kat, make sure that we get the right slide deck out there. Absolutely. Yep. If this, it'll probably won't have the results of COVID, but it'll have all of the branded slides on it. Yep, thank you for asking that. Sorry about that snafu. I don't think, and I think if you look at, I think if I was looking, if I remember correctly, I was looking earlier at my session, I don't think they linked the file. So something's up. So we'll get that rectified. Any other questions? Okay, how many people have named stewards and are publishing that as a directory across your organization, making that visible to everyone? Okay, good. So these are the experts, all the rest of you, get some tips and tricks from them. Yeah, that's what this conference is about, learning from other people. How many of you are really struggling with it and you haven't named stewards yet? Yeah, yeah, team of one. Oh, I feel your pain. Yeah, yeah, that's difficult. It's, there's a lot more effort when you're beginning data governance than you're a team of one. Yeah, good signs. Okay, I think we're good. Thank you, everybody.