Designing Data Governance | Lauren Maffeo | 518

New ideas and frameworks take time to gain momentum. Just because you shout eureka doesn't mean that everyone in your field adopts the idea overnight. Today I want to talk about the process of building momentum around an idea, and I've invited Lauren Maffeo to join me in the conversation. Lauren is the author of Designing Data Governance: That's a term you're going to hear a lot about in this podcast. And Lauren is also an adjunct lecturer in interaction design at George Washington University. In today's episode, we'll talk about building a movement, the challenge of when an idea is someone else's problem, or worse yet, nobody's problem. And we'll talk about what it takes for an idea to gain traction. I'm Bill Sherman, and you're listening to Leveraging Thought Leadership. Ready? Let's begin. Welcome to the show, Lauren.

Thanks so much for having me. I'm excited to be here.

So you've been doing some work in what I would describe as an emerging area of thought leadership, which is one where people may or may not have heard of themselves, even if they're in your field. So data governance, what is it? Give us the 101 quickly.

That's a great question to ask because in tech, we often throw around terms with the assumption that or presumption that everyone should know what they are and that we're all speaking about the same thing. I see this most prominently with AI. I see people talking about it and throwing the term around constantly without any awareness of what they're actually discussing and what AI truly is. And I see that with data governance as well, even amongst data practitioners. We are often not talking about the same thing, but when I talk about data governance, I'm talking about your strategy to manage the people, processes, and tools that help you govern big data at scale. So if you are a senior leader in an organization and you are the chief data officer, you are the VP of data and analytics. Something to that effect. Your job is to come up with a strategy for how your organization is going to manage its data at a high level. Everything from the mechanisms by which they, uh, your products ingest data, the data that you collect about consumers, your data destruction policies, all of that falls under data governance. And I would make the case that organizations already do data governance. They just don't know that they do it and/or they are a bit averse to the title while actually practicing it, just not in a more cohesive way that would be more effective.

Well, and it sounds like it is drawing a circle around a number of activities, some which are already being done by organizations, some which are not, and saying, let's cluster these together as a group and applying a label. Is that a fair way?

I think that's a fair way to describe this. There's certainly a case to be made that organizations do aspects of data governance, even if they don't do every aspect of it that arguably they should. And because the reality is, is that you, you do need mechanisms to manage the data that your organization produces and collects. You need data quality standards. You need a things like a data dictionary, which is a, a way to define different— what different pieces of data mean. Now, those latter two points are where I see most organizations falling down today, and that's where I think we have this general problem in businesses with data writ large, because the amount of data produced has increased exponentially and is not going anywhere due to how many internet connected devices we have. But the quality of that data is something that we should all be suspicious of, and that is something that leaves organizations at risk. So that, I think, is a huge opportunity for today's data leaders. It's also a challenge, admittedly, because there is so much data that establishing and then applying these quality standards is certainly not easy work. I think the biggest challenge to doing data governance well is establishing a thought leadership strategy around it to get other colleagues on board with it, because the case I make in my book is that there is too much data produced today for one team or one leader to own all of it. You really need to make it a collective effort across technical and non-technical roles, and that is possible if you give the right thought leadership, which is going to show the benefits of each person participating.

So there's several things there that I want to come back to in turn. And what I love for this is you're asking the question, how do I bring people inside the organization aboard to share a common way of thinking about data, right? And a common way of handling it because this problem is too big for us to handle individually. And so when I think about this, any idea, any thought leadership that's worth solving a problem, right? And organizations very much at their heart solve problems for clients, customers, and then they create problems of their own, such as what do we do with all this data that then they have to figure out, right? And so this process of solving problems through ideas. Okay. Data was okay when we were just, you know, had little bits of it and we were putting it on notepads or in a filing cabinet, right? It's gone to such a large scale that it's become unusable. And so what I want to ask first off is that process of bringing people aboard. Okay, how do you make this idea accessible and exciting and something they want to do?

This is the hardest part of data governance, even amongst data practitioners. Many of them do not want to talk about data governance or hear about it, let alone to do it, because many practitioners see it as a hindrance to their work. There's a real tinkering culture in tech with code, and I— that extends to data as well. And because we have a lack of industry standards that are universal that everyone can refer to, that kind of gives people carte blanche to do whatever they want with data. And when you think about making it real and tangible and exciting, that is the challenge of the day. In terms of showing what you can do with governance and what, what it can do for you and how it can help you do your job more effectively. I think the governance conversation is still too high level and too opaque for most people to buy into it. You really have to make it very tangible in terms of the benefits for your organization as well as your data stewards. So your data stewards in an organization are the people who are the subject matter experts about your key areas of data that you produce and/or ingest. So for instance, your VP of Sales could be the data steward for your sales data. Your director of marketing could be the steward for your marketing data. The director of customer success could be the steward for your customer data. And then you have subdomains underneath those three domains, which break out the data into more detail, categorize it, give it more structure, hopefully. And then what happens in an ideal world is that those three stewards create the standards for data in their domains, which are then automated in production environments by your data architects and data scientists, engineers, and so on. And so in terms of getting those three stewards on board, you as the data leader really need to make the benefits tangible for them. You have to understand that you not only have a baseline understanding of their day-to-day, but that you also explain how data governance and their participation will help them do their jobs more effectively. And that doesn't have to be as hard as you think because all of those roles I mentioned, sales, marketing, customer success, you cannot succeed in those roles without data. Data plays a huge factor in a leader's success, especially in those functions. They need to know the latest data on, on everything from sales to ad campaigns to customer signups, reducing churn. And so making the data aspect of governance more tangible to their specific jobs is a way to get them on board. Likewise, I think you need to start off by having all of these data stewards work on a project that, you know, the business has prioritized. You need to integrate your data governance work into this initiative. That the CEO is on board with, because then you automatically get that top-down support. That's also crucial.

So I'm hearing a couple different things in here, and I love the richness because here, if I'm thinking about a head of sales, for example, if you go to the head of sales, and I know this is true in terms of, yeah, we want you to be the champion for thought leadership in the sales channel because it'll help you sell more effectively. We can show how that leads to shorter sales cycles, greater upsell and client retention. They're still focused on this month's target or the quarter's target, right? And so I think in the same way, getting the idea of data governance and saying, congratulations, you're the data steward for sales. It's like, wait a minute, I didn't sign up for this when I took this role, right? Where do I find time and what do I let go of to make this happen?

That's exactly right. And I do feel that's a strong reason why data governance has to be a top-down effort. If you are the chief data officer and your CEO does not see the value of investing in data governance, you're going to have limited success inherently because it— because that's otherwise, that's exactly it. People are going to say, that's not my job. You talked about making data governance exciting and something that people want to join. That's the hardest part. The next hardest part really is getting the buy-in to do it and to make it real for people. And so that is something that is a huge issue and an ownership of data. Is also a huge issue. People without understanding the benefits for them or that it's something the company prioritizes, people are just going to put their hands up and say, "That's not my job." And so in order to avoid that, you really need the buy-in of leadership to, and their understanding of how this is going to drive the business forward. That means, like I mentioned, that you really need your data governance strategy and your first project to be very tightly connected. To the business and the business goals in short and long terms. Without that, you again are going to continue to have limited success. And I— and that's a big risk as well. I see data governance often happening in a corner separate from the engineering team, separate from the business plan. And anytime that happens, you're going to fail because if your governance is not integrated into your technical practices, if it is not integrated into the business strategy, it's not going to be effective. It's going to, it's going to be—

You're playing house in some ways.

Yeah, it's going to be digital documentation that lives on SharePoint or Google Drive realistically that nobody follows.

So we've talked about the question of data ownership and you mentioned something I want to circle back to, which is the data dictionary. And you and I probably are like some of the listeners in this group as well, who are excited about having clear, crisp definitions about what we're talking about. It's the much more scientific approach because there's a difference between an idea that you wave your hands and go, yeah, we're talking about this, versus this is how we define it, this is how we measure it. So from your perspective, Talk to me a little bit about a data dictionary, how you create one, what makes one effective, because I think it's a tangible tool that can also be exported to thought leadership more broadly.

Yeah, data dictionaries do play a big part in any data governance/enabling efforts. They are the centralized space in your technical environment where you host the definitions for individual pieces of data at the domain and subdomain level. And that's really important because the same word does not mean the same thing depending on context. That's another thing that data dictionaries do well is they provide crucial context about data, which helps leaders and data stewards make decisions based on the data. And so for the example I always use is the example of a date. The word date can mean off the bat two different things. It can mean, you know, two people who are in a romantic relationship going out for an evening. It can also mean a date on a calendar. And so—

or a piece of fruit or—

right. And right. And so it can mean three very different things. And if you— and so I think what we often see, as with data governance, as with AI, People assume that these terms are implicit, that we will know automatically what they are. Now, of course, depending on the format of the data, that gives you a big clue as to what the definition is. But at the end of the day, you really shouldn't be assuming, especially when you are managing data at scale. So it's really important any technical environment that you have for a data dictionary to be part of it. Many data governance software systems like Calibra and Informatica have data dictionaries built into them. So I, it's always a good idea to, right before you buy a new tool, to look at what you already have. It's possible that you are using a data governance tool that already has a data dictionary and you just haven't been utilizing it yet. So that is an option. If you need a stopgap while you search for something else and get budget for something else, you can use tools like Confluence, uh, which is a wiki that hooks up to Jira, which is task management software for project teams. So there are opportunities to create data dictionaries even if you don't have data governance software in your organization yet. And if you do have that software, there's very likely space for a data dictionary in there, which you absolutely should utilize. It's going to be essential as a space for all colleagues to go and get the information about data that they need.

If you're enjoying this episode of Leveraging Thought Leadership, please make sure to subscribe. If you'd like to help spread the word about our podcast, please leave a 5-star review at ratethispodcast.com/LTL and share it with your friends. We're available on Apple Podcasts and on all major listening apps, as well as thoughtleadershipleverage.com/podcast. So let's shift into book project, and I want to tee this up with something that you said to me. You mentioned that a number of your colleagues, when even some of the younger folks, they said, hey, when I went to school, this wasn't covered.

Yeah.

Yeah. So how did that lead to you saying, I'll write a book?

Yeah. So that was a path of about 5 years total. I'd started when I was a research analyst at Gartner. And I was covering different business intelligence software tools and techniques that business leaders in small and mid-sized businesses could use to grow their organizations. And so that involved researching different AI techniques. That's where I started learning about data as the backbone of AI. And that's very important to emphasize because the mainstream press likes to talk about AI as this monolithic sentient being that could possibly overtake us when the reality is that AI is data.. And so that's important to know first and foremost. But then what made me interested in exploring this concept was that Gartner kept putting out research paper after paper, which showed that the number of data-driven organizations was still low despite the consistent growth of data in volume. And that continued over time. It, that was a constant challenge that, that organizations of all sizes would have very low data maturity as a assessed by Gartner. Then I left the research analysis side of it and joined technical teams where I was working as a service designer alongside data architects and engineers and scientists to design and build various technical systems for our clients. And I saw firsthand the— just how low on the maturity scale many organizations are when it comes to data. I'm talking no automation, manual processes that take days to complete when they could be done in hours. I'm talking about no— nobody even knew in many cases where which datasets lived where. So they would tell my team, for instance, to do certain things with particular datasets. And my colleagues would say, great, where is it? And they would say, I don't know. And so then we would have to look for it. And very often it was an Excel file on someone's local laptop. I mean, and so that I saw firsthand what the lack of governance does. I also saw how many of the same clients who had these practices would make comments like, we'll do data governance later, or we'll do data governance once we reach production. And that mismatch is really what drove me to pitch the idea for this book, was seeing firsthand that the volume of data is increasing while the number of data mature organizations is actually dwindling. That's an enormous mismatch, that's an enormous risk. And I'm more convinced than ever that this is really not a technical problem. It's a cultural change that you have to embed within your organizations. And that reframe is very important because if we don't understand fundamentally what the problem is, I don't think we can begin to fix it.

So let me ask you this question. Less data, better governed, is better than more data in the Wild West?

I would say so. I would say that it is better to start with a small subset of data that is of critical importance and work on governance for that than it is to throw your hands up and say the problem is too big. And I do understand the temptation to do that because I've done that on projects myself. I've, I've worked on for instance, website migrations with, with an astronomical amount of content on this PHP site that I had to help migrate over into Drupal, which is a content management system. And the volume— it's not that the problem itself is hard, it's that the volume of content that you're working with is so enormous that it feels overwhelming. And I do think we're in a position like that with data where there— it's not just this question of setting up data governance from scratch, I don't even think that's really the problem. The bigger problem is leaders not only designing this data governance plan, but then thinking, I have to now retroactively apply this to all of the data that my company owns. And that is incredibly—

Cleaning out the Augean stables. It's a Herculean task.

Yeah, and it's way too much, not just for one person and one team. I would say— depending on the size of your organization, that's too much. Even if you do have a full data stewardship team that meets regularly on a council, it's, it's still very overwhelming. And so I do think that if you're in that bind and you're trying to figure out what to start with, asking your executive sponsor which data sets, which data is the most important, is the way to go, because then you can apply those data governance standards to that particular project, which is contained. It's of high value to the business, which means you'll get support for it. And then you can continue to scale out from there.

So you also mentioned something when we were talking earlier about data governance, even within an organization, being a smaller group. And you said one of the reasons you wrote this book was to sort of reach that audience and say, hey, this is the book I wish I had, and you're not alone. That resonates a lot with the world of thought leadership. So what is it like now in the world of data governance for the people who are enthusiastic about it? And how are you creating sort of connection?

I think that doing data governance today is still an isolating experience because you are very often an army of one. Inside your organization who has to constantly be justifying the value that it brings and why it matters. And you might be falling on deaf ears depending on who you're speaking to. I was speaking to a group at an event called Data Architecture Online earlier this summer, and the moderator for the session I was part of said that she actually sees a lot of enthusiasm about data governance on the business side, less so on the technical side. And I would agree with that from my own experience. I think that I just saw a LinkedIn post earlier this week about different data roles and the, the common experience of people in these roles based on how they're perceived in the organization. And everybody wants data scientists, everybody wants data analytics. I hesitate to say nobody wants data governance, but that person has a much higher hill to climb. And that— and so I think it's— it can be an inherently lonely experience. You can— it really does take somebody who has strong relationships across the business and is willing to build them by understanding, by building coalitions. And not everybody wants to do that. Not every data leader wants to do that, which is again why I think data governance is inherently a business role more than a technical role. And again, I do— what makes me happiest is when readers of the book tell me that it really resonated with them and gave them a roadmap to do their work more effectively and make progress because, as mentioned, it can be a really lonely task. I do think in 5 years, and that will be different if we talk again in 5 years, I think we'll have a different conversation. But for now, we are in the earliest stages of making this mainstream. The people doing it do not have as many resources, or if they do, they're piecemeal. And so anything I can do to even begin building a community of practice around this, I think is really rewarding, and I am excited to see where it goes. I do hope it's a book that will be evergreen as opposed to a flash in the pan because it discussed something trendy. I think one of the benefits of data governance not being super trendy right now is that it, its value will grow over time. And so I'm excited to see what that looks like.

So as we begin to wrap up, I want to ask you two questions because you have taken a journey into thought leadership as part of your career, the writing the book, being the advocate for the community of practice for data governance. And I can hear it in your— the excitement in your voice, right? It's a topic you love. What is one thing that early in your career prepared you for this? And then what is one thing you wish you had done differently to prepare?

I do feel that my background as a journalist prepared me really well for this work, both writing the book, then speaking about it. I started my career doing consulting for small businesses based in London that were in the tech and digital space. I also worked as a freelance reporter covering the European tech sector from London. And because I was freelance, I had to pitch article ideas to editors. I had to learn how to sell my ideas. This was not a case of me being an in-house reporter and getting assignments and then saying, go off into the fields. That's more common in the news space. But because I was free, I had to pitch myself. That did prepare me very well for this because when you are promoting your own book, you have to be your own best advocate because if you are not excited about what you're discussing, nobody's going to be excited, especially when it comes to a topic like this, which I'm well aware can seem very dry. And so if I don't do a good job of making it interesting and relevant for people, there's no hope of me selling the book and getting it into the right hands. In terms of what would have helped, I was very liberal arts oriented in, in college, in graduate school, and I do in hindsight wish I had taken more economics courses and a few more statistics courses. I did take statistics up through grad school, but I strayed away from those subjects thinking that it wasn't relevant to me, that I wouldn't really use it, that I wasn't interested in it. And I think that was a mistake. If I could go back, I would have invested more in those courses and making them applied and applicable to my work as opposed to thinking of them as fully separate endeavors.

So thinking back as a fellow liberal arts student, both in undergrad and grad, English and drama, I wound up having to go back and pick up statistics in my late 30s and realized it was like, yeah, this is like learning a foreign language in many ways. Yeah. But it was absolutely essential.

It is. And you think you won't use it. But that's actually what I'm talking about is I thought, given my area of study, given the career that I thought I was pursuing, I did not think it was going to be essential, and that was wrong. And, and that kind of goes back to my point about how data is not one person's job anymore. We all have jobs that are going to be affected by data. We are all going to have data in our purviews that are— that become our responsibility. This is no longer something that we can— we can not also no longer say, that's not my job. And so, because it is rapidly becoming everyone's job. And so that, that kind of goes to show that even if something does not seem super relevant in the moment to you, that does not mean that it won't be valuable later on.

I think that's a great piece of advice. Before we wrap up, Lauren, I want to ask you, if someone's listening to this conversation and is one of those people that wants to tune in on more data governance or they want to connect with you in general, How do they find you?

I would love for folks to connect with me on LinkedIn. I'm on there under my full name, which is Lauren Maffeo. I'd also love for possible readers of this book to, to give it a read and then write a review of it on a site like Goodreads or Amazon. I'm learning that those reviews really help new authors have their books discovered. And so I get shy about asking people to give reviews, but if folks would be willing to do that, that would be awesome. The book is available from Target, Barnes Noble, Amazon, local bookstores. You can also go to pragprog.com, that's P-R-A-G-P-R-O-G.com, and find the book there. It's called Designing Data Governance from the Ground Up. And if folks want e-copies from pragprog.com, they can get them for 35% off through September with the code DATAGOV23, all caps. So that's D-A-T-A-G-O-V-2-3, all caps.

Fantastic. Thank you very much for joining us today, Lauren. This has been great.

Thank you so much for having me.

If you're interested in organizational thought leadership, then I invite you to subscribe to the OrgTL newsletter. Each month, we talk about the people who create, curate, and deploy thought leadership on behalf of their organizations. Go to the website orgtl.com and choose join our newsletter. I'll leave a link to the website as well as my LinkedIn profile in the show notes. Thanks for listening, and I look forward to hearing what you thought of the show.