[23.09.24] Data Strategy - A Journey

Hope everyone has a is having a good afternoon or morning today where we're at. We are gonna get started in just a moment. I'll just give a brief intro here and a few kind of admin bits to say, and then I'll hand over to to Jessica. So, yeah, first of all, welcome. My name is Taylor Brownlow. I'm a chief of staff at Count. Count is a chem space BI tool. Really, our mission is to make sure data teams are more than in support functions. So that kind of has two, ways that we think about that. One is, I'm getting some bluffs. Yeah. Feel free to say hello in the chat and maybe see where where you're here. Calling you from is always fun as well. So, yeah, we've kind of got two halves of that. So we obviously try to, find data teams like Jessica's that are doing things a bit differently, and hey, Mendel. And share other stories. So we have a lot of blogs and things about data leaders and how they're how they're doing things differently. And secondly is we have a a Canvas based beyond someone like I mentioned. So it's kind of like if you imagine, you know, Tableau, Jupyter notebook, and Miro had a baby, put together. It's all about kind of how to update decisions work collaboratively, have more flexibility to tell business stories, that kind of thing. So that's a bit about us and why we're putting talks like this on. Hopefully we have many more coming up like this. And, yeah, basically, I'm gonna talk as little as possible here today. A few things to know as you go. Any questions that you have, please drop them in the chat and there'll be time at the end for questions. Everything will be recorded. So if you've gotta jump off early or get disconnected, don't worry. You'll get a replay of everything. And with that, I'm gonna hand it over to Jessica Franks who, got a great talk for us ready to go. And I'm gonna disappear for now. So I will see you guys at the end for q and a. Jessica, over to you. Cool. Hi, everyone. Thanks for joining. I hear we've got people from all around the world, which is terrifying, but also really exciting. So, today, I'm gonna be talking about my journey towards creating a data strategy at Not on the High Street. Cool. So just a little bit about me. I'm Jessica. I'm the engineering manager for the data team at Not On The High Street. And my team basically consists of data engineers, analytics engineers, data scientists, and we are responsible for the data platform. And we make sure everyone in the business has the data that they need when they need it to make different decisions. So if you're sitting there trying to guess where my accent is from, I'm South African, and I moved to London in September twenty twenty two. And, essentially, I started my career as a telecoms engineer, but after ten years decided I absolutely hated it. And then I took some time off to study data science. And since then, I've worked in various data related roles, and I kind of see myself as more of a data generalist with a particular love for data and analytics engineering. I love DBT. I hate Redshift, and I also have two eleven year old sausage dogs who I brought with me to London. So for those of you who haven't come across Not on the High Street before, we're an online marketplace that supports different artisans, designers, and curators across the UK. We have over five and a half thousand small business partners selling over three hundred and seventy thousand products on our website. And not recently turned eighteen years old this year, which is pretty crazy if you think about it. So if you're looking for a gift for a loved one or maybe something special to treat yourself with, it's worth having a look at our website. Yeah. So eighteen years. You know? That's quite a quite an old company. Right? Surely, we've got this data stuff figured out. And answer to that is yes and no. So the company has gone through many changes over the years from having data set on a PC under someone's desk, to having Redshift and Tableau, and now a more modern data stack involving Snowflake, DBT, and Looker. We've had many iterations of data over time. And I joined the company two years ago after a number of key data leaders had left, and they didn't really leave much in terms of documentation other than some vague ideas that they should be that they thought should be focused on over the next coming weeks. The data team was split into two with one team focusing on insights and analytics and then my team, which is the one that focuses on the data platform. So here I was. I was new in the company, new in the country, and also new to this type of management role, trying to figure out how I was going to lead my team and frantically searching for a data strategy that didn't exist. I was pretty lost, to be honest. And as any good millennial will do, I headed to my bestie Google to see what she had to say on the matter. And searching for a data what is a data strategy kind of yielded some results like this one from Amazon. It was okay. I agree. That's what a data strategy is. But what does it look like? I really work best with examples. And I couldn't really find any. There was no neatly packaged answer. There wasn't a five step plan to the ideal data strategy for an eighteen year old marketplace focused on small businesses in the UK with two BI tools and a lot of unanswered questions. So I did a lot of research from Slack conversations to different articles. I watched numerous YouTube videos, but nothing was really sitting right with me. There were a lot of things about core components, different stages of data scaling, different terms like data informed, data led. All very nice, but all jargon filled and really overcomplicated. The only real directive I've been given from the business at this point was to save money. So I went back to what I know, retrospectives. My first data job was pretty amazing. So ten years in telecoms, start a brand new career. I started at a real estate agency that was data obsessed. I mean, we had estate agents using Power BI dashboards, which I thought was fascinating. And the CEO ran the company with agile principles, and we basically had a specialist team that helps us map out different processes and do a lot of retrospectives. I basically have never used so many sticky notes in my entire life. So after a couple of months working at Knotts and getting the lay of the land, I did a mini retrospective from my point of view to see if I could find areas we could focus on to improve data at the company. I looked at things that were going well, like our stable data engineering pipelines, advanced DBT usage, And then I looked at things that weren't going so well, like data only being available at lunchtime, much to our stakeholders' delight, and many duplications of tools and processes. I put together a list of ideas that weren't covered by existing initiatives that could make data work a little bit better for our users. I then identified five goals that I wanted the team to achieve. So that first was that business directive to reduce costs. And after getting rid of some unnecessary tuning, spending hours renegotiating contracts, seeing how we could reduce our snowflake credit usage, because at some point, we were going to run out of Snowflake credits before the end of our contract. Yeah, between, myself and the team, we managed to do a lot of things that helped us to achieve this goal. And then the remaining goals had a lot of progress, but they still have a lot of things that we can action against them in the future. So I had my goals, and we were working towards them, but still didn't really have anything that could explain why those were my goals besides for the fact that I had identified some things that we could be doing data. So I reached out to my mentor to see if she had any advice, and she recommended that I assess the data maturity of the company and pointed me towards a few resources. So data maturity basically looks at four main areas, namely purpose, people, method, and tools. And there are a number of things under each of these that you can either be really mature with or, alternatively, need further work to get to a higher level of maturity. And this was kind of a different way of thinking about things, and a lot of the issues that I had identified in my retro could kind of fit under some of these headings. But still, even using this, it wasn't easy for me to show how things impact each other or highlight the areas that we should be focusing on first. And then along came multi mapping. So someone shared a link to a YouTube video in a forum I'm a part of, and I basically sat through this forty minute video with my mouth wide open. This this is what I was looking for. The whole thing just appealed to me in its simplicity and its way to easily break down concepts into smaller components that are all interrelated and show how mature they were. Someone warned me became my new messiah, and I kind of feel like I've joined a cult. And I've been thinking about this for a while, but it wasn't until I was at a dinner with a fellow data leader, Patty, when he had explained that he had been new mapping out data at his organization using a wordy map. And he was using it to explain to the business why they had to make certain hires within the data team. And I think that was just the push I needed to get started. So I'm going to try my best to explain more demapping, but if after this talk this topic interests you, there's definitely some really useful videos on YouTube that give you a more of an in-depth understanding. There's also a free ebook that you can download, that Simon Wardley has created. So lots of resources available for you to have a look at. But, essentially, Wardley mapping is a process that you can use to make strategic decisions based on a number of factors. Essentially, it's a way to map out a process or product, and it allows you to identify areas of duplication or improvement that can help form your strategy. And it always starts with the user and their needs. So in my example for data at Knotts, I started with a data obsessed organization as my user, and I identified a number of needs such as data leadership, which is more around how seriously the leadership team within the company uses data than, like, a head of data role. Things like data metrics, common or ubiquitous language when talking about data, data governance, data literacy, all those kind of things, and then the typical kind of things that people would expect from a data team, like descriptive and prescriptive analytics. So once you've identified the user's needs, you can then take each of these needs and identify their needs. And then you basically repeat this process until you end up with a value chain with things at the top of the chain are more visible to the user, and then things at the bottom are less visible, and they care a little bit less about them. So I have a simplified example on the screen with a user who needs a cup of tea. A cup of tea needs tea and hot water. Hot water needs a kettle, and a kettle needs power. The user doesn't really care about the power. They are interested in the cup of tea. So for each of the needs identified in the previous slide, I created value chains, and many of those needs had common needs. And we'll get into that now. I just one more thing I need to explain. So each of those components or needs in the value chain can all evolve or devolve over time. And you can see on the axis I have in my image on the screen, if you look from left to right, you can see that process of evolution. So components that are rare or constantly changing are on the left in the Genesis section, whereas components that are more commoditized and kind of available as off the shelf solutions are on the far right. So as different components become more commonplace or more standardized within organizations, They move from custom made on the left to commodities that can kind of be purchased from a third party on the right. So now we've got two aspects of the various components that form part of a process. You can now plot that process or that product on a wordy map where top to bottom shows how visible the component is, and left to right shows how evolved that component is. Yeah. Just take a moment to take that in. So all of that, I plotted what data looks like at Not On The High Street. And, obviously, this is my opinion, so somebody else would have a different view from their perspective. And a lot of our data platform or the technology that we use can kind of be seen on the far right as yellow dots on the map. So these are common components. Lots of companies use them. We are gonna create our own data warehouse from scratch. We then have some of the skills and data organization and framework stuff that kind of moves from left to right and then left again. As the organization evolves, people join, people leave, the direction of the company changes. So that kind of stuff is always in a state of flux. So to take an example, data metrics, it's the red dot with eyes next to it in the top left. About five years ago, a lot of work was done to define metrics, and there's always a few few key metrics that will always be measured within the company. A lot were related to initiatives that have now been completed or were needed by specific people or teams that are no longer part of the organization. So as a result of that and for no one looking at it for a long time, it kind of devolved towards the left of our map. And now highlights that as part of our data strategy, we need to revisit our data metrics, see if they're still relevant, if the definition still makes sense, and if any changes need to be made. Similarly, with data models, there were over one thousand two hundred data models across two DBT repos when I joined notes, some of which were based on data from third party tools that are no longer used, but the models still exist. And therefore, a lot can be done to clean up and simplify some of our data models. Our dbt repos are an interesting one. So we have two dbt repos, one that's run from dbt Cloud that feeds our BI tools, and another that has a custom Python implementation based on an outdated version of DBT that runs on an AWS batch container. And between these two DBT repos, we have a lot of replication and interdependencies, which makes it really, really difficult to maintain and improve our data models. So we could result another project as a result. We could identify another project as a result of this working map to basically merge our two d d t repos together, and, this will enable us to have one way of looking at all our data models. So with the boarding map, you can identify areas you wanna focus on to evolve them or mature them if you wanna tie it back to kind of the data maturity stuff I spoke about earlier. And then you can kind of end up with something that looks a bit more like this, where things have shifted a little bit more to the right as you're evolving them. So to summarize, all the maps can help you easily identify quick wins, duplications, and focus areas. Your road map can now contain initiatives which have a set of directions to move your components from left to right on your road map. And you can easily justify the reasoning behind any initiatives you want your team to focus on using the map. And lastly, it can help with the assessment of data maturity within the organization. So what's next? So we are actively working on some of the initiatives that have been identified that can help evolve some of the components on our Wardley map. We are also gonna start planning for future initiatives and figuring out the direction of AI and ML at Mount on the High Street. And lastly, and hopefully something all of you are willing to help out with, is understanding what other companies are doing as part of their data strategy. So, yeah, thanks for listening to me talk today. I look forward to hearing any of your questions or any advice you may have around data strategies. Nice. That's amazing. Yeah. Thank you. So, yeah, please do drop any questions you have for Justin in the chat. While that's coming up, I've got a question, actually. It seems like, you know, the first step of this is going to work out. Like, you've kind of decided the data obsessed organization is the high level goal. How did you come to that conclusion, and did you need to get you know, did you talk to anyone else in the organization to kind of get some high level input on this before you really dove into it? Not necessarily. So with with the walking map, because you need to start with the user and their needs, I just added data obsessed organization as my user because I didn't wanna just put knots as, like, an answer. So I want people to be data obsessed. I want them to use data in every decision that they make. I want them to, like, always think how are we going to measure this when they they're doing an initiative. So I want the the company to be data obsessed. And that's kind of, like it's not necessarily terms that have been used, but I think that word obsessed resonates with with our executive team. So, it helps having it on there. Yeah. Yep. I like it. Okay. I've got some questions coming in now. So first off, from Emily. I guess, like, I think. How was this received by senior executive leadership? Yeah. So I first took my boss who's the VP of engineering through it, and I think it's the first time that people have actually been able to maybe they don't understand all the terms that I use, but, like, understand why I wanna do something. It's it's, like, plenty of this. This is why I wanna do an a project to merge our DBT repost together. So this project has been on the back burner for, like, three years and just hasn't ever been focused on. And this it's really important from, like, a technical debt perspective and from my perspective and my team's perspective, but it doesn't really move the business forward. It's not like a cool data product at the end of it. It's just kind of a lot of tech debt. So this was a really easy way for me to explain. Like, there's two dots in a map. Anybody can understand. I only want one dot. So this is the project that I'm gonna embark on to get one dot. So it's a really nice way to kind of break down things, and then they can also now see how everything is interrelated. So if you want more if you want AI and ML, we can't do that. Like, everybody, oh, we need, Gen AI. We want to say we do AI at the company. K. That's great. We can do that at some point. But that AI and ML relies on all of these things, and all of these things are not very mature at this point in time. We need to mature them a little bit more before we can even begin to focus on AI or ML. So I think, yeah, like, it's been a good way to have discussions about why we wanna focus on certain initiatives within the team. Nice. I like that. Questions are are rolling through now. I think that Omar's question about presenting this to the business, I think you've kind of answered that. But, Omar, let me know if you've got something more specific. A few questions about tools, what software you use to do this. Yeah. Anything there? So you can use any kind of graphing tool. This one I did in Miro. I think count has graphing tools as well. You could use Visio. So pretty much I mean, if you really wanted to, you could use PowerPoint and just put circles and lines and things between it. So at the end of the day, it's it's more about what you're trying to communicate than the tool you're trying to communicate it with, I guess. You could even draw it on a piece of paper if you're so inclined. I just prefer, like, a tool that allows me to drag things around. Because if I'm like, oh, wait. No. That doesn't make sense. Oh, that's actually not as visible to the user as I thought it was, then you put it further down on the map. So it is easier to kind of use a a tool like Miro to do that. And we will be sending around a template after this as well, both for Miro and count. So, you'll have a bit of a framework to kinda get started with that. It'd be good. Question from Izzy. How did you gather all this information? Yeah. So it's a great question. So that's why I said it's a lot from my perspective. So I sat doing a lot of this myself. When I first joined the company, there wasn't even an architecture diagram. So there's maybe one or two small architecture diagrams for very specific components in our data stack. So not really related to this, but I spent quite a lot of time going into all our different tools, all our different repos on GitHub, and kind of just getting a lay of the land of what data actually looks like in terms of, like, an architecture perspective. A lot of this also came from discussions I've had with people, and that's why I said at the beginning, this is kind of a very one-sided approach. And some of things are informed by other people. But if I ask somebody else within the company to do something, they would come up with a completely different map. So Wardley maps are meant to be like like you can have a first step, and then it's a collaborative thing to, like, define. Okay. Do you agree with this? If not, why? Where do you think this should be? But all the kind of points and things on the map either came from discussions, from blogs I've read, from different articles, and just kind of, yeah, doing something and thinking, oh, this is this value at the top needs these five things as well. So as you're doing that value chain analysis, you kind of build up the map over time. And each of these little components on the map could probably have its own model map all by itself as well. So it can be as intense or as high level as you need it to be. Yeah. It's a good point on on iteration. We just did a a session on metric trees a couple months ago. That was one of the biggest piece of advice there as well. It's it's just taking the first step, put something out there, and be prepared to kind of discuss it and write. It's, just really good advice for this kind of stuff that's really complicated and involves a lot of people in this great way. So I'm trying to keep up with all the questions. Good question here from Simi. How was it received by the people reporting to you? What's kind of the data perspective on on this? I I think they liked it because it was something that they could understand. This is like they could finally work on projects we've been talking about for months now and be like, yes. We can finally clean up our data model because we can justify why we're doing it. I think that's been very satisfying as part of our DBT repomage project that we've been doing, and we've been cleaning up a lot of the the old logic that we've got and just simplifying things because there's a lot of overcomplications sometimes. Like, people are really coming up with clever solutions to things, but sometimes a clever solution is not the most simple solution. And we want simplicity as part of our our goals. Simplicity is really important. So I think it's been well received by my team. I've also done this presentation for, the tech team as a whole at Not On The High Street. So, we have, like, once a month, we do, like, share different bits of information with the entire tech team. And this was kind of a presentation that I did. So just a different way of thinking about strategy or thinking about a process and how you can map it out, which is applicable not just to data, but many, many different departments can also do their own ways of, like, breaking things down into smaller components and kind of assessing them from a maturity perspective. Yep. I'd be curious, yeah, if any of any of those other teams adopted something like this. I can imagine it being something that's picked up after you presented on it. Yeah. I haven't seen anything, but there were people who wanted to kind of know more about it. I guess it's always, like, priority. Is this something that you wanna do or have time to do? Because it is some it takes a while, so you have to call that time, to kind of put it together and, like, iterate on it. Like, since this has been done, I haven't actually gone back to this diagram to update it with, like, work that we've done, which is, I mean, something that I probably should be doing just kind of as we are evolving over time as projects progress. Those kind of whole landscape changes. So we need to continuously go back and look at it. Yeah. And and, yeah, I can still the software underneath this evolving at the same time as well. Mhmm. Lots of different. Yeah. Questioning about kind of using this oh, so I keep forgetting this is quite but, did you use this in conjunction with company goals or OKRs or or maybe did you think about how to integrate that with this at all? So not necessarily company goals, but at the moment, it's mainly the the tech strategy. So trying to because we're a data platform and not, like, data as a whole, it's trying to align our strategy with the tech strategy as well. And a lot of our goals overlap with the tech strategy, which is quite nice because I've done my goals before. Our new VP of engineering had introduced the goals that he wanted the or the strategy for for the tech side of the business. And simplifying is, like, one of the main goals that we've got to try and simplify our techs, simplify our data because we don't need to be so overly complicated, because that slows us down essentially. So, a lot of these things will help enable the business to achieve some of the goals that they've set up. So the business needs different data. I mean, the data metrics kind of measure the success of the business. And as part of that data metrics project, we've started working on metric trees, which is a whole different way of looking at metrics, which we have to start getting the business used to. So that's also now an iterative process. We've got one small little metric tree that we're now gonna start adding to, and everybody we show it to is really excited because now it's starting to simplify things. So it kind of allows us to develop data products that are now useful for the business, because we've had time to focus on it, because we want we've made it a priority. This is so far on the the left of the graph. Data metrics, we really need to improve and then get it more to the right. So how do we do that? So it's a beneficial thing for the business. Nice. That makes sense. I I think it really kind of, almost easy to forget part of your presentation more was those objectives at the at the top when you kinda add simplicity into those islands. I think worldly maps are so broad. It's easy to look at them from a lot of different lenses, and you can kind of see, you know, things that you wanna see or things, you know, but but having those kind of goals to start with, I think, helps you read it a certain way, which is nice. Alright. Another question here from Simi. How long did it take you to get up to speed after joining the company before making any changes and decisions? That's a tough one. I feel like I'm still learning things every day, and I've been there two years. I would say for me to feel really comfortable with things, it was probably about six months. So the first couple of months was then observing and, like, helping out with things we required. There were still projects that people were busy with based on people who had left. So it was, I would say, probably, like, four to six months before I could come in and, like, make improvements to processes or, like, even identify areas where we were having issues. But, yeah, every day I still learn something new, and that's that's always great, I guess. But yeah. And, question more conceptually on the wordly map itself. The visible versus invisible, is that specifically from the perspective of the user? Yeah. So when we look like, if we started at the the top, so the user is basically only caring about these things. Then, like, these are the things that are visible to them. And then as you kind of move down that map, it's kind of less I care about them. So if I had to do this graph from my perspective, like, it would probably be a little bit more reversed because I care about the technology, I care about the platform, and less so about the things that are built. I mean, I'm not too worried about a graph and an analyst builds on something unless they told me that it's wrong. But from my perspective, like, if, our AWS batch container that imports data from a specific third party tool doesn't work for a few days, like, that I care about. So it's it's all relative to the user that you've put at the top of your graph. So in this instance, that's our data obsessed organization. So all our users who use the data as opposed to, like, me who cares about the technology around the data. Yeah. That's the point. Okay. Next from AO. Did you get any pushback from stakeholders? Do you have any kind of leverage? Sorry. Do you have to leverage kind of your VP or anything? Did you did you have, like, a green light to do this kind of work thing? Yeah. So that was one of the benefits. So I had been tasked by our VP to put together a data strategy. So from a board perspective, they're very interested in getting data into a more advanced level within our own high street. So we have both, the board's kind of blessing to to work on data projects as well as the VP of engineering wanted, like, a good focus on data strategy. And I think because some of these address, like, the initiatives that we wanna work on to kind of shift things a little bit more to the right, are going to help with some pain points within the company. So, like, common language, like, conversion rates. You ask anybody, they'll all have different versions of what conversion rate means to them. So it's about kind of these are problems that keep coming up and keep coming up, and it's about, here are our plans to address these problems and kind of come up with with solutions that everybody's on board with. So this is just, like, outdated strategy. We obviously enable this for the the business with a number of initiatives that they work on. So that work kind of happens alongside this. So, obviously, we will do a little bit of work on the data strategy. But if all of a sudden there's a new marketing initiative that needs a lot of focus, then we because we work in a natural way, we're able to shift and, assist with that. And then we kind of always have these projects that we can work on in the background that we can dedicate, for example, like, sixty to seventy percent of us sprint to and the other thirty percent to to the more, the other projects that aren't being driven from us ourselves because we're sometimes a service team, and we we have people who need things from us. Christopher Hizzie, did you find that data literacy and behavior actually moved across the map after completing more tech focused initiative, or does that meet its own project? I think I think it depends. Our our data literacy, you can see it's kind of sitting in the middle there. Our users are quite data literate, I would say, from my opinion. Like, they can use Looker by themselves. We have a lot of Looker training that people can have when they they first join the company. So to answer their basic business questions, we don't really have to get involved so much with that anymore. So I think data literacy is quite, quite high. And, obviously, a lot of these initiatives like defining common language and defining our data metrics and simplifying how we visualize those metrics will go a long way to improve data literacy. So from my perspective, one of my goals was embed. And embed in this context means I want data to be embedded in every decision that somebody makes when they're working. I've not so, like, from like, do they have the data they need to like, for example, marketing, can they decide what campaign needs more budget put against it? Or customer service, can they decide, which areas they need to put more help articles for? Because people are struggling with this, and they're getting a lot of calls about that. So it's kind of making data a part of people's lives. They don't even realize that their data are, like, obsessed. It's just, like, this is part of my job. I log on. I get the data to do this, and then I do this. And when I'm working on a specific initiative, I measure it in this way, and that requires data in some way, shape, or form to see if that initiative is a success. So, yeah, I think if you have a problem with data literacy, you can have separate projects to focus on that because you can like, any dot on this map could have a separate initiative behind it to shift it more to a, like, to a more mature state. So, yeah, I guess it just depends on the company. But it's a good way to focus. So if your little data literacy doc is sitting very far on the left, you can now explain to people why you want different training or, different documents or whatever you wanna put together to help shift data literacy within the organization. Yeah. I guess that's a really good point. I think kind of looking at the map, there's a lot of technical dependencies, but, like, processes feels a bit I I get why they're kind of not on there, but they're kind of like this unspoken part of the the puzzle. So it's almost like, you know, if you think about the, you know, the circle of data literacy or this point, yes, that is dependent on certain tools and even technologies that you have in in yellow and stuff. But it it is also, you know yeah. How do you, you know, speak to people? What's that process like? What is the training like? All these other, things that, maybe are kind of behind that that dot. So it's helpful to think about it, I guess, in terms of, like, okay. If we wanna move this dot to the right, yes. Here are some technical dependencies, but here's also everything else that goes into it. Yeah. Alright. And question from Reagan here. How have you expanded on the Wardley map into a fully fledged data strategy document, tooling, etcetera, and how did you transition this into a road map? So I don't have, like, a, you know, here is my ten page data strategy. I've got these slides, well, some of these slides kind of combined with a few summaries of the the initiatives that we wanna work on. So I can kinda show you an example of what that looks like. So, yeah, one of our kind of tooling things was around ending our contract with Tableau. So this kind of ties our goals with our strategy. So So every time there's a goal, kind of highlighting what goal that works towards and a little bit more about that initiative that we're working on. Merging our DBT repos, explaining why we wanna do it. There's loads of other documentation places we have for for specific initiatives and the way we need to document them. But, like, this is just kind of an overview for our SLPT team to kind of understand why we wanna focus on certain things. So this is why we wanna do it, who's impacted, what the goals are that it's kind of working towards. And, yeah, then it can be backed up with that working map so we can kind of show you on the map. So it's more of a discussion point rather than that. Like, here is a huge document, but kind of these were the documents of these. If you have a huge document, no one's gonna read it. So, I prefer to present things and have something for somebody to go back and reference something short, snappy that they can go back and look at. Yep. Good advice. I've got one last question if that's okay. I know, you mentioned that there are some things you would do this that you had anticipated seeing, like, you know, the DBT core cloud instance, maybe even Tableau. But was there anything that was really surprising to you? That's an interesting question. I mean, I don't think surprising because I've created this. So if maybe somebody else had created it, it would have been a little bit more surprising. I mean, this could be wrong or wrong from somebody else's perspective, because I guess this is my opinion of what things are. I think the nice thing about this is it's been able to highlight gaps in knowledge rather than skill sets. So you can see we've got, like, data analysis and data science quite far to the left. And that's not, like, dig at anybody's data science or data analysts or or data analysts and their skill sets. It's more around we only have one data scientist. We have a very small data analyst team. So it's more around we don't have enough people to serve the the needs of the company in terms of data science needs or data analysis needs just because the that's a body problem. We don't have enough people or enough hours in the day to kind of service kind of things. So if those two were to improve, we either have to upscale other people around the company with, skills to analyze data, or we need to hire more people to kind of help with that. So, yeah, I guess it's kind of just making sure it's not this isn't, like, reflective of anybody's skill set. It's more around, like, the skills which exist within the company. There may not be enough of things, which I I guess is, like, an interesting way to look at things. Yeah. That's a good point. And, yeah, I think we've answered all the questions. I think maybe, do you wanna leave us with maybe one last piece of advice you'd give anyone who's, about to to start using more than enough for their data strategy? I think don't overthink it. Just throw it together. It's it's not that nothing's permanent. You can change your mind next week if you don't like it or if you've had a conversation with someone that changes your opinion about how things are or you work on an initiative that kind of shifts something. It's a living, breathing thing, so it can change at any time and it can change based on conversations. It's just I think it's a really nice way to kind of get all your thoughts out on the map and kind of or, like, in one place here is kind of everything that I've been thinking about for the past couple of months. Let me just put it all down, and I could shift things around. And then I'm gonna speak to someone and then move things around a little bit more. Yeah. It's just get started. I don't think there's any right or wrong way to do it. I mean, if you look at body map examples from around like, everybody has a different perspective. That's the thing. It's a completely unique to you or your situation or your team kind of thing. So I think it's just a positive thing to have any kind of discussion around data and how we can improve it within different organizations. And if this is a tool to facilitate those discussions, that's always great. I think that's a great point to end on. Jessica, thank you so much for doing this and sharing this. Everyone, thank you for joining. Thanks for your great questions. I'll send around, the recording to this and a few other bits of materials, to help if you wanna get started on this process yourself. And, yeah, send around the the metric tree information as is requested and, yeah, anything else that they're coming up that might be useful. Alright. Enjoy the rest of your day, everyone. Thank you so much. Thanks,