SELECT video_content FROM LIBRARY WHERE SLUG='009-break-free-of-the-service-trap-the-4-keys-to-being-a-valuable-effective-data-team'
009: Break Free of the Service Trap: The 4 Keys to Being a Valuable, Effective Data Team
Loading video player...
Hey, everyone. Welcome to more than numbers, a live show focused on turning data teams from support functions into engines of growth. My name is Nico Yoke. I am the host of the Analytics on Fire podcast. But today, I am taking over more than numbers show and interviewing your host, Ollie Hughes. So just for some context, if you're not familiar with Count, Count is a Canvas based BI tool that breaks data teams away from just building dashboards and turns them into organizations problem solvers. As I stated, this is a data takeover. Okay? I'm interviewing the Ollie Hughes. Ollie, how are you? It's very weird having you repeat that intro. Thank you for doing this. That's very good. I did my best. I know everybody saw a customer seeing you, but, hey, I gave it a good shot. You did a really good job. Did a really good job. Don't do it too well. Right? Don't do it too well. No. You do a great job. Okay, guys. So today's a very exciting show because what we're gonna talk about today is I know if you guys have been following more than numbers live, you've seen all the interview an amazing guest. Right? And if you haven't checked it out, I was a guest. Thank you. But he also has had leaders from Monzo, from Bumble. Like, go back and check out MTN dot co's. Wait. No. I may get it wrong. Don't quote me. Count dot co slash MTN. I will put the link in the comments. There we go. Thank you. Be sure to go back and check it out, but don't leave us yet. We have an exciting show today that is really gonna be focused around the tenets of count. So I wanna jump into what that is, Oli. But before we get started, for people who don't know you, because there's always new people watching the show, Oli is not just my birthday twin, but he is an amazing founder, guys. And I've worked with a lot of founders in the data data space, and he's very passionate. So this show is a little bit different because as opposed to him talking to data leaders, his passion about these tenants are gonna come out, and I'm just honored to interview. So, Oli, let's put you on the spot and start with a question that you always ask. What was your first BI tool? My first BI tool, thank you, Mika, firstly for doing this for for me. It's really great to have you here and be in the hot seat for once. Good good good humility for me to be here as a guest. The first BI tool so interesting story. Obviously Not Excel. Not Excel. Obviously not. Mhmm. No. I so my first, like, proper data tool that I use a lot was actually in Tesco. If you don't know Tesco, it's one of Europe's largest retailers. And they had, back in the time, like, their own on prem Teradata data warehouse, like, properly, like, servers sitting there, in head office, like, wearing away old school. And so, actually, my first tool I love was just interrogating that database. It was pretty cool. I just had so much stuff like Tesco. Any retailer generally has amazing dataset because you've got, like, human behavior, matched operations. It's a really fun day to set the table. So that was definitely the place where I fell in love with data most. Did a lot of cool projects there. Tesco's a great data led organization. Then the the story really about BI, like, properly a kind of a a dashboarding tool. This is gonna I don't I don't like slamming other tools particularly, but I after Tesco, I I end up doing consulting, working with clients with Power BI. And Power BI just Oh. Now just come had just come out, and I was like, I'm playing around with it. And I real then I It's rough. I did walk into DAX, and I was like, DAX, what what is this language, which is sort of like some sort of bastardized version of an Excel formula, makes no sense, horrible to learn, this cannot be the future, how can this be in the newest BI tool on the on the market and done by Microsoft, which is obviously a pretty good product organization. I was like, this is gone, and this is going the wrong way. And that was kind of one of the things that kicked off. Holly and I, my cofounder, thinking about count. I'm trying to find a different answer. It was like, thank you, Power BI, for giving me the, impetus to be to believe I could find something better to build. So there you go. That's the bad story. And, you know, I was a Power BI MVP for a number of years, so I'm a little bit biased. I will say that that was before they were I think he used it before they had fully been acquired by maybe Microsoft because Microsoft did acquire them. People don't know that. Okay. And so, yeah, they weren't acquired A lot of people don't realize that because Microsoft just did like, the branding, obviously, is all Microsoft, and I think Microsoft has done a lot of work since then. So while it's not a perfect tool, I was just telling someone in LinkedIn the other day. You you back out of it, but you are you and I both know what I'm not saying is true. But you you play that for me. I'm just saying it's the iPad of the eye. Okay? It's basically pick it up. Anybody with any knowledge or no knowledge can use it, and I think that was the point. Whether or not it is the and the default, there's yeah. That's a different conversation. Okay. So let me just go ahead and take my Power BI plaque. I remind remember that I used to be a MVP. Let's move on from that. Okay. So Power BI. Okay. Ollie, so let's get into this. So I mentioned about the count tenants, and you basically baptized me in these when I used to work for count. Okay? And I was sold. So what I'm hoping to do is have you basically kinda explain why you feel so passionate today about data teams being support functions, essentially, and them needing to instead be, I believe you said, growth engines for the business, right, for the for the right? So let's just foundation. Like, what is the problem that you're trying to solve, and why is it important? Thank you. I mean, yeah, I can talk about this for a long time, so you're gonna ring me in if I go too far. But in general, I just think that as a as an industry, we're we're at a really, really critical moment. Right? We're we're now at a point where we've gone past the the zero interest world where capital was free and data teams could spend, spend, spend. And we're now in a point where Yeah. Data teams for many reasons, one is they just need to prove their ROI with the money they have. There's not infinite budgets. But also now with the with the AI revolution, which is gonna come and make a big impact, there's just this need for data teams to step up their game and just become much more valuable in the way they work. And instead, what I see is data teams struggling in this kind of service trap, this support function mode where they wanna drive more value. They wanna be more at the core of driving the business forwards, but instead they're stuck being this kind of dashboard factory, and they're trying to break out of that. And it is a thing I wanna fix. Things like we not everyone's in data not to become a dashboard builder, but to be to solve problems. That's the general core principle. Every single person I've spoken to in data over a decade wants to solve problems, and instead they're building building charts and dashboards. And it's how do you break out of that trap? What can we do as an industry to to move that forward? And that's where the highlight of the tenants came from. It's like, well, actually, what's the value framework, which is not about how to be not makes it not transactional, but instead makes it a ambitious vision for what their team should be doing and focusing on, and actually is the is the levers of value for them. That's the whole idea of this project. That's what I've been passionate about with the tenants. And I completely agree, and it's so funny why you're saying that even though we didn't plan this. You if you go on LinkedIn right now, you could type in dash for developer. There's hundreds, if not thousands of roles. Right? And what you don't see some a lot of times in those roles if you scope them only is you don't see problem solving. Right? You see analyst. You see all this stuff. So I like the fact that you are kinda distinguishing the fact that, like, the industry is calling for someone to be like and we used to call it chart monkeys, just build their bill. You are focusing on what we actually are supposed to be doing. I was an analyst myself and data scientist, which is solving problems. Okay. So I wanna dig a little bit deeper. Let's peel the onion a little bit more. So in terms of, like, in terms of, like, this pivotal time, and I agree with you, like, in this Jennie I age. Right? A lot of people are like, am I gonna be replaced? Why is this moment so pivotal? What are the issues that data teams are facing that they need to start to address or be replaced? Well, that's it. It's the there's this there's two big waves here. One is there is now less mess budget, reserves over. We need to make more get more value for what we have, and data teams need to react to that and become more there's more pressure to become more impactful. And the second thing is if we if we stay transactional and stay as a kind of support function just providing the data the business, which wishes for without without any other value driver, that is a that is a function which will be replaced by a machine. Like, I just believe that's the case. I think I agree. There is a there's a much higher value operating model that a team can move to, which is far more driven to value, far more, has a higher level of value attached to it than just the one who can write SQL and build a bar chart, which we can get data teams to. And they need to get there because otherwise they will be mis replaced by machine. And it's also results. I'm not it's also, as I said, no one finds satisfaction in being a chart builder. It's about the problem solved, and let's get people there. Now is the time to make that shift is basically the principle. And I'm I'm agree sorry. Go ahead. No. Yeah. I just I think in general, my vision of this is, like, that big vision is that BI is no longer about just getting data into the business. There's enough data there already. BI used to be about just get data into the business to drive value. That kind of was generation one. We've been through that age. Now it's about my view is BI should be about business improvement. Like, the goal of a data team now is to drive business improvement, and BI should stand for business improvement. We need to make the business better. We no longer just serve the data to the business, and that's it. That that is now that is the thing that needs to become a commodity. I think you can see the market actually, you know, making it a commodity. AI is gonna make it a commodity. So data teams need to shift to becoming, like, the drivers, the facilitators of business improvement, and that's the role I believe we can move to. I'm I'm seeing our customers move to. And I love that because the two things I'm hearing is transformation to problem solvers and focus on business improvement versus support function. And I think if you put those two together, which you're gonna tell us, shortly in the show, that is where we get that transformation. Now I wanted to jump in a little bit deeper because if I'm listening to this, let's peel it on you one more time, and I'm a data leader, data team. You know, I'm sitting down thinking, well, Oli, how do I know if I'm a support function? Right? It's not just about am I billable, am I not? So I know that you have an amazing kind of, like, service trap. Can we get that slide up? An amazing serve it, like, four symptoms of a service web to see if your data team is a service trap or not. Could you kind of expand on this? Because I just thought, you know, this just gets to the heart of it. It's either a yes or a no. Yep. I think so let's walk through the different service trap the just the different service traps and then how you can know if you're in that trap. These four things are actually they all are linked. So we can talk about that kind of what we call the vicious cycle. But in general, there's four of them. Right? So the first one, if you you know you're in a service trap if you are drowning the business with information. If the business is drowning with the amount of dashboards and assets and data that's available to them, and they can't see wood from the trees. And the symptom there and a way to diagnose this is look at your kind of dashboard to employee ratio. Like, how how many dashboard dial there in the business, and how many employees do you have? That's so good. And is that if that ratio is anywhere close to one, or if I if it's not even, like, one to ten, then you've got every employee with a different version of the truth pulling in different directions that's causing confusion. That is a that is an outcome of being in a service trap where you're just pumping information into the business. That's that's one of the that's one of the service traps. The second one is Wait. Yeah. Before you move on to that service trap, Ollie, I can hear someone in the audience saying, but I have my Jira request for it or whatever, and I'm getting these requests over and over again. What am I supposed to do? We'll come to that. I I have to briefly solution, but I I hear it echoing in the audience. Yeah. Yeah. Yeah. Yeah. You're gonna hear it, and we'll get to that. There is a solution to that problem, and it's and it's actually about breaking the cycle. But and we'll come and that's the vicious cycle of, like, the more they ask, the more information they get, the more overwhelmed they are. You need to solve that problem. How do you make the business feel simple, not feel drowned in information, A different version of the group. So we'll dig into that more. And that links the second the second service trap, which is answering with every question the business has. So there's a real subtlety here, which is the business is under is hung often, you know, wonderfully hungry for data. They know the power of it, and they keep wanting to get more data to answer more questions. The problem is if you are their if if you are their quick fix, if you give them the information they're asking for, you are commoditizing your value by just giving the numbers they're asking for, and you're just a c call interpreter rather than being the the problem solver for them. And that that's a big problem too. Right? So if you're overwhelmed with ad hoc requests, there's a drug with businesses on here which is getting it costs you a lot to give and needs to be much more discerning than that just to give information away. And so that that's the second trap, which is often linked to the first one, which is if they're asking for information, you're giving it to them. There's a vicious cycle of, like, building more more confusion. Therefore, they want more requests to understand what's going on, and that's a vicious cycle of just building, building, answering, building, and answering. And it doesn't get any better, and we call it the vicious cycle. That's what you're trying to break. That's a really important point. It used to be known as the data treadmill. The data requirement treadmill. Exactly. Yeah. It used to be the data requirement treadmill. Yeah. Okay. Continue. So that those two are really linked together. And then this Yes. When things get tough, there's a real temptation for the data team to sort of retreat back behind and, like, draw the pull pull the drawbridge up of the castle and just protect themselves, and that leads to other big problems. So that's the third service trap is the idea of, like, minimizing time with stakeholders. Like, the idea of, let's put our our process. Let's get the ticketing window up so we we can retreat away. There's a interface to deal with us. You don't really know what's going on. But also we didn't Yeah. Business doing either. And then that makes things even worse because then the data team is not as well in forward up business priorities. They're not in the business context. You and you're just being you're even more like a black box where you can put a number in, machine gives an answer back. And that makes it even more a o like an AI bot in the in the way you're working. So that's the third trap is the midwife type of way. Just to insert there, it's it's it's it's prep disguised as protection, isn't it? Right? So you it it's protection disguised as prep. So you're claiming that, oh, I wanted to become prepared when you what you're really doing is a CYA. Right? Yeah. You're kind of creating this distance. Yeah. Yeah. Exactly. Creating distance and that with with understandable need to protect yourself from, like, just all the bomb bomb of requests and being treated like a machine. But in reality, you're not actually leaning in to be more valuable to the business and better to serve what really matters. And that that's another another failure mode you can fall into. It's hard, again, hard to get out of if you want to Fission cycle. Yeah. Fission cycle. Yes. And then the other temptation again, which falls out of this feeling that, like, the business doesn't really value us is to start to optimize things that don't really matter the business. The number of times that I've seen data teams who spend more than half their time just maintaining operational reporting or maintaining data quality because they can control that stuff, and they will make it even better. Or they wanna over optimize query performance because they know that that's gonna drive that they control it. They can justify saving or efficiency, but the business doesn't care, doesn't see that work, doesn't even, you know, know it's not happening. Yep. Comfort zone. This is it's called data comfort food. Data comfort food. Exactly. So this is the natural response. As you're feeding the business more information, it's getting confused. There's more demand on you to clarify. That's a vicious cycle of of the data or you call it treadmill. I love that phrase. But then you've also got this other temptation to just retreat back and do the things that you could control, like server costs or optimizing queries or just, like, putting up a kind of a a booth that they can come to, which they can their ticketing system to get to you, which is exactly how as a machine would look. And and that this is the trap that you can fall into, and this is when the business doesn't value you. You become commoditized. That's the we gotta break out of that mode. And that's the default mode actually of a data team, and this is working different way. Okay. That's the way these tools our BI tools are set up to support, which is why it's a problem. Question for you. So you presented four service traps, which I think is great because these are symptoms that I'm sure people in the audience are going, I'm either one or four of these. How many of these do you have to check a box for to realize that you are literally just a a I don't wanna say use a support function, but you are a you are caught in these service straps. Is it two of four? Like, how many? Is it one of four means your head now on the trail? How many? How many symptoms? I think one. I think if you have one of these problems, you if you have one of these problems, if you don't dress it, you can fall in. You it exacerbates the rest. Right? That that's the challenge. So let's go through these are the four traps. Let's go to the right each other what the four symptoms are to realize this. So you if you'll have a dashboard to employee ratio close to one or or wait, you know, just way or way too many data data assets out there, then you're drowning the business with with information that risks causing, the the the treadmill to kick off. If you're spending a little time Pause there. So to visualize this, if I'm Microsoft or I'm a big company like ServiceNow, I have fifty thousand employees. You're saying if I have fifty thousand plus report I was wanna we need to drop pictures, quantify it. Fifty thousand plus reports of dashboard assets, something's wrong. That's what you're saying. Or even approaching that many. If you've got thousands of reports out there, then you're there's a lot of information out there saying different things in different ways, and that's causing Yeah. Yeah. You said ten to one. So five thousand or more. Okay. Just wanna quantify. Move on to number two. So number two is obviously then the you know, if your if your biz if you as a team just feel overwhelmed with ad hoc request left, right, and center, that is a symptom of you being a answer machine for the company rather than being a kind of something much more valuable to them that you're just you're commoditized answer answer machine. We'll come up to the solution what that looks like instead, but that is another, you know, a symptom that you can feel of being in a support in a in a service trap. So, again, that's that's a key thing to think about. Am I just over am I just feeling overwhelmed with this, like, this treadmill of adult adult request coming to me? The And I wanna add here, this one here sorry. I'm just inserting because we need to drop pictures. This insert in here, in my opinion, Ollie, and keep me honest, is Gen AI can answer questions faster than you. Right? So the reality of this one is that this is a race that you're gonna lose. So race you're gonna lose. AI can be a solution that you're wrong. There's obviously part of this is how to enable self-service, but in in in it's, as we know as anyone will know who's been data well for a long time, there's there's a there's a a graveyard of self-service initiatives, and you never get the perfect self-service. You're always gonna be asked for more information as a data team. It's just whether that information is valuable or not. We and we'll come to that in a bit more detail. You need to make sure that you have a way to not just answer questions, but actually lean into the problems which matter most and prioritize your effort there. That that's obviously Agreed. That's the thing which is probably least surprising for our audience to hear. It's just how you get there. Right? Yep. And then so then the third symptom, like, if you're spending, most of your time on on supporting data quality, if your if your team as a whole is spending more than forty percent of its time, like, maintaining operational reports and dashboards or fixing data quality issues, that is too much time spent on this on things which aren't aren't, you're spending too much time away from stakeholders, basically. You're not working on things that matter most. So that's really important. Right? Too. Okay. That makes a lot of sense. And then you have the last one. Oh, and can I ask a question there? When we were doing the prep, you mentioned an acid test that I thought was so good. Right? You said, you know, can your exec name three things that the data teams have to drive business value in that last quarter? And if I'm correct, you said if they cannot answer you, can you expand on that? Because I just thought, like, to drive this in. That is such a good asset test. I agreed. That and that so this is what it all comes down to. Ultimately, the minimum bar that I've people often ask me last week, someone asked me this question, like, what's the way to measure ROI? And it's a hard question. We all want to have a number for it, but it's a hard one. And I said that it's a kind of one of those paradoxes that the data teams who are driving value are never asked to prove their ROI. It's just it's just that it's so obvious that they're needed, and they're so obviously driving value. They don't need to put a number to it. The teams who are being asked that question are the ones in trouble. And I said the minimum bar that you should be aspiring to is the data team as a minimum is that every quarter, your executive team can point clearly point to three things that the data team has done for the organization, which has driven business value. And it could be indirectly driven it or absolutely let it from the front. But that they know that you're there and that you they know that you've been contributing towards three key outcomes that matter. And that should be the bar the bare minimum of the data team should be doing. And if you're not doing that, if you can't point to that, then you need to make sure that's more visible. You need to be working, on things that all yeah. The organization can see. And that and that's the key thing is that the business values you, and they understand what you're doing. And then you're not seen as a commoditized support function. That's the minimum bar in my mind. I think the golden nugget there, Ollie, thank you for that, is that, to me, that's the data team NPR. True. Right? Yeah. Yeah. Yeah. Yeah. That's yeah. That's what it is. Very simple people ask you. You just say you know, NPR, for those who don't know that, the sales metric of, like, would you recommend my business? Right? There's a whole history behind that question. To me, this what you're suggesting is the data team NPR. If an exec or two can't answer this question, you don't need to ask any other questions. And if you if you wanna go back and learn more about that, like, Lina from Bumble did an amazing job of giving us a way to do that kind of survey to get some of that. Yeah. But the key is that it's not just that someone in, you know, in marketing values you, but that's a very important score, but actually does the exec team is the people who make the decisions understand the value of data. That's where you gotta make sure you're delivering to. So there's a whole there's a whole company wide spectrum there. Yeah. And you can just so you know, you guys can go again to count dot co slash m t n. All of the shows are there. If you type in Lina, if you go in the show notes on the bottom, yes. Thank you. You'll be able to see that download. I recommend it. I think it's a stakeholder survey. It it's, you know, it's plug and play. You can implement what Oli is seeing right now, get your asset test done, and figure out what's going on. Okay. So we've talked a lot about the problem, and we've talked a lot about the vicious cycle. I I think it's safe to say that MTN is clear now. So let's now get into my favorite part, which is the solution. Because to be honest, these four tenants and as somewhat like, these are what got me hooked with count. Right? Like, this way of thinking. It's a way of working and thinking. Right? It's not just a tool. It's not just a so let's talk a little bit now about the count tenants, which, if I'm correct, it directly one to one addresses each of the service shops. Is that correct? That's right. Yeah. Yeah. We I mean, we've built business around this. We have interviewed hundreds of data leaders. We've worked about the one worked through the ones which are really driving impact on the ones that never get asked their ROI. What are they doing? And then and and then looking at what their what their principles of the way they work. Can't we built the count platform to make sure that that is the way that any data teams work using count? And And it but it's a it's a framework of value which applies to any data team. You can use it you can start tomorrow. It's not just about one tool. It's about a way of working and a principle. And these are what I'm excited by, what I wish is that I if you go into an organization and you ask, you know, what does marketing do? Everyone knows what marketing does. Everyone knows the value that marketing brings. When you go into an organization and ask what the data team does, you get every company has a different answer to that question. As an industry, we need a we need to have a definition of what data team's role is, which is clear and is understood by the rest of the business, the rest of the industry. And we don't have that. We have, like, a very loose definition. So one of the many goals I have of these tenants is that I wish they are if nothing else, they're just adopted by the as by the data industry as a way to understand what the data team's value is. And I've it's been wonderful to see so many day leaders and data teams taking these tenants and running them with them on their strategy away days or building their annual strategy around these tenants, regardless if they can or not. Because they did just they're just fundamental value drivers. They're principles. They're they're things that are, principles you can keep working on them and getting better and better at, and that's what I love about them. They're they're kind of tried and tested. We know they work. Yes. You know, they're good they're good value principles. If you ever start, you go back to them. You can never end on these journeys. There's never a dumb thing. They're always true. Anyway Yeah. I think yes. Thank you for, thank you for bringing it up. And I think the thing that's important before we dive into these here, is that people need to understand that when we talk about for those who are familiar with jobs to be done and deep work. Right? Those are two phrases in the data data industry that become. To me, these are the actual jobs to be done and the deep work, and I see count the count canvas as a tool that enables you to do that. Other BI tools do not. So I just wanna make that reference because I know that people in our data world understand it. Do you agree with that? I I do. I mean, we as I said, I think BI tools and BI tools, I mean, like, dashboard focused tools with the paradigm is the ones that, you know we've had the big BI tools around for decades. And even now, the newest BI tools adopt the fundamentally similar paradigm towards The Three Stooges. The Three Stooges. But even the newer tools adopt the Three Stooges. They just have slightly different different flavors of the Three Stooges. And they're built to enable the operating model of the service traps. They're built I agree. That way. I agree. Yes. Now you can use count as a boring BI tool. You can build dashboards and count. I agree. That is fine. But the key is that it unlocks a different way of working, that it unlocks a value in elevating above just the transactional dashboard factory way of working that exists today. And that's what really excites us is we love doing and what we spent so many years trying to get right. Yep. And as someone coming from that world, I absolutely am aligned with that. Like I said, this count enables the deep work. Right? These to me are the real jobs to be done. And the reality is that if you fix these, you'll never have to answer the question, what is what are you guys doing? Like, what are we paying money for? Right? So okay. Time is not our friend. Let's jump right into it. So let's talk quickly about the four tenets of high impact teams, and let's make sure that we kind of address those one to one issues that you had before so that the people so we're solutioning right now. Cool. Yeah. Love it. Well, let me let me start with the first one, which is is an unlocked to the rest of it, actually. It's often the place where we see a lot of, customers or just data teams getting into this mode, focusing on, and it's called, like it's seeking operational clarity. Now what is operational clarity? So opposed to the idea of drowning the business with information, just giving out assets and building dashboards willy nilly, the goal of a data team should be to create the maximum amount of clarity for the organization with a minimum amount of information possible. But you're creating what I would say from an engineering background is like the signal to noise ratio is incredibly high. So Yep. You know, we're in a world now where every single piece of software, every single tool that anyone in the business has gives you numbers and metrics and data. We're not we're not lacking data anymore. We're lacking clarity about what's really going on. So data team's purpose is now to clarify and simplify the operating model of business. They should they're the ones making it clear what the business is doing, how it's performing, how the business fits together, painting the operating model of the business, not just painting the data or owning the numbers. And that's a crucial role, which makes everything else easier. You're making the business feel simple. I would say it's almost like data teams need a COO, but we're out of time, so continue. No. No. That that's it's that simple. I mean, so an example of that could be, you know, your data team should be producing things like metric trees or making process flow maps and match attached to it. That's what we see a lot of our customers doing. Just to position and contextualize the metrics that matter and painting the story of the business, make the make visualizing the business, not just visualizing the data itself. And that's the big leap forward. Is that kind of like, we are gonna make the business, paint the business and how the business fits together, not just how the numbers, what the numbers are. And, yeah, it's it's amazing. It sounds so simple. Like, it sounds so obvious, but you can never make the business feel clear enough. Like, you can always make it simpler. And it's amazing the stories we know of, like I mean, there's been so many examples of this I can't tell you, but, like, we saw one customer who, they're they were doing a POC with us, and they built in a, you know, a few days, built a metric tree of their they're fast growing SaaS company. Right? Fast growing SaaS company. Mhmm. And their junior analyst built a metric tree, a very, very basic metric tree of the core metrics of the business, put them into a tree so you could see the hierarchy of the different parts of the business, brought to the company all hands with three hundred with, you know, two hundred and fifty, I think it was, employees, presented it, and there was just silence as people were like, oh. Oh, yeah. That's that's what our business looks like. That's what's going on. And it that's a trivial example, but it's just so powerful. If the data team is the one bringing that signal, that kind of clarity about what's happening, what matters, that's just gonna help everyone at every level to understand their role and understand what really what's really important. Yeah. And I know we're short on time, but I just wanna show quickly. Can you bring the metric can we bring up the metrics to you on the screen? I just it's one of my favorite canvases. I'm a little bit biased here. I'm a visual, like, dashboard. I love dashboard. Can we bring that up? Find it up. Yeah. Yeah. Let's go to that. I have it. I have it. So this is you know you know I'm known for, like, the data dictionary, which was first a KPI blueprint. So I love metrics. I know it's weird. It's kinky. I love metrics. And so when I first saw this, Oli, on there, what I love about it is that, you know, typically, we have a metric sheet. It's just words. Even my own, right, is really just words. Here, you have not just the context, but you have the charts to go with it. Right? So it's like a the usual metric tree. And this is a template that you can download. Right? Totally. And just to clarify, this is the this is the build environment. So this is the place that analysts can build it out. It's not necessarily the way you report. This has got the code, the definitions, and there's a bit of SQL in here. But if you you can absolutely make this into a report that you can send on your whole company, which shows just metrics in context and shows that tree in in in really, really clearly. So we're looking here from, like, the analyst perspective, and that's another whole powerful environment. But, yeah, a hundred percent, it's a it's a very, it's a great way to do it. Now I also wanna say, people who, you know you know, can't buy account today, you can absolutely drive operational clarity with the dashboard tool. It's just about how you do that is trickier and harder, but you can absolutely do things to improve clarity and signal. Most of that could be just clearing out all the old conflicting assets that don't are just driving confusion and get to the minimum number of reports you can, which lets the business operate. Like, that's the key idea is minimize the amount of places you've gotta go to understand business performance. And that is possible. Other tools, it's harder, but it's definitely possible. That's why the principles are, you know, are universally acceptable, and you could adopt them today. Okay. And we're a little bit over time, but it's important that we get through the next three. So can you I think I think an operational clarity, just to be clear, the reason you spent so much time on that is that my understanding is that if you fix that, a lot of the rest of it is kinda what trickle down. Right? It's kinda like the snowball effect. Right? The vertical cycle rather than the vicious cycle of pumping data and data and assets in business to confuse them. The more you pump in clarity, which means less, like, less assets, basically, the better the questions, the better informed the business is, and the better they're they're using you to ask questions. So a key idea here is back to the second tenet of solving business problems, is a large number of the ad hoc request the data team receive is not actually about solving problems. It's about understanding what's going on. So instantly, you give clarity. You're dropping the number of the price you're getting, and you're getting a higher higher proportion of I wanna solve this problem. Help me, please. I agree. And that's where the data team can then drive value. So the second tenant, solving business problems, as I said, this is probably not a surprising tenant to many, data people. They wanna solve business problems. They wanna get stuck in there. The big lift is understanding that the better you're clear of operational with clarity perspective, the easier this is to be there is this is to do. And the second big leap is to recognize that either data team can do more to own the problem solve. Right? So rather than just, answering questions the business asks of you, where the the problem solve structuring is in some some stakeholder's head and you can't see it, and they're not necessarily clear because you've got a million things to do, the more the data team can take ownership of the problem, structure it for the business, help them understand it again, clarity again, and then get to an answer and to facilitate the problem solving, the structuring of that problem, not just be the that they ask without much without understanding why, that's a huge lift to the business. You're then, you're then Totally. Helping the business for you. Problem solve, not just being a data dump. Yeah. So I again, we're a little bit overtime here, but just bear with us because this is so important. So one of the things with this that I wanna ask you is you're always gonna get questions. Are you now saying that you need to be aware that those questions are going from just asking, you know, just seeking clarity versus solving problems. Like, you can actually draw a line on the type of questions you're getting, and you need to look at those two buckets and say, okay. We're no longer just being asked, you know, clarify this or help me. These are actual problems that we're solving. So you're saying that that is a clear line, and if you start paying attention, you can actually track that. I'm yeah. Exactly. I I also you've question type can so the operational clarity allows the question type that you're getting to improve in quality because they are now asking questions that they understand what's going on. They're asking better questions. They might still be exploratory, but it's just now much more targeted, much more informed. The data team understands more what they're talking about, what they're trying to go after, and that allows the data team to take more ownership or lean in more to be like, what is a bit let me help you understand what's going on here. Let me understand let me understand let me help you structure this problem you're tackling in a way which makes sense to you. And what other way of thinking about this, just if you think about the exec I as I as an as a, an executive, I guess, myself now increasingly, I can tell you that I get given information from all over the place. My inbox, that's my SAS tools, from the different parts of the team, solving problems at different levels of detail, like, from the highest level down to the lowest level. That's true for every leader. Everyone in the business actually is dealing with information, different levels of detail. The idea that they have space to, like, load that information to their brain, into their RAM in their mind, and get to a good answer, a good problem solve is Yeah. Unlikely. The more a data team can help an executive, a stakeholder structure their thinking, lay it out in a way which helps them grasp not just the numbers with data, but actually how it all fits together and make the make the jigsaw itself. That's so valuable because the cognitive load is being taken off someone's head when they're just in Slack or when they're just on email. You're actually taking the cognitive load away from them, and they're gonna value that more and see the the problem solving capability of the data team. Like, there's so many people, so many graduates who are, like, have STEM degrees who go into data are nowhere close to being utilized fully. Now, wonderfully, there's many more people in data than than not in STEM, but the key is that there's a huge you have to be such a good problem solver to be in data to do what you do, but you're not they get the team the the wider team to recognize that and use you that way is such an important thing. It's about taking on the the structuring the problem, the methodology of the problem solved, not just to giving the numbers out. That's the key lift there, which is helped by operational clarity. Okay. And then number three is I think, again, this is all kinda going hand in hand now. Right? We cannot go in the snowball hill. Okay. So solving business problems. Again, just to recap, if you are transitioning from a service team into high impact team, you can literally divide the line between the type of questions if you're doing this right. You're going from basic clarification questions, transforming into data informed questions that are more well educated, more focused on solving a problem. Okay. Yeah. Now the third tenant, because we we're short on time, is minimizing a time to decision. And I believe where this is leading is that if you do if you get your operational clarity correct and understand the operational model, right, which I think Kong should provide training on, different story, You then, are are now seeing the transformation of your questions. You no longer essentially have to run run from the business. Like, that's That that that's right. I mean, you you can tackle these in any order. Like, every team often has one of these as a bottleneck to them. But you're right. That's the that's the that's the that's the normal order we see that tackling, like, one to three, four. The key idea of minimizing comes to the decision is rather than moving away from the business yourself, minimizing your time to stakeholders, your goal as a data team is to work on the processes themselves that are driving decisions and leaning in Yes. And looking at going, well, how do I help make this this this this decision making process better? Not just provide the data to it, but actually help think the business think through that decision making process. So a very, very common thing for data to think about is self-service. Okay. Self-service. How do I help the business answer more questions themselves? Now that is a piece of the puzzle, undeniably. How to help this the business answer quick questions for themselves to they start to operationally make decisions as on a on a fast cadence is a really important part of that puzzle. But there's so many other decisions that are going on in the business from the most strategic at a board meeting all the way down to things you can even automate away with AI. And a goal of a data team is to look at the spectrum of decision types from the operational up to strategic and help make all of those decision making process faster, not just throwing in self serve and hoping that's enough. And that's a that's about looking at distribution of work and working at where to put your effort and time to make things faster and faster and easy for the business. Okay. Ollie, we have two minutes. So I'm gonna take the liberty here, because I wanna make sure that we get to the calls, the actions. At the end, people know where to find this stuff is important. I think measuring itself, I hope to some extent is self explanatory. What you can't manage what you don't measure. So, you know, I would hope that after you do all of this, you're open into measuring yourself and seeing how you're doing. A hundred percent. So the key idea here, which I think is very important, rather than optimizing things the business can't see, the recognition is that the vast majority the majority of the cost of a data team is in its people and in the payroll of those people, not in your server costs. There may be there may be some fringe organizations where that's opposite, but majority of the time, the most the biggest cost of business is where you're allocating your team's time. And so the most important idea here is that you're working on the the peeing of people on the problems that matter most to the business and putting effort there. And if you could justify that allocation of time, then you're in a very good place for driving ROI. And that is not Okay. There you go. Alright. Well, thank you so much, Oli. I think this has been amazing. We went a bit over, but we have a few seconds left. I just wanna make seeing numbers with a lot. Very passionate. I think it was great. And I actually think for those who are listening, you know, to more than live audience, people are gonna want more. So let's make sure that they know where to find more. So the good thing is that the entire more than numbers live series is focused on customers and people in the industry who are implementing one or all of these tenants. So if you're sitting here going, but, Ollie, how do I do this? No. No. No. No. This entire show, go in and subscribe. Let's get those links on the screen. Make first of all, you can go and subscribe to count dot co slash m MTN, and you will be the first to hear about every show. You'll get all the show notes. There's free downloads, and there's an entire community. Okay? So you guys wanna you're joining a thriving community. Yes. Count has a Canvas tool, but more than numbers is a movement. So make sure you guys get in there and get these show notes and go back and listen to some of the shows. That's number one. The second thing is that we're giving them access to the tenant site. Are we not? Yeah. You can get a tenant straight away. Correct. So if you guys wanna go, and we'll put these in the comments as well, you can hop to count dot co slash tenants, and you can actually access what Ollie was just showing. And you can get in there, screenshot it, play with it within the Canvas, and you guys have access to take that and go forward. Now I wanna say, Ollie, I'm thinking that there is a training coming here. I feel like there should be a training, but I won't put you on the spot live. But let's just we gotta wrap up here. Oli, this has been amazing. I have enjoyed this. You know what I mean? You can go on all day. We're data geeks, but I think more than the audience has gained a lot of knowledge here. So thank you for being a guest today. Thank you for being in a hot seat, and thank you for sharing your knowledge and passion. Well, thanks for being our first guest host. It's been, you've been you've done as well. Thank you so much for being here. It's been awesome. Yeah. This was great. So, guys, get in there, subscribe, and, oh, I forgot. You can also follow Ollie Hughes. Look up Oliver Hughes. It's his first name on LinkedIn. He is posting every day, he's posting knowledge bombs for you guys on how this thinking works, so make sure that you guys also follow his profile as well as the account LinkedIn page. Okay. You guys are awesome. Oli, thank you for having me, and, guys, be sure to check out next episodes. Take care. Thanks, everyone.