Brittany Danishevsky: Hey everyone and welcome to our State of data Enablement Roundtable. My name is Brittany, the solutions engineer here at Secoda and today, I'm joined by three wonderful humans who are going to speak to us about data enablement. 

Before I introduce them, I wanted to speak quickly on this topic. We are here to discuss what happens when you have the data but you don't use it and how to make sure that your teams can use it effectively. The data world loves to learn from each other and I think that is an awesome, awesome thing. Your community or the community that I'm now part of is really supportive and really big on knowledge transfer and that's what we're going to do today.

So without further ado, I'd love to introduce my panelists, my Roundtable participants today. I'll throw it over first and foremost to my own colleague, Lindsay. I'll let you do a quick intro and then Kelly and Leah will introduce themselves as well. So Lindsay, kick us off. 

‍

‍

Lindsay Murphy: Awesome. Thanks, Britt. So my name is Lindsay Murphy. I'm the head of data at Secoda and I'm also an instructor with CoRise. I've been working in data for about 11 years and previously, led some data teams and worked on the problem of data enablement and the challenges that come with it. So super excited to talk about this topic today. I think it's really important in how data teams drive value so, yeah. Super excited to get into it. I'll throw it over to you, Kelly.

Kelly Burdine: Awesome. Thanks. I'm Kelly Burdine. I'm the director of analytics at Wellthy, a tech enabled care concierge service. I've been here for about 18 months but I've been working in data for a little over a decade and have led data teams at three different companies now. And so I've encountered this problem everywhere I've been and it's definitely near and dear to my heart so thanks for having me.

Brittany Danishevsky: And Leah, if you wouldn't mind introducing yourself as well. 

Leah Weiss: Yes. Similarly, I think I've been working on this problem specifically for my whole career in data. First I built out the data team and data infrastructure at WeWork then I built a consultancy for a couple years doing sort of enablement and building data capabilities. Now, working on this problem from the product perspective at Preql where I am CEO and co-founder. 

Brittany Danishevsky: Amazing. Yeah, I'm really, really excited to hear from you all. For those that are unfamiliar, the topic of this Roundtable, the reason why we wanted to bring it to fruition is because we just put out a white paper. I believe it'll be linked in the comments. And so I encourage everyone to read this white paper and get familiar with the results. We won't so much be discussing the exact results of the paper but more discussing our own experiences. We have three incredible leaders here who will talk to the things that they've done to improve data enablement and to really get their teams using the data available to them.

‍

‍

The other thing to note just as an aside is that this panel unfortunately looks different from other panels. It shouldn't but it does and I'm sure everyone's noticed that all of our panelists identify as women and we don't see that very often unfortunately where the topic has nothing to do with being a woman and the panelists are all women identifying. So I think at the end, it's a topic that's near and dear to my heart and to the folks at Secoda of speaking about being a woman in tech and especially in increasing the amount of women in data as well. So if we do have some time at the end, if folks have any questions for our incredible leaders and if our leaders would be open to answering them, we'll talk to that but in the meantime, you just got to plug that in, right? So if there's anyone watching out there that is thinking about coming into data and doesn't see themselves represented, I hope these folks show you that there's a place here for you as well. 

So before we can dive into how to improve and what the challenges are and all that fun stuff, we have to start with defining the problem. So I'm curious how everyone here would define data enablement. Maybe Kelly, I'll kick it off to you if you don't mind to start us off and let us know, how do you define data enablement? 

Kelly Burdine: There's so many things, so many parts of data that people are always working on. You hear analytics engineering, data engineering, reporting, all this stuff, right? But ultimately, to me, our business users have to leverage the data to make decisions, to take action and enable them to take those actions. That's where the ROI is, right? Like, you can do all this work ahead of time but it's that last mile where you really enable it and unlock the value of data. So that's how I would define it. 

Brittany Danishevsky:I'm curious. Leah or Lindsay, do you have anything to add there to support that answer? Maybe Leah, if you have anything to add of your own personal understanding of data enablement or how you would define it? 

Leah Weiss: I agree. As data people, we’re really good at building things and we're really good at moving data around. We're really good at storing it. We're really good at making it perform. But at the end of the day, if that's not connected to people who are leveraging that data to make decisions or at least informing their decision making with information, I think it's going to be hard to continue to get the kind of support that you need to build out data capabilities. 

So I think the question that I always return to when I'm working with folks who are building their data capabilities or when I've built state of training programs, things like that, it's what would you do differently if you had access to this data? How would this change your decision-making process? What are you doing at the moment where you're making this decision and how can we sort of surface information at a time when it can be relevant and in context for you? Data people are really good at infrastructure. They're really good at some of these technical challenges but what's really hard about data from my experience is sort of bridging the business world with the data world, making sure that we're speaking the same language, making sure the logic that we've encoded in the data that we're providing makes sense to the decision maker.

Brittany Danishevsky: I really love that. I think it makes sense. You want everyone to be speaking the same language. My background is in engineering and you could code things until the end of time and you can make it so beautiful and so this but if your end user doesn't know how to use it or it doesn't bring value to them, it only goes so far. 

Lindsay Murphy: I think it kind of goes back to this topic of data democratization, too, which maybe is like something that we talked about like a little that that term seems to be going a little bit about the door. But it's really how do you increase the impact of the data team. So if you have a really small data team with a really big organization, you have to be able to give data and decision making power to the people who are actually doing the jobs themselves. So yeah, I think it comes with ensuring that as Kelly and Leah already said that the people in those roles of decision making are trained on how to use the tools that are created for them from data assets. They understand the data models that exist and the data models are created in a way that the data team understands the business and it's actually well aligned which I think is a big one. 

And then the last piece I think too is even ensuring that the people who are, you know, if you're asking them to do analysis versus just look at a dashboard and kind of infer insights from it that those folks know how to understand the data set and kind of make a good decision about it. So it's like if you have a really small sample size, that goes into the factor of your decision making and you're not just kind of making a huge decision based on a sample size of like a few. So yeah, I think it kind of goes into that area of how do you help people who are not the data team to get more access and make the right decisions. 

Brittany Danishevsky: Yeah, amazing, and that actually flows so well into what I wanted to talk about next which is the challenges and barriers. Through our white paper and just general discussions, I think one theme that comes up a lot and it just came up in our discussion so far is data literacy, especially the literacy of your stakeholders. You can have this great grand old data team and everyone internally can feel so good about what you're putting out there but if, like Leah said, if your stakeholders aren't speaking the same language, it's only going to go so far. So I was wondering. Maybe Leah, you can kick us off of maybe stories or examples of times that you've found data literacy between your stakeholders and between your data team to be not exactly at par not where you want it to be and how that's created challenges in data enablement.

Leah Weiss: Yeah, I can sort of speak to my background here. So I was sort of that lonely data person. I'm sure people can relate where you have all of this institutional knowledge, how all the models are built, how all the metrics are defined but sort of communicating that, socializing that, getting people to use it becomes a challenge and then sort of also maintaining all of that stuff. And it creates tension which I think sometimes, data people don't own up to that there's often sort of tension between the business consumers of data and data people who are working really hard and often overburdened with requests and all of that. 

So to address this, this was totally grassroots effort that Gabi, my co-founder and I actually

worked on back in our WeWork days but what we did, instead of sort of having this process of sort of like gatekeeping where you're like, these are the definitions, these are the models, you must speak to a data person before you do anything, we decided to go on a bit of a goodwill tour. That was sort of about education but also kind of just building bridges and helping improve the communication between data folks and business consumers of data. And a big part of that puzzle was not just teaching technical skills. It's great if everyone knows SQL and everyone can speak the same language but it may or may not be realistic. 

I think that the biggest thing is actually teaching the business how to frame questions that data can help answer and how to sort of define problems that data can solve. So what we did is we went from department, sort of trained them in this problem statement methodology to get them to like really isolate the areas of the business where data could help and then we could prototype solutions really quickly and it improved the conversation a lot where it wasn't just like, send me the CSV or I need this dashboard by tomorrow. It was, I see an opportunity to reduce costs, how can I collaborate with the data person to improve that. So that was sort of our approach to data literacy where it was actually more about sort of the work of defining problems and framing questions.

Brittany Danishevsky: Yeah, I really love that. I think one thing that can happen in any organization is we become siloed and we're so ingrained in what we're doing every day that we forget that there's consumers of what we're doing whether it be customers or other stakeholders within the company. And sometimes you can get a bit stubborn. You want to believe, well, I'm doing my best work and just because someone may not understand it doesn't mean it's not good work. It's just something that needs to be adjusted for the purpose. And so I really love that we're talking to that and I think it flows nicely into the next kind of topic around challenges which is low adoption of these self-serve tools and how we can, you know, we're not fully in the solutions part of our discussion yet but I'm sure this is a topic or a situation that many of us have encountered. You create these tools for your business users and no one opens it, right? No one even touches it. You're like, oh, but you're still bothering me so much. Why is this happening? 

I'm wondering, Kelly, if you have any thoughts about self-serve tools and any stories or

personal experiences about having really low adoption and being a little surprised at that perhaps.

Kelly Burdine: I think like many of us in data, we've probably learned this the hard way. Many, many years ago, likely when I was kind of the lone wolf data person, I honestly thought the answer was just kind of a self-serve tool, open up access to data, problem solved, like, all the value. And so I actually got on an all-hands meeting at my company and said, all right, everyone has access to this data now, go to this tool, it's fantastic, let me know if you have any questions. I got lucky with a few people that were pretty data savvy already and got in there but had tons of questions and then crickets everywhere else. And I hear that a lot from folks and so I have learned that that's really not the best approach and so similar to how Leah went about, I've learned you really have to kind of teach your business users how to use the data and work with them very closely on, like you said, defining the problem and they need to understand what the data means, how to use it, how to ask questions. 

And it's a progression because if you think about like anything you've learned in life whether it's a sport or math or anything, you don't just start at the end, the hardest problem and someone puts it on the, the teacher doesn't just throw a math problem on the board, be like, all right, there you go, you got it, here's the book. That's not how it works. You start off with your basic math and you work up and you make sure to check along the way, check literacy, check understanding. And it's the same way with data. It's really no different. It's just like learning another skill. 

And so with Wellthy, we took that kind of learning and progression approach as we rolled out our bi tool and worked with our stakeholders. We kind of went team by team and said, all right, let's start off with this, okay? We'll kind of teach you how to do it. We did some training, documentation and then once they got comfortable, we added more and we kept going and then we're like, all right, this model seemed to work. Let's go do it with another team and we kind of progress through the organization like that. And I think that's really important to get adoption of those self-serve tools because it doesn't mean that it's there's not some, there's still a bar. There's still a bar that you have to be able to understand and use it. And so I think that's really important to understand. 

Brittany Danishevsky: Yeah, I love that it's like a walk don't run and understand that the folks that you're talking to also need to walk and not run and all three of you have been in this industry for so long and sometimes, just in general, folks forget what it's like to be brand new to something and hear SQL and go, what?! And the funny thing is I'm sure a lot of folks know this is that when it was first invented, it was meant to be like the people's language, it was supposed to be accessible to everyone that anyone from any admin person, anyone who needs to touch the data could use it and from any of us who use SQL, we know that that's just not quite the case. So the understanding that we need to meet people where they are is really, really an important message.

On another front when it comes to challenges to data enablement moving away from adoption and your business users, we've heard that common issues are also found in data quality and data sprawl. And I'm wondering if you have any, I'll start with you, Lindsay, if you have any stories or thoughts about how data sprawl in particular or poor data quality has really made it difficult to enable data discovery within your teams. 

Lindsay Murphy: I've definitely experienced this firsthand and I think this kind of goes a bit opposite of the last challenge that we talked about which was like a lack of adoption. I think on the other hand, when you do self-service, you actually can get pretty good adoption and so I've been in a situation where a lot of people in the company were using a tool like we had built Looker and they wanted to use it and then it was a new feature request every week. It was like, okay, well now, we have this data. Can you please add this? Can you please add this? 

And I think what quickly started to kind of it became a bit of a runaway problem for us was like we hadn't really spoken to the business leaders about how does the company want to use data. Like, what are the problems that we're going to try to solve with data and if we have limited resources in a data team, what do we want to invest in and what is going to be the most return for the company. And so I think we kind of just opened up this world of like self-serve analytics, we'll answer any feature requests that gets submitted. And we quickly were finding like, we're adding features in the minutia of our product that when you really go back to the drawing board, it's like, how important is it for the team to know this and like what decisions are they going to be able to make that actually impact the business? 

And so we kind of had to take a step back and say, is this valuable for us to be doing all of this or should we be saying no to more things? And I think with the changes in the economy and things that like data teams are getting more pushed to have, what's the ROI of your effort, hopefully, we're seeing a bit more of that but I think there was a period at least in my management of a team where we were kind of, I don't think we were being very good about, are we putting our all of our eggs in the right basket in terms of our investment? 

Another thing that I was kind of thinking of when we were on the last topic was, I think when you talk about getting buy-in with certain people in the company, it depends on the stakeholder that you're talking to and I've had someone say this to me in the past was that analytics can be the fire that feeds someone as a team. Like, it can be something that they really enjoy and they take away and they see the value in or it can be the fire that burns them. So something that you have a decision maker that's really high up in the company and you know they wanted to make decisions based on their gut or on their Instinct. They may not actually want your data to be involved in that decision-making process and so I think there's an aspect of that as well in terms of data enablement. It's like you sort of have to figure out, how is the business going to use data? What are the ways that we are going to focus on? Like, who are our friendlies in the company versus the people who maybe don't want the data involved? And that's fine for the time being.

Brittany Danishevsky: That makes me think of one follow-up question, too is, as someone on the data team, you get this adoption, people are asking you for more and more. There's a lot of requests. How difficult is it to say no sometimes and what kind of thought process goes into saying “no” in order to, like you said, Lindsay, maximize ROI? I'll throw that back to you, Lindsay and then if anyone else has any comments, I'd love to hear. 

‍Lindsay Murphy: I think what it came down to us is just again, like, we had to sort of take a step back and say like, we kind of went really heavy in self-serve analytics and that, it opened up a lot of areas for people to use data but it really didn't give us a lot of prioritization. So we weren't really thinking about,  “what are the biggest problems that the company has?” How can we strategically use data to help solve those problems and then focusing on, okay, marketing is one of our biggest challenges right now so we're going to focus on the marketing strategy and supporting them versus product versus another internal operational function? 

So I think for us, we had to really partner with the leadership team and go back and say like, what is data at our company and how are we going to focus on driving the most impact for the business? And then it became a lot easier to say “no” to people because you actually had the support of the company and then people could go back and say, okay, this relates to this OKR, this broader objective from a company perspective. I think until we did that exercise, it was hard to push back because everybody could just kind of say, okay, we need this for this reason and we wouldn't really be able to say, well, that's not important compared to all these other things that we could be doing.

Brittany Danishevsky: I see a lot of nodding heads, too, so it seems like it's something that's definitely relatable. And I think it really comes down to, like you said, Lindsay, the ROI, we have these data teams and we've seen a big investment in data stacks and improving your data stack in in getting more and more modern tools to use but that doesn't mean that it's just a free-for-all. Every decision needs to be made with a lot of care and ultimately, it needs to help the quality of the tool and also the ability for your team members, for your stakeholders to really use it effectively to make good decisions for the business, which I really love. 

So as we move on in our conversation, we've kind of touched on this already. Some best practices for overcoming these challenges. And we've talked about really collaborating with our stakeholders as it pertains to data literacy. I'm wondering, I'll start with you, Kelly, if you have examples of different training that you've done with your teams that you have found to be really effective and tangible. We always love a good tangible example, a good story. So if you have any of those, definitely, I'm sure our audience members will appreciate that. 

Kelly Burdine: Yeah, sure. At Wellthy, we always train any user, especially for anybody who's going to have access to our BI tool, we train every single team. And then we record the training. We post the training along with documentation. We have documentation about things like, what does this metric mean? How should you use this? And I think that that really helps. But something that's much more kind of small scale that I've learned to do that I think helps a lot is recording short, quick videos. 

When someone asks a question like, hey, I'm struggling to do this, or does anybody know how many signups we had with this and these criteria? And so one approach that I've certainly done many times in the past was quickly do it myself and either send over the number or like, maybe send over a link, be like, here it is. But instead, I've kind of stopped doing that and I'll record myself doing it. I'll be like, here, I'm logging into this. I'm using this data set because of XYZ and I'm going to filter down and I just talk about exactly why I'm doing it. It takes me almost no additional time to do this and then I send the recording to that person. So I'm not just giving them the answer but I'm teaching them along the way. I'm trying to help them do this themselves in the future to enable more self-service and I think that's one way that I've found to be very, very valuable and in a very good use of time to just record those and then you can also take the recording link and put them in, you know, if you have like Confluence or Guru or something like that. You can now quickly create a library of how-to videos. You were going to do it already so why not just record yourself doing it, talking through it. I've seen a lot of value out of that. 

Brittany Danishevsky: Amazing. Yeah, I'm curious, Leah, your perspective now having gone from someone leading a data team to now being a consumer of the data. You're in a unique position because your data literacy having led a data team before is probably higher than the average consumer, but what have you found for your teams and for yourself as a data consumer really works in terms of training and finding that matching language with your data team. 

Leah Weiss: Yeah, so one suggestion I have is just sort of a mindset-shift that was really valuable for me. I think when you're leading a data team and you have the most sort of technical knowledge and institutional knowledge, there's some sort of protective instinct that kicks in where you can be a little bit defensive of your work. You want to make sure everyone is using things correctly and generally speaking, there's usually maybe one person per department or a couple people who just flood your inbox or your Slack or ask a lot of questions and they're doing rogue things in spreadsheets and you don't know exactly where the data comes from where they're presenting. 

And I think my initial instinct when working with those folks was to sort of correct them or to corral them in some way and I think one thing that really helped me is to think about those people as your potential advocates. If you can get those people on board with your approach, then they have a lot of influence over their department and can really sort of think about things differently because ultimately, data can make everyone in your organization a lot more effective in their roles and there are some people who are primed for that and ambitious in that way and they know that if they can pull information together then they can work much faster. So I think instead of being overly focused on getting those people to do exactly the right way, just see those people as your potential partners in sort of spreading the data culture that you want. 

And one other quick thing, I think you said you have to really sort of walk before you can run. I think as data people, sometimes, our inclination is to gravitate towards complex analysis and data science work that's why we're all interested in this work. It's really powerful but if you can't get agreement on how you're going to measure things, if you can't build trust in definitions, if you can't make sure that everyone sort of meaning the same thing when they say revenue even though you're in different departments, don't skip that work because it will come back to you every day.

Lindsay Murphy: Yeah, I was thinking there as you were talking, it's kind of like overcoming this us versus them mentality that I think sometimes comes up as a data team. Like, you start to feel you are a centralized resource, you're often under resourced in a lot of cases especially if you started as a data team of one. So I was really resonating with what you were saying. It's almost like I feel like I've almost been the protector of my team and at times of like, don't reach out to these people directly or like requests have to go through a process and I totally agree. 

I think it's a bit of a mindset change where you kind of have to look at it as like these individuals want data. They actually want to do the right thing and be able to make decisions. They just need some guidance on how to do it. So it's less of an us versus them problem and more of like, how do we get them further down the funnel because they're already past the adoption stage which is great. They're engaged. They just need some help in figuring out like, how do we actually get to the next phase of making us better and stronger in our skill sets. 

Brittany Danishevsky: For sure. And ultimately, we're all part of the same company. We're all working towards the same goal and it's so easy to get into those silos like we talked about but remembering that our common goal is to move the needle as a company, as a whole team. I'm curious just, yeah, a little bit more practical when you do have these conversations and switch that mindset from someone who's just kind of oh, you're getting in the data. You're messing it up. You're annoying like, whatever. Maybe annoying is a bit harsh but I'm sure we've all felt that way, sometimes.

To really seeing them as an advocate for your perhaps a partner, I'm curious, Leah, how you've had those conversations and how have you brought it up and transition that person from someone who maybe wasn't as familiar with how to actually use the tools and use the process to finding a middle ground where they are more of an extension of your team rather than kind of going rogue in the data. 

Leah Weiss: Yeah, I think in my consulting work in particular at data culture when you're building data capabilities, I think the number one thing that we try to infuse in all of our projects is you bring the business along in the journey. Our goal is to demystify data. I think sometimes, there's a tendency to say, like, you wouldn't understand, our transformations are complex whatever data modeling is it something. But in reality, data is just information and you want to bring people along in the journey and have them feel connected to it because then they'll be supporters of your work. 

The other thing I should mention is when it comes to data enablement, the product that I'm working on now at Preql is sort of a different way of thinking about this problem. So my whole career, I've been sort of managing data teams, building data capabilities and working to bridge the gap between business users and data practice first through culture and the conversations we've been describing. I will say that Preql is sort of a product approach to this problem, which some data folks will feel is extreme, but I've actually had the belief that business consumers should be able to manage and maintain their own definitions for reporting and info metrics with certain controls, of course. 

So I think part of the problem or at least this is the conclusion I've reached after however many years in this field is, it's also a bit of a workflow problem because business people are making decisions in whatever tools they use. And data people are working in a totally different environment and thinking in a totally different way and it can be hard to sort of switch gears and build alignment. So there's culture work and there's potentially product opportunities here as well.

Brittany Danishevsky: I think one thing that has been mentioned already, too, is the importance of standardizing your definitions and making sure that everyone is on the same page. I see a heavy nod there from Kelly. I'm wondering if you want to speak to the importance of making sure that everyone is aligned on definitions of your metrics and those kinds of base understanding so that you can really get collaborative and a collaborative approach from your teams.

Kelly Burdine: Yeah, the heavy nod came like, I mean, yesterday. I reached out to a stakeholder. I was like, hey, I just want to let you know here's this term, here's how we're defining it. Are you okay with that? Like, give me a thumbs up, thumbs down. It happens all the time and it's so easy to have this like little nuance in a definition but people are using the exact same term and then you get different numbers and then you get two people show up and they're like, I thought signups was this. No, I thought it was this. And then some data team person gets goes down this rabbit hole trying to figure out the difference and like that's not creating any value. Like, that's a problem. And so like Leah said, like, if you skip that step, it will come back to haunt you. I can promise. So it is so important to really align your stakeholders and get them to agree on a definition. 

And earlier in my career, I remember getting a bunch of department heads together and I'm like, all right, come on, we have to get this together. Like, what do you all think? And it was just like going around and around and around and like no one could agree. And so I've learned that that's like probably not the most efficient way to do that and so what I've been doing more recently is like the data team, because often, we have like contacts around like the technical pieces like what's possible with this and enough of the business contacts that we'll say like, here's what we recommend. Here's some pros. Here's some cons. Push back if you don't like it. And you end up getting like a lot of thumbs up from quite a few of them. 

There's always going to be some that people disagree with and then you have a conversation on those. But that's usually a more efficient way to kind of get that conversation moving and get everyone to agree on it and then I personally think that it really needs to be defined in a centralized place either in code. Some people define it in their BI tool, whatever it is. Like, you don't want to have to ask your business users to memorize the definitions. You want them to memorize the terms and intuitively know what they are but they shouldn't have to remember that, well, it's a sign up as long as they did X, Y and Z before this date or any of that nuance. Like, take that away from them. No one wants to remember that. And so essentially defining that, making it really easy for them to use those is pretty key to actually enabling it. 

Lindsay Murphy: I'll jump on that point quick because I think it's just a good process or thought what's in my head was one of the tangible ways that I've been trying to think about implementing that we just did one at Secoda is the metrics tree. So I'm seeing a lot more of the metrics tree conversation happening in the data community now. They get called all kinds of things, KPI drivers for these money trees, all kinds of things but essentially, the idea of showing how all your metrics kind of relate together and how they're all interconnected. 

And so that's an exercise that we just did here at Secoda to sort of figure out, what are the metrics that we care about as a business and how can we build our data stock around that? And so I have learned my lesson that if you don't do that first and you kind of start building down the roads and like nobody's on the same page, there's no alignment. People aren't agreeing on definitions of things. It's because the metrics weren't aligned on and it's not really a data quality issue sometimes, hopefully. So yeah, I think metrics trees I would say are the way to go. 

Kelly Burdine: when that happens, when they don't align and they're like, why don't they align? What's going on? People start to doubt the metrics. They start to doubt the data. They lose trust and they lose trust in the data team. Losing trust is easy, winning trust is really hard. And so you don't want to start off on the wrong foot. So it's really important to find those early and, yeah. I won't harp on it again but I have strong opinions about this one. 

Lindsay Murphy: Yeah, and I think it just gives you a place to focus like, then you're focused on the actual data quality problems for what they are rather than like, is this a misalignment problem? And then it's hard to tell what we are actually investigating here.

Brittany Danishevsky: But it really does sound like the importance of these issues that we're seeing within data, it can apply to anywhere. You need that collaboration. You need to be aligned with your stakeholders. You need to work with the end users. You need to get rid of your own biases and really think as a team. And of course, this all comes down to actual practical things that we're doing and it sounds like we're doing a lot. It sounds like we're thinking about what our onboarding looks like. We're adding documentation. We're getting aligned on metrics early and we're making sure that we don't lose folks' trust because I think that's a very good point. It's really hard to gain it back once it's lost and when you don't have trust in the numbers then you can't really use those numbers to actually move the needle on the business so it's really, really important. 

Moving into some other practical ways that we can continue to implement data enablement processes, we've talked about standardization of metrics. But there's some other tools as well for instance, like, office hours, onboarding programs. I know Kelly, you talked a bit about some of the videos that you make for your team. 

I'm wondering, maybe Leah, I'll kick it off to you if you want to start off with just some of the more practical things that you've done both even as a data consumer and as someone who leads a data team to get the ball rolling on data enablement. Have you run data office hours before? Is that something that you've done and found successful?

Leah Weiss: Yeah, I think office hours are great because they attract sort of those people that I mentioned before the squeaky wheels who can either be your biggest pain point or your best friend when building out data capabilities and you really want to surface those people who are trying to do more than data and help them get more self-sufficient. Everyone wants to be self-sufficient. That's the other thing. No one wants to be blocked when they're trying to get something done at work. 

So beyond sort of technical trainings, I think the biggest learning is that there's also opportunities to actually build community around data. I think the approach as I've mentioned a few times is can sometimes, you're often centralized, you're often under resource, you're overburdened but people get really excited about data. People get excited about new technologies. People get really excited when they can answer their own questions and solve their own problems. So I think building sort of a network of advocates who can be your testers and early adopters, that kind of thing has been really effective and then building sort of a community of data people and giving them the tools and resources to continue their own journeys has been really effective for us as well. 

Brittany Danishevsky: Yeah, I love that. I love the idea of, if you create this space, people will come especially those folks that might be the ones that at first, you are a little bit, not opposed to but you have a little bit of walls up. You feel like they're not necessarily a partner to you and really transitioning into not only having them as a partner but creating an open space where they can come and ask questions and have those discussions and really grow together. 

Kelly, any thoughts on this about onboarding training office hours. Is that something that you've implemented in the past? 

Kelly Burdine: Yeah, we actually do office hours here at Wellthy. We do it once a week and anybody can show up, anybody can sign up for them. Sometimes, we'll get a question a few days before and as long as it's nothing urgent but like, can you come to office hours on Wednesday? And it allows us as a data team to kind of stay focused on our priorities and we have that scheduled time. And then allows us to kind of work one-on-one with them and kind of bounce ideas, ask questions, show them. 

I often, during office hours, instead of me saying, hey, I'm going to share my screen and show you, I say share your screen. I want you to go do this and I kind of walk them through it. Another opportunity to kind of teach and increase that data literacy. And it's just a great way to kind of quickly get somebody unblocked, teach them something new. Sometimes, people don't know what questions they're trying to ask. Like, I have this problem. I think some data would help but I'm not exactly sure what to do and that's a great opportunity. Just come and let's talk through it together and I can make some suggestions and we can work together and figure this out. 

So now, I've tried office hours at other places with less success so I'm not exactly sure what I'm doing differently here but I mean, we get office hours attendees just about every

week and they've been very productive and people generally leave pretty happily with what they need. So that's definitely something that we've done that I think is super valuable. 

And then, Leah, you mentioned building community. I completely agree. I think that's super important. Last week, this report went out in an email. It's like a schedule report. The CEO responds to a bunch of us and says like, hey, I noticed this number changed. It looks great but like what caused that? I'm really bad at checking email. I didn't get to it for hours. But by the time I did, three people had already responded and each of them had screenshot-like metrics like, hey, I pulled this from here. I was digging, drilling down into the data and like this is what I see when someone else pulled another piece in. And like, it just warmed my heart. I was like, this is amazing. Like, look at all this hard work and people are working together and they're sharing data and they're helping each other out and because yeah, you have limited resources on the data team and so it just, it really helps when you build that community.

Brittany Danishevsky: It gives you some space to continue to grow your data stack, continue to invest in what you're doing instead of always worrying about responding to ad hoc requests. Of course, a question from the CEO may not really fall in the ad hoc request category but it's definitely very rewarding to see that the tools that you put in place, the structure you put in place and the training you put in place is effective. 

And I've got to say I think one of the most effective ways to teach is to get the person to do it themselves. I know starting out as a junior developer years ago when you're with a mentor and they go, okay, you take the lead and you show us in debugging and it's the most terrifying thing for sure and I'm sure folks who are new today to our data consumer feel that same way but it really is so effective. And especially when you're talking in the sense of creating partnership, creating community, finding your advocates. This isn't something to test anyone. It isn't something to make anyone feel any type of way. It's really, we're here together to empower one another, to figure out how to use these tools together and to continue again working as a team to move the needle.

I'm wondering, Lindsay, you've worked on big teams, small teams. And I know that we've heard a little bit from Kelly as well. Some data office hours have worked really well, some haven't. In your experience, Lindsay, how have data office hours worked for you? 

Lindsay Murphy: Yeah, we had a pretty similar process at my last company when I was at Maple. So we called it like colloquially data clinics because Maple was a virtual Healthcare company. So I think before I was there, they were doing them weekly and then they moved them to bi-weekly as part of them rolling a looker in the company. And we did find over time, I wonder now, Kelly, hearing you said that they were weekly. I wonder if making them bi-weekly actually made them less valuable because it did force people, like, if they had a question, they would just come to us and we couldn't say, hey, do you want to wait two weeks to come to this meeting? So in my head, I'm like, I think having the weekly is probably a good part of the success there but we did notice over time that the attendance started to dwindle so fewer and fewer people would come to them. So what we did was we shifted them to be, you could still come and ask ad hoc questions if you wanted but if nobody had questions, we would prepare little tutorials. So we would kind of do like, here's how you create a calculated measure in  Looker or here's how offset variables work or things like that. So different things that maybe a data consumer wouldn't normally get from like our basic training that we provided and just sort of like tips and tricks. And those seem to kind of take off. So we did start to see more people attending for those and we would have people watch the recordings after which was a valuable way of engaging them. 

Another thing that we were looking at doing which I hadn't quite rolled out but what I was excited about was an onboarding program. So whenever new people are joining the company, they kind of go through data onboarding which might be reading some articles or reading some documentation or watching some videos to kind of give them a lay of the land of like, here's the data that we have. Here's what we have access to. Here's how the data team functions, those types of things. I've gone through both editions of doing those live and the resource that requires every time someone onboards versus recording it and then people aren't as engaged usually with recordings so I think there's a double-edged sword there. But that is one that I do think kind of gives people a good foundation and a base to sort of understand your data team. 

Another thing that I've heard from other companies and other folks that I've talked to is proactive insight sharing. So if you're doing analysis as a data team and you uncover something interesting, it's like you go back and you share that with the whole company in a certain forum whether that be like a monthly presentation or even just like a newsletter or something. I think that that gives people some insight into what are the things that we're discovering about the business and how can I then take that and ensure that information isn't siloed within the different teams. And also, I think it gets people interested in data a bit more. So they can kind of see what the team is doing and what the applications are. 

And then the last one that I'll say is I think making documentation a first-class citizen as a data team. I think a lot of times, documentation ends up being this like an afterthought that nobody really wants to deal with. And I know this was a challenge that I was dealing with at Maple was we wrote a lot of our own documentation in terms of dbt but that wouldn't necessarily make it to the consumer. And so, the data consumers would have pretty limited documentation and look or they might know what a column is defined as but they might not know how it all kind of fits together in the broader data model. And I think that if you're going to invest in self-serve analytics, documentation has to come along with it because it's kind of like giving someone the keys to the car and then not really teaching them how to drive. You're just kind of like, here you go, like, figure it out yourself and not giving them the context on what you've built. So I kind of feel like making sure the documentation and the investment in documentation is done up front and done alongside of yourself is going to make things a lot easier than trying to fill it in later when you realize how badly you need it. 

And I think in the world of ChatGPT and LLMs, we actually have a lot of help now building documentation. So previously, you had to write everything by hand. I think ChatGPT can help write a lot of that or other LLMs and then we can kind of fill in the blanks and fix things where needed. So hopefully, we'll see that become a little bit better over time.

Kelly Burdine: Oh, I just had one thing to add about the proactive insights piece. My CEO asked us to start putting out monthly insights presentations. I was super skeptical of this at first. I'll admit it. We started doing this I guess in January and yeah, every month, we'll dive into a topic that's really relevant for the time being. And they have been so valuable. We get very high attendance, a lot of engagement. I get a lot of people I'll see in Slack afterwards like referencing metrics or insights that we pulled out. People like our product team taking those and saying we need to go tackle that problem and just a lot of action. A lot of action coming out of those and that's been awesome to see and we've gotten a lot of really positive feedback from it. So I'm a converted believer in the monthly insights presentation. 

Lindsay Murphy: I love that. Yeah, that's a similar format to what I had heard from someone that I was speaking to about how they did it. And my background for many years was as an analyst so it's very near and dear to my heart to kind of go and do that creative work and sort of uncover things that will be valuable to the business. I think it has so many legs because it then gives the people in terms of self-serve analytics like guidance on like, here's some of the things that you might want to look into more and then I feel like it kind of promotes the data team in the way. It's like, here's the value that we deliver rather than we're just building all the stuff behind the scenes. Nobody really knows what we're doing. I think it really puts it front and center like, this is what we're building and here's how we actually turn it into value so, yeah. I hope to start doing that here. 

‍Brittany Danishevsky: Yeah, I hope you do start doing that here, Lindsay, because I would love to receive those newsletters. I know everyone's always wondering, oh, another internal newsletter, another internal email but when it's succinct, it has numbers behind it and it can really move the needle on the product. I can definitely see why that is valuable. 

We have a really good question asking about, is data enablement more of a relationship building and defining between the data team and users versus a procedural version of enablement? I could definitely see why that question is coming up. I think we've really talked about both versions of data enablement and I would wonder, maybe we'll start with you, Leah, what you would think is more, where the weight goes? Which way the weight goes?

Leah Weiss: Yeah, it can be challenging to separate the two. And I guess I would say at the risk of getting a little bit too abstract here, when you talk about sort of measurement and metrics or even talking about raw data, you're talking about representations of things that are happening. So that if you're a physicist or a mathematician, you're describing real forces in the universe. Here, we're describing human concepts which means that you have to agree on them and the data itself that's hitting your warehouse that's being generated from your application is also sort of like a proxy for something that's happening in real life but it's not the thing in itself. So apologies for getting a little bit too philosophical but I think that's why the definition and alignment piece of this is so important because we are creating a shared reality of what these things mean and that you have to operate from a place where everyone understands that in order to make any progress. So that's like part one of this. 

And then of course, you need to build a process and procedure around that. I think if you sort of do one without the other, you have a lot of rigidity in your processes without a lot of shared understanding or you could have great relationships but still have data sprawl and data chaos. So I think the first thing is sort of creating alignment, create a shared reality and then build processes and tooling around them. 

Brittany Danishevsky: It's a joint effort. It's a little bit of everything. It's the answer no one wants to hear. Everyone wants to hear one strict solution and the reality is life's messy and there's a lot that goes into making sure everyone is aligned.

I'll ask one more question. I'll throw it out there. I know, Lindsay, you brought up the topic of AI and Large Language Models. Kelly, I'm curious what your thoughts are on how AI and Large Language Models will change data enablement over the next 6 to 12 months?

‍Kelly Burdine: Yeah, I mean, I hope that a lot of teams really start to dig in and use it because I think they can be super valuable. We've found ways to use this already and not just to write funny poems about our teams but also to create documentation. Naming things is hard. I think this is one of the hardest problems in data or coding is just naming things. And so I've used it quite a few times to be like, what's another word for X? 

Another great use of AI is to “explain this like I'm five”. Something that can be really difficult for data people but really any technical people is like, I have to go get my end user on board with this or I have to go explain this problem that we encountered and why we're going to miss the deadline or whatever it might be. And that's a great way to take what might be a very technical explanation and kind of break it down in a way that is easier for them to understand and they can explain because if they don't fully understand, it's really hard to get their buy-in. 

And so that's another way I think also like sharing insights and presentations and writing descriptions and these are all great pretty like low effort ways to kind of leverage like Language Learning Models to kind of just further superpower your team and enable your team to do things faster and more efficiently. So those are some of the kind of low-hanging fruit ways I see in the next, I mean, really right now but I think also writing code. I think when you're writing code, there's certainly things you can leverage those four errors. Sometimes errors can be really difficult to troubleshoot. You can pop those in there and it'll help you understand them. So yeah, those are all ways that I know I've kind of dug in and started to use them. 

Lindsay Murphy: Yeah, I've become pretty lazy now with errors in code. I'll just be like, what's wrong with us and it's like your table alias here or something. I'm like, oh, okay, it's like, that would have taken me half an hour to find that. 

Kelly Burdine: Yeah, that last close parentheses somewhere, yeah. 

Lindsay Murphy: So, yeah. And I think just to add to like my thoughts on the next like, 6 to 12 months is I think it just shows how much more important metadata is going to be for data because in order for, it's basically taking that business context that we've been talking about. Like, once you've aligned that, it's like, you now need to codify that and put that into a system for a Large Language Model to be able to understand. And so I think to really get a lot of the benefit out of Large Language Models on top of our data stack, it needs to actually be properly documented and have the proper metadata and context and tags and all those good things. Otherwise, you're sort of putting a Large Language Model on something that doesn't really have the information it needs to then generate the insider help you out. So I think it's just going to put a lot more emphasis on all the stuff that most data teams probably are leaving behind right now or avoiding because of the tedious work we don't like doing.

Brittany Danishevsky: Nonetheless, I'm sure we could have an entire other panel on data and AI and Large Language Models. I'm sure we will continue to have these conversations as it pertains to data enablement as well and even conversations around. Will AI replace or will Large Language Models replace data people? And I think the general consensus is no but there's so much effectiveness in using these tools to not only help you as a data practitioner but also help your data consumers. And it all ties back to those concepts that we're talking about straight from the beginning which is collaboration, finding your advocates, working with your teams and understanding that it is trial and error. You're not going to get it perfect the first time around but it's not about working in silos. It's about bringing everyone together and really moving the needle as a business because that is our ultimate goal. 

We have one minute left. I want to thank everyone for coming. I want to thank our panelists so, so, so much. You three have been fantastic. I've loved learning from you and I'm sure everyone else has as well. With this one minute, does anyone have anything to plug anything interesting you want to tell us about? Could be business related, could be personal, could just be a fun fact. I'll start with you, Leah, do you have anything to plug?

Leah Weiss: I do. If you are struggling with this question of data enablement, Preql is a new product we're looking for early partners to give us feedback and onboard to our tool and the idea is that it's a platform for business users to maintain those definitions but in a way that your data person will feel great about. So check us out, preql.com and we can also just show you the tool and give you a demo if you're interested. 

Brittany Danishevsky: Amazing. Thank you so much. Kelly, on to you. What do you have to plug or just a fun fact, whatever floats your boat? 

Kelly Burdine:Well, fun fact, I don't know how fun it is. I've never eaten a Cheeto and people are always really surprised by that so I'll throw that out there. I'll plug my own company which is Wellthy. It's a tech enabled care concierge service. So if you have any caregiving needs, child care, elderly parents, anything, we can help lift the burden off you and so you can focus on caring for your loved ones. So check it out. 

Brittany Danishevsky: and in 30 seconds or less, Lindsay, what's your plug? 

Lindsay Murphy: I'll say check out Secoda AI because it is a very, very interesting tool. Definitely, if you're tired of writing the documentation and the metadata, it can help out with that. So I was pretty impressed when I used it for the first time. It can write dbt YAML documentation which was like the bane of my existence so that's definitely, if you want to check that off your box as a data team, give it a shot. 

‍

Brittany Danishevsky: Amazing. Well keep in touch with us on LinkedIn. Let's keep chatting. We are going to keep having panels like this. We love talking about data. That's what we're here to do. Thank you. Have a wonderful afternoon. See everyone next time.

‍