Why Context Is the New Currency in Data Strategy with Chris Tabb of LEIT DATA

Speaker A: I coined something else a few years ago, which is meta metadata. Data. Uh, about the data. About the data is where the value is.

Speaker B: Now you're tuned in to the Data Masters podcast. In each episode, we dissect the complexities of data management and discuss the data strategies that fuel innovation, growth and efficiency. We speak with industry leaders who share how their modern approaches to data management help their organizations succeed. Let's dive straight into today's episode with Anthony Dayton.

Speaker C: Welcome back to Data Masters. Today I'm thrilled to be joined by Chris Tabb. Chris is the co founder and chief Commercial Officer of Leet Data, one of EMEA's fastest growing data consultancies. With an impressive 30 years experience spanning BI data architecture and enterprise analytics, Chris has seen the evolution of our industry firsthand. He started his career at cognos in the 1990s and has worked through almost every layer of the data ecosystem since. Beyond his strategic work driving business value and advising startups, he's also a fellow podcaster hosting the Data Value show, which I encourage everyone to go listen to. Today we're going to dive into how our careers have shifted upstream from BI to raw data, why we need to rethink traditional ROI to more build smarter business cases. And finally, we're going to demystify the context layer. What it is, how it keeps working organizations from falling into the chasm of inaccuracy. Chris, great to have you on the show.

Speaker A: Well, what an intro. That as well, being called a master to start with and then all the rest of it. I've even forgotten how much I've done over the years. So thank you very much for the intro. It's great to be here. Yeah. So the beginning. Should we start there? Really?

Speaker C: Yeah. So in a funny way, I think we, as we were preparing for this, I think we both noted that we have, in that sense, similar career trajectories, having both started on the consumption side of the data. You started at icognos, I started at qlik. And let me relay a story, if you don't mind. I just got back from the Gartner Data and Analytics Summit in Orlando. In the initial introduction that the Gartner analysts do on stage, and at some point early in that presentation, they said something like, isn't everybody sick of dashboards? And the entire room erupted into applause and cheering. And it was just an absolute moment where I was like, oh my goodness. Like where we started our careers around, um, helping people consume and use data more effectively is that era is very much over and everything has really shifted back in the value chain to the data that supplies those. So I'm curious, I suppose, if you agree and uh, or are dashboards still relevant? Yeah.

Speaker A: And you just, I just triggered a thought. I just make a note because otherwise they, they pop in and out of my mind. But a little while ago I, I, I did a, a view of what UI would look like in the future. I said UI is just going to be a prompt box and forget, you know, the dashboards and the rest of it. That will be our interaction with it. And I, I was right on this. Occasionally it happens occasionally. But we were doing a lot of stuff with Thoughtspot back then and, and that was their sort of uh, tagline back then. Dashboards are dead. And I think, first one, define what a dashboard. If a dashboard is a static bit of information that there is no business decision being made of, yes, it is just a pretty picture. It's no, it's no more than that. But if that dashboard is driving business decisions and you know, the business processes are being driven off those dashboards, then they're not dead. I, I think it's how they're being used and you know, a prompt now can create your dashboard that you go make the decision on. So yeah, again I think it was a bit of a marketing thing. Like, okay, you know, anyone that's got a nice little AI front end on their, on their original dashboard in products, yeah, they're going to go down that route. So yeah, I think independence, yeah, everything needs to be driven driving a business process or decisioning process. Otherwise, yeah, it's just a bit of a, uh, bit of nice chartish.

Speaker C: So no disagreement. But there's a sort of second dimension to this which is maybe we could even say whether it's a prompt interface or a dashboard interface, it's kind of a solved problem. But what isn't a solved problem is the underlying data itself that.

Speaker A: Oh yeah, yeah, yeah.

Speaker C: So that and I think part of what people were reacting to, I think in that moment was this overemphasis on the visual presentation of the data and a lack of emphasis on the actual data, uh, solve. I'm curious if that resonates.

Speaker A: I've just, Again, I just click another book. I remember back in my BI developer days, I probably spent more time getting the legends in a particular format, uh, or the colors on the charts and mapping to what the user would want than probably the data preparation itself. And I think that's gone back down. The point was we were delivering this for people that used to have PowerPoint charts. So they wanted to report what they were used to, which is the power, which is the same problem we have with Excel as well. There's a slightly other, slightly different story, but yeah, so that I think there was too much on the. How it looks in the presentation rather than what we going to do with this and how accurate is it? And also what's the next question I'm going to ask if I look at that? Oh, great. But why is that more? Well, why has that increased more? What is the difference what changes have happened during that period? Why is the number of customers increased 100% in the past two weeks where that couldn't be impossible? We did a migration. You know, it's those sort of questions that the prompt approach or that iterative sort of analysis of that data that is not the question you want to ask. First of all, it's actually the fourth question didn't know you want to ask that is actually going to provide you the value. And I think where we are now and where we're going, we are able to provide the ability for people to ask these questions and get the answer. But how much trust is there in that particular response? Everyone's like AI hallucinating, why am I going to trust the information there? And they're right to have some concerns. But this is why you need to make sure that it's set up in a way that there is no, there's no way of actually creating these mistakes because you've already built all the business logic and usage of that data and context. Even though maybe I should use that word too early in this podcast. But yeah, um, yeah, to make sure that it is writing accurate SQL that you would have written yourself back in the day and it's providing you consistent answers that would be the same if another person in another department is asking similar question off the same data set. But it's always going to correlate. You're always going to, you're never going to get that boardroom where someone's going to say, uh, you know, our net revenue this month was this. And someone's going to say, no, it was this.

Speaker C: Right? Yeah, I used to have this thing, I would say, because it would be very common for, uh, customers to complain about the quality of the data in their dashboard. And I would say, no, no, you don't need to worry about that because by, you know, sunlight is the best disinfectant. By putting the data in the dashboard, then people will cause, be caused to go fix the data. Uh, which admittedly looking back on it I think is a lie that might be a bit strong but it was oversimplification maybe a more generous way of saying it. But I'm curious you know, as you've moved in your career and now finding yourself on the advising side of the business do you feel like that's given you a kind of freedom to, to say different things to customers and do you find yourself saying different things because you're not sort of beholden to.

Speaker A: So I think uh, from going back to the career I've been on and probably why, why I've uh, either stayed well people liked, liked me and I kept I've worked many people the same place over and over again. I don't, I say what I think and I say what I believe rather than why what they would want to hear. And I think being a contractor. So I've only ever been I've had two permanent jobs one at Cognos, one is the one I employ myself now within the company. And between, between those 25 years, no maybe 20 odd years I was a gun to hire contractor. Uh, you know and I went there because I wanted to put the best, have the best approach for the best solution. I had no ulterior objective my career path there or not accepting boss or the fact that if you didn't like it I know I'd go somewhere else because I knew I could, I had the confidence knowing that I wouldn't be sure to work based on the historical um sort of experience and again being in your home company as well and I have to answer people I have a chairman, you know he makes make sure that I do, I have a CFO that makes sure I do the right thing there but from an advisory to a client, you know I, I do like sort of sales but I, I, I say a part of my pitch is you know I'm a architect first, a salesperson second. I can only sell you something I can believe in and yeah and that I, I, I wouldn't yeah maybe yeah that's not the approach I've taken. I think that's, that's being get recognized and you know that that advice is, is taken seriously because it's m not driven by any ulterior motives. Obviously I need to make money but I giving, giving the right advice actually uh aids that rather than a uh, rather than not. And I think to the other thing to mention is I still do. I'm probably more hands on than I have been in many years now with regards to building stuff. I uh, doing R D We're building up frameworks. I've built my prompt engines to do internal optimization. The learning I've taken from that, I give back to the clients and they say, look. And I'll say, I built a system of context. You know, it's another thing which is on top of all my system of records, it's able to be my one, one portal that actually I can see where anything's going on the business. And it's driven by AI. You know, it is. We're at the right, in the right places and that's brilliant. I think dimensions there, you know, using the right tool for the right job is also very important.

Speaker C: So speaking of tools, I think, and uh, I know you hosted an entire podcast on this. I did want to touch on this question of business value and roi. I do feel like you are the kind of world expert in this area. I also think this is arguably one of the most challenging pieces of the software space when it comes to data software, data and analytics software. Building the business case. I feel like a large proportion of the sales process, of the prospect engagement process is helping data teams build that case almost internally. Like they're bought in, but they don't know how to speak the language of business to get the business side to uh, sort of buy into it. So maybe share a little bit on your. I know you have a very thoughtful framework around this.

Speaker A: Yeah.

Speaker C: How do you think about this?

Speaker A: So I'll tell you a story about the roi. What's ROI and why it always annoyed me. So I was working at a. I was head of architecture or something at a fintech company and the marketing, marketing department. Cmo. We both went with our presentations. The CMO was putting, putting a proposal for Salesforce. We put in to do this, to do that. It had 50 times x value in customer retention. This, this, all these things. Anyway, uh, I went there with, with my proposal, which I wasn't asking for nowhere near as much money as they needed for to put in Salesforce, but I was evidencing, uh, you know, a. Probably a modest, A modest but valuable return which would have actually unlocked other things later. So it was foundational that it would have paid for itself and a little bit more. But then you could actually do use case three, four and five. Anyway, I lost. You know, I didn't, I didn't get it. And I was there long enough to see the Salesforce project fail miserably and cost a load of money in return. No value. And if you'd hedged your bet and just give Me a bit of chump change. You know, I think that they would have been in a better place. But you know, I didn't go full smug mode and tell Togo, but I think they all, they all knew. And so uh, let's step forward to the term business value. And probably about three years ago I started using, using it and we mentioned Joe Reese and Matt Housley did a book called the Fundamentals uh, of Data engineering on, on O'Reilly. A very good book. I mean you see my name at the beginning. I did a little bit of a forward on it, but yeah, but you know been talking to them and me and Matt were going on a journey. We're going to try and do some book on. We never actually made it, but we're going to do a book on it. So we did a lot of thinking and we hung up just on what the definition of business value was for a long, long time. And the thing we had both agreed on in the end and you uh, know a lot of, a lot of debates with other people over a few beers over a few months was it was a positive evidence effect on your business objective. So it was never about the bottom line because it's not always about the bottom line. It may be on the second by second degree but maybe not directly. And the reason why I say that is, and I give this example, Uber never made a profit for 10 years. So was the objective of any of they did to actually adjust the bottom line this year?

Speaker B: No.

Speaker A: Next year? No. Though hopefully maybe year three or four. But it wasn't the gate. So the value there is, it's customer attention it's getting, it's actually acquiring new areas, not actually m making additional additional profit or bottom line that point. And there could be some eco sort of thing you want to do is making sure you'll see your carbon neutral. Again, not actually directly make it, but it's past your business objectives that you agree to your shell. So that's when we got to okay, what's business value? So since then I've taken and we're using this now in a few clients taking this to, to a. The next level of okay, how do you provide business value to a client that is evident. So the approach we take is, is the friction approach. Okay, so you've got actually I might include a third one but let's keep it simple for now. It's two. You've got business friction and delivery friction. So what is friction? Okay, friction is a time complexity and effort to perform an activity compound by frequency how often that thing happens if you're able to look at the business processes. And this could be via a combination of interviews, log mining, looking at the UI flow, uh, and M. Multiple mechanisms to get the metadata, associated information to start to understand where there is business friction, where there is optimization that could happen or processes that you know backwards and forwards between two teams that could be solved with something simple. So then, then that's your business friction. Then your delivery friction is how long does it take you to get something into production. And engineers love engineering things. Okay, so you go, there we go. Oh, and then, oh, look on our backlog. Oh, we're going to change this. I've done this all in, I've written it all in some scripting language now that means I don't need to do this bit of infrastructure and ah, it's automated. Brilliant. How often do we do that? Well, every three months we might have done. How long does it take you? Half a day. A day. So how long does it take you to do it? What's, what's on the back? Okay, right. There is no, and that is a vanity project, an engineering driven project, not a quantifiable project that is actually linked to business value. So the other part put into this now is referred to as force multiplier. So if you can identify a false multiplier, which is something that is either reusable, so basically it becomes a uh, reusable asset or a false multiplier is the amount of effort you need to put in to the value you get from it is you get more. So I'm going to call it the Millennium Fulcrum. You know, if you remove the fulcrum, um, and you move that fault with automation, that means the effort you put in here, uh, is a lot less to lift the load on the other side. So identifying where in the business world or in that delivery world, force multipliers, you know, you solve it for once or the effort you need to do it next time you get the same value, more return from it. You can now plot a evidenceable business value roadmap that is iterative and if you look at these things and you work out. Okay, right, yes, there's a lot of value in this, but it's really hard to do. So now I've got this, I've got all of the information there to start having the right discussions with the right people in the business and taking out emotion and uh, any maybe you know, these vanity projects and say, okay, let's do this stuff in the right order. Yes, you get to build your nice fancy framework. We need that Hugh, next year. All right, that's, that's a year two objective because by then we need it because we want to spin up more of these things quicker. Uh, because we're opening up another product line then so we don't need it now. So yeah, business value just leave. Yeah, we actually have the force multiplier discussed anyway. So yeah, if you get all the right information and package that up and internally what we have as well, uh, we have a platform blueprint and which link onto the contact there in a minute actually. But that platform blueprint is a technology agnostic, functional domain component platform and that will give you everything you may need at one time, but you may not need it today. And uh, we've got some bit knowledge engineering done in those. We know which components are grouped together, maybe could solve by particular products. If you go with that then you solve multiple pieces of it, but you're not putting in. I'm building a snowflake with a Sigma and a Tamar in it. Ah, well actually you're doing a bit of data quality, you're doing a data app and you've got a wrong. And we've been always uh, been making that same mistake many, many times by describing the technology and actually not what the functionality is. And then it makes it very hard to swap things out later because there's no abstraction from that. So using our blueprint and using our uh, uh, frameworks that we have underneath these things of best practice for each of them, we can with a little bit of effort working with a client, provide them something that's driven by what they need, not driven by technology roadmap that we're implementing on there and doing things in the right order, uh, that keeps the stakeholders happy, that keeps them on board for that journey because you're not going to keep them all happy all the time. You've got to keep the right people happy at the right time and eventually get to everyone at one point.

Speaker B: Experience Tamer's proven data centric AI engineered to speed the discovery, enrichment and maintenance of the golden records businesses need to accelerate growth. Tamer's expertise in quickly and accurately unifying large amounts of data across disparate sources gets results faster at a lower cost compared to traditional master data management or DIY solutions. Stop wasting time on bad data. Visit www.tamer.com that's TamR M.com to see results. Now

Speaker C: one of the big ideas that I took away from the Gartner show last week In Orlando, one of the Gartner analysts made this point that every data project should start by the team that's working on it, uh, reading their annual report. What would that have anything to do with this? But his point, and it speaks exactly to what you're talking about, is if you don't understand the business objectives of the business, then whatever technology, whatever data project you're working on is likely to be a, a technology project and uh, not a business project.

Speaker A: Spot on. In fact, I've done that whenever, whenever going and pitching for a data strategy piece about the first place I go is to their, their last board report or their, anything, any publicly, publicly specified. I've actually built that into our knowledge platform internally that we actually have all that research done, um, on a company before even talking to them, before I'm talking to them, I've already had the background of what's going on with them, so have all the context needed when I have the conversation.

Speaker C: And then I also really love this idea of friction. I think that is a really unique insight. And just to play it back to you, I think one idea there that's really important is there almost certainly lots of pain points inside an organization, lots of points of friction. Uh, but friction in something that's not actually moving very quickly. To your point, something that happens every three months, even if it's very painful, every three months, it's only every three months. Whereas something that's happening six times a day, even if it's not that much friction, but there's a huge, like, not to overuse the analogy, but like there'd be a huge heat buildup in that because it's just. Yeah, yeah.

Speaker A: So you either have to chuck more oil on antigens, which is more people to try and like smooth the process, or you reduce that friction. You know, you, you put something in there that solves the problem.

Speaker C: So in your view are these. I like this idea of the force multiplier, but I'm, I'm curious, is that something that's typically human led, meaning the force multiplier is people or is the force multiplier technology?

Speaker A: Do you know what I think it could be? It could be any of them. I think the, the force multiplier. So say for example, it give the people bells, people room. It could be the fact that at the moment you've got three people doing this particular activity as a part time job and the value that they have doing other things is more valuable just putting one person that does that thing, that's dedicated to that, that Serves those other three, you've just solved it as a people. So it could be as simple, as simple as that. It just be more efficiency with the staff you've got or better structure of your teams. Next one it could be the deployment framework. Okay, so basically normally you've got someone that goes and runs a script here it does that and someone else does the testing. So now you've got them built an end to end testing framework that runs it sends them a slack message with the result saying done. You've put it on two things. One, you save them some time, but you've also built more trust in the process because there's less likely for it to fail. So and you solve that process for that one department, you've now got a force multiplier that is every other department that's doing this can now benefit from that. You solved it for once you got more benefit. And I think the, the business process one is okay, so for example, you've got mass of data scattered all over the place and now you've did your head but your bag here is a bit. And that was, yeah, I was unintentional. But having that now centralized in one particular place means that the information is more accurate. You're not paying for multiple systems that actually were doing this at first play and you've got it in a more timely manner. So it has become a for how you'd identify that is by your process of doing this analysis of looking for, you know, areas of friction, you would have identified that these three departments are all using a separate One's got Salesforce, one's got HubSpot. At some point maybe you would, would go and centralize into one serum, maybe not. So maybe there's an opportunity to go, okay, right, I can't get rid of all you, but for now I'm going to master this in one location. That is the golden source. Anyone needs to go and get the latest thing for that. Everything feeds off everything, everything feeds via that hub now. And now you know, you've got to solve that for your billing department, your finance and your marketing department that are now, you know, not sending marketing material out of people haven't paid their bills. You know, there's no point trying to market stuff that people can't buy it in the first place.

Speaker C: So, but that, so I think you're. That's a good transition to context layers which again if there was a third theme that came out of the Gardner show, it was this, the buzzword context layer which you know, we'll Give you credit, you've been talking about for some time. Uh, I don't know if you can quite claim to have invented it, but you should claim to have been.

Speaker A: I m will claim I did a bit of perplexity research to find out who was the first person that talked about it. And it's keeping me happy. But it couldn't find other people talking about it before, before that. But I'll tell you where it originally, where, where I originally coined it and why I coined it. And it wasn't to invent a buzzword. And it's linked to like uh, the good old days of bi. And you know, we had in cognos you had a catalog in business object, you had a universe. They were a semantic layer and it was bundled a uh, bundled semantic layer with a BI problem. I didn't know it was a semantic layer then. All I knew was a catalog. I was describing my data and I just did it back then. But it's interesting to see how you know, evolution now and where we uh, are. We were talking about these things again and there would, there was something semantic 2.0 and then they would do a whole list of all of these things that I'd say context related. It was all ontologies, it was all about knowledge graphs, vector databases. It went semantic layers and semantic 2.0. And so, and I was, and there was people arguing. Oh, you know, I said look, it's what, what are they all providing? They're providing context collectively. They, they are a context layer. And back to that blueprint or our reference architecture. Uh, and I can. Now I know how long it's been there because I haven't, haven't updated it for over a year now. Well, I haven't updated that part for over a year. And I have this thing called a context layer. And again that was the purpose of that was to describe to the business what capabilities. Uh, it wasn't a product, it wasn't a solution, it was a concept. And it was to try and say that all these things you're hearing about, they are part of the jigsaw puzzle of providing you the context is needed for your use cases, but you don't need all of them at once. And you don't need, probably don't need them all, you probably won't need all of them at all. And it's working out what you need at the right time. And then I think I put in there something called context management. And I've done this in my prompt, my prompt engine, I have. So my Prompts are stored afterwards to run, but they also store the context that they've been given as well. And it gives feedback if that context isn't or if it believes the context is the reason for the bad result for the prompt. So the hierarchical it will go around, it'll tune itself to go and say what additional context would I needed not to have performed? So you need to manage context. Context will mean different things to different people. And also context has got a lifespan as well. So people really need to unpack um, what they actually need for context for them. And if context just is you've now stored all your additional metadata on your DDL with comments or tags or with foreign key, primary key constraints or naming conventions. You built context into that by design, then you're able to know, uh, you can read that and actually extract knowledge from that context and it will always be kept up to date. So you don't need to go and have another calendar again. If your business processes, you're capturing that and you've got some naming convention you put that into and those business processes are linked to your data model that you may have somewhere that is also you've actually just created all that metadata already. Let's provide new contact. You don't need to buy a product, you don't need anything else. You need to put that somewhere and actually be able to use, use that and stick an homage at it, uh, agents. It'll work out what it can do with all of that context. You provide it. And then you just need to make sure that that is available to the purpose you've got. And you know, it could be a prompt, you know, you want to make sure you're giving the right context to the prompt that's been given. It could be to. We're talking about, you know, the prompt box. We're doing reporting now. You need to make sure the example I gave earlier. So we've just done a migration, right. By the way in the history of activities that have gone on recently or you know, there was an outage on this in this region at that time. Those, those things that if you just get, you know that's going to be useful for someone doing reporting, just getting that sent somewhere that you know that when you've got your analysis being performed, it's also have access to that additional context. You're just providing additional value and also providing additional trust in that data. Because m as soon as they see something wrong, oh, I know why it's wrong or it knows why it's wrong.

Speaker C: So I Think, uh, one thing, I just want to go back a little bit. You made this point that this is something that we've as an industry we've had for a long time. And in that sense I think in our consumer lives we're quite comfortable with it. We often talk about, you know, what Google has is a lot of context. And I think a lot of what Google was trying to do in making Search better was learn or figure out the context. Sometimes it can get creepy in our personal world. But leaving that aside for a moment, would it be fair to say that we could learn a lot from the way our experience with consumer software informs the way we need to make these enterprise systems successful? Especially in the context of. Context?

Speaker A: Yeah, I think I'm going to answer this, but something else we talk about recently is a system of record and you've seen recently Salesforce price crash, um, HubSpot crash. And that was. And something I've seen as well that was based on behavior of the businesses now. Whereas before that system of record was the go to place that they drove everything from. Now it's not. So they were taking that information out of there and then performing that analysis outside of Salesforce, which meant maybe the number of the licenses they needed before weren't as high because people could go and self serve on this data doing. I know that Sigma doing this, an app on top of that. You can't take that data real time but you can take it batch. So that's sort of like I think a shift now from um, where we were before of the system of records being the big golden pillars of an organization system. And you may have seen that Salesforce has recently changed their licensing agreement that you cannot train AI. Well, I don't know how they're implementing it, but you can't train your models on your data in their platform. So maybe I think you can take it out and saying it, but it, but that just shows that they realize that context is, is, you know, where the, where the money is. And if they, if they lose that context and it's being taken outside the platform, they're losing their value. Yeah. So I don't know if I'm. Yeah. So did I answer your question?

Speaker C: No. Yes, exactly. And I think the, this goes to a theory I've had for many years which is that what happens in enterprise software is what happened in consumer software five years ago. And to your point about the operational systems where I think a lot of organizations saw value in these operational systems, they're increasingly seeing value in the linkages between these operational systems and not so much in the. And I'll say this in a funny way. There used to be this idea that eventually all the data will end up in whatever SAP salesforce, whatever the system your choice of systems is. And I think there's this increasing realization that that's never going to happen. They're just not going to end up in one place.

Speaker A: Yeah. Which is, I think, where this system of context, as I coined it. Gartner will talk about this next year. All right. And you can, you can say you heard it here first, but yeah, the system of context is stringing together all of those different parts of your organization and it's much easier to bring it all together now, which it's always been there, but it's been very, very difficult to do. Before it was data platforms were downstream. It was never seen to be, uh, uh, an operational thing. And I think now that's shifted. And if your data platform is from your operational or provides an operational and all the systems of record are feeding into it, your system of context sits on top of it because it understands everything, because everything's going into it. And I think it's the sum of all of the parts are worth more than the individual pieces. And I think the data world has got that now, whereas the salesforce is. They're all trying to get it into their platform.

Speaker C: Which brings us sort of back to where we started, which is the value is no longer in this very specific bespoke user interface dashboard or for that matter and CRM system, but in, in fact in the data behind it. And then in fact the context that that data provides, whether it provides it to humans or AI systems.

Speaker A: I coined something else a few years ago which is meta metadata. Data about the data, about the data is where, where the value is now. And, and that links into. That's providing additional context. So yeah, I think people tried to do this years ago. You know, you take the ETL method, take. You take your database method. It was difficult and it's not now. You go and stick some agents on top of that. It can work it out quite quickly and you can get some really valuable insight from it. M. We're doing that not ah, revealing everything, but that's something else we're doing elsewhere.

Speaker C: Well look, I think uh, we've covered a lot of ground both between the transformation in the data space away from how we visualize data to the actual data itself to how we can use a different concept than roi. But think about. I love this idea of friction as a motivating factor and really introducing this idea of the context layer, which arguably is where we're going as an industry. So, uh, Chris, thank you so much for the time.

Speaker A: No, no, thank you for listening. I've got a lot to talk about this stuff. So

Speaker B: thanks for joining us for the latest episode of the Data Masters podcast. You're find links in the show notes to any resources mentioned on today's show, and if you're enjoying our podcast, please subscribe so you never miss an episode.