SELECT video_content FROM LIBRARY WHERE SLUG='18-07-24-part-4-beyond-metric-trees-driving-operational-clarity'
[18.07.24] Part 4: Beyond Metric Trees - Driving Operational Clarity
Loading video player...
To join us joining us again here for, part four of our magic tree master class. We're joined by, I think, most of you familiar with with Ollie. We're joined by joined with Ollie Hughes, founder and CEO of Kount. How are you doing? Hello. Sorry. Yeah. Yeah. No. Good. Thank you. Had a bit of a biking accident on the way here while I'm in London, but I'm okay. I'm okay. Yeah. Everyone has to it has to happen to everyone at some point, I think. It's a little It's a question of when rather than if, actually. Yeah. Yeah. Yeah. Well well, thank you guys for joining today. I'm just gonna tee us up and just remind us where we've where we've been over the last, two weeks with this master class before, kind of letting Ollie dive in to operational clarity. So, yeah, we wanted to run this master class just because we've been getting a lot of questions about mesh trees, what they were, how they worked, how to start making them really practical questions to really theoretical things. So we wanted to cover a lot of ground here, which I think we have. So just kinda wanna touch base on that. So we started last Tuesday. We're joined by Ergus Shiblati, who is, he's a blogger. He's an author. He's someone I think we've all kind of seen his post on LinkedIn and things like that. And we touched about what metric trees are, what are the bounds of them, what are kind of the the theoretical principles behind them that make them really powerful, which I think laid the groundwork really well, for the next couple sessions. So on on Thursday last week, we started building a tree live. We're joined with Matthew Brandt and Sara Subsakari. I think so today. Hello? And, yeah, for that, we were covering really practical questions. So, you know, what does a project look like if you're building out a metric tree? How should you, think about your approach to this? How should you think about, putting together metrics and talking with stakeholders and just, you know, what is the kind of actual, coding look like in that perspective? And then on Tuesday, we were joined by a few people who have lots of experience doing this themselves. We're joined by, Callum Ballard of Omaze, Michael Rogers of Bumble, and Will Mahmood of Mubi who have had extensive experience putting this in in in real life. So we got to talk to them about really practical things, like how did they get buy in and approval, and how did they start this, and what kind of is the impact that they've seen MetroTrees have. And this session, I think, Michael teamed us up for it really well at the end of Tuesday's session. We were talking about the impact of MetroTrees, and he said, you know, a big part of this is just making the business seem really easy, making it seem obvious, making sure everyone understands how the business works, what are the levers that we can pull. I think this speaks to this idea of operational clarity. So I wanted to have Ollie on today, to to talk about, you know, beyond MetraChase. What else can we be doing to kind of continue this this idea and continue adding value in this way? So I don't wanna spoil too much about what we're gonna talk about, but I just wanted to tee that up. And then I will I'll hand over to to Ollie now to bring us up to speed. We'll definitely be talking about it together. That'd be great. Cool. Yeah. Thank you. Well, nice nice to see you. Well, I really I hope you really enjoyed the series. It's been really fun to put it on, and and, David, you've done a great job doing it. Well done. I'm gonna I'll I'll just share my screen. What what I wanted to do maybe I should hear this up beforehand. So MetricTrees, as I'm hoping you know by now, is a really, really powerful mechanism for getting, your business clear on its growth model, understanding its metrics, the relationships metrics to each other, and how those metrics drive, drive growth and drive towards outcome. And, they are a really powerful mechanism, but, but we would, as Ted alluded to, say that metric trees are part of a wider story. And the wider story is like what is the way that data teams can provide the most value to their organizations. And often one of the things we we I recognize that we my co parent and I and Taylor and team have realized as we've gone on this journey is that it can be difficult as a data team to, know your role and know how to add value. That the data teams have a really difficult job because unlike other functions like sales or marketing where the expectation of what that department is doing is clear and sort of an industry wide understanding, data teams, the role is, often, less well understood as an industry, and it's more about filling the gaps. And so we've really want as we've been building count, really thinking through what is the operating model that we think is the most important way that data teams can drive value, how can, data teams, like, have a standardization about what their role should be, which can make give and they can use an articulate to the business in the way they work, and their objectives to help the business understand how to work with the data team, what data team can do. And that's been a project that we've been doing over a number of years. And and more recently, we've been working with a number of people to, create this framework of value, like, what we think are the tenants or the principles of high value data teams, of which metric trees form a big part. But I wanted to use this chance now to, with Teta to talk through the wider story, the way that metric tree sit in this wider value framework for data teams, and the way that metric trees can lead to other areas of change, where data teams can can drive value. So to do that, I'm gonna just share my screen and and walk through, this presentation, which we will definitely send you at the end of end of the workshop. If you're in our newsletter, you did receive this yesterday anyway, so you may already been looking at it. I can see some people are already already in here, and hopefully, we'll, make sure you have a a copy yourselves. And this just really is a this presentation we pulled together to set the scene for what we think a high value data team can be and where, I guess, as we'll go through, where metric trees fit in this wider framework. As I said, the introduction of this project has been very much focused on what is it that makes a data team the most valuable to the business. And we think there are four fundamental principles to that. And we're grateful as well for the number of people we've interviewed and worked with on this. They've been a huge number. I think we've done over over seventy five to one hundred interviews of different data leaders about this, and these are only a few of the people, who'd been willing to kind of put their name to this document, as we've gone through. Tayla, is there anything else I should think about before before we move on to sort of go through the different tenants? No. I think that's a good good introduction for sure if that's the scene. Cool. So I think about some people often ask me what, like, what is it that we're trying to achieve in the tenants? What is it what is the if I was to describe what a data team is, what a good look what is what is a high value data team look like different to those who are struggling to drive as much value? And, actually, I I I think the definition that we've the sort of analogy I would speak to actually comes from psychology, weirdly. The way that we often see data teams operate in a sort of negative sense can be where the relationship in the data team and the wider business has what's called in psychology terms a kind of parent child relationship where the business dictates the way that relationship works. There is a power dynamic between the business requesting and working with the business, and forcing the business the data team to work a certain way, which may not be the best way for the data team or the business to work. And that relationship can be quite a tense one, quite a low trust one. And what we see and what we believe this framework helps to do is to move the data team to being a much more of a adult adult relationship where the data team operates more like a a critical friend of the business, helping business to grow, but also doing things to help the business grow that business may not expect. So we talk in this presentation about the service traps. These are the ways of operating, which we believe we've seen again and again in an empirical study, I guess, that we think emphasize the the parent child relationship. And that there's four of them then and they're kind of, we can go through each of those for now. But these are the dynamics which we believe, like, undervalue the skill and the and the influence a data team can can otherwise have. So let's go through those four, and then we can move on to explain the four tenants that we believe lead to a kind of adult to adult relationship. And we'll we'll go through more examples of that. So that's how I was hoping to structure the session. Getting questions as we go would be fantastic, but we'll also make sure we have time at the end to do that. So here, the fill of the four, we call these traps, basically service traps. These are things which, as I said, we think, emphasize that parent child relationship and make the data team run to the the tune of the wider business. So the first one of those is drowning the business with information. The idea of the the data key the business keeps asking for information from the data team, and the data team keep providing it, And that continual provision of the information without any recourse leads to confusion, operational bloat, and a fragmented understanding. As you can imagine, that very much goes against the principles of metric trees that we've been discussing in this series. So we'll come on to the how that can be a help with the the counterbalance. The second one then is just answering a question the business has that the date the business sees the data team as a source of information, and treats the data team like a service rather than being a function with high with a role which is higher value than that higher impact and ultimately undervalues, underutilizes the scale of the data team. The other way that the data team can be undervalued and have a a sort of a a power dynamic difference with the business is why the data team putting up barriers between the business and the data team. It's very understandable reaction to when you get, you know, swamped with questions to try and create processes and formalize the way the business and the data team work. Sometimes that that is a requirement and a useful, but it it can also make the the data team feel more like a black box and, again, just minimize the role it can have in the wider business. And the fourth one, which is a and also a temptation and I think it's very easy to do is to focus on up on tasks which have diminishing returns and value or the business doesn't even understand. It's very easy, if if we're not careful as as data practitioners to focus on the things we can control, which may be our own code, our own infrastructure, our own stack, and affecting that with the out actually being a genuine outcome of value creation elsewhere in the business. So these four, sort of behaviors we consider to be, operational traps. They're very easy to fall into. This is not to say these are things which every team does perfectly, but these are the four ways that we can remove ourselves or devalue the work we're doing by the nature we're asked by the business. Any questions on that, Tay, you think would be worth flagging? Any thoughts you have on this? Yeah. I think, especially number three, it just really makes me think of the the a lot of the language you hear around self-service right now, which is just kind of, oh, you know, throw it over the wall and and hope that it, you know, that that solves all those ad hoc requests that we get instead of kind of leaning in and and playing a very different role. So I know that that's was in my mind when you were going through, particular kind of two and three. Yeah. That's helpful. And there is definitely a place to sell sales if we're gonna cover when we go through the tenants. Just to sort of bring us to life a bit more, these are some of the ways that our sort of working group would highlighted signs that you're in more of a service trap mode, versus being more of high impact. So some this is not an ex like I said, exhaustive list by any means, but it's just a five things that if these resonate for you, it might give you some signal that you you then you could potentially have a lot of you could change the way you're working to drive more value. The first one is having a dashboard to employee ratio closer to one where you have as as many or more dashboards, than you have on your employees. That would suggest that you maybe are there's too much information in the business and that is confusing the business rather than supporting decision making, clearly. Your team feels swamped by ad hoc requests and you feel unable to challenge the business about the nature use of those things. Your tech your team wants to spend more time developing just technical skills rather than soft skills influencing. There's there's an undervalue of the kind of skills of the of the analyst function versus just an engine being focused on an on engineering and tech. Now clearly, both are needed, but if it's about that balance being right, your data team is spending over forty percent of its time maintaining operational reports and data quality. That again suggests that the work you're doing is maintaining, a service to business users, rather than driving incremental value. And then the final one, which is always very hard to, like, really just as we'll come to, like, really prove a pound number of ROI sometimes, but the most important thing is can your exec your team list three ways that you've caught that the day your team has contributed to growth in the last quarter? If that isn't possible, then that's a sign that they see that the potential dynamic between the dent in the business is more more service based, than than high high impact. So what are the what's the sort of what are the alter what's the alternative to this the service way of working, and what do we think are the the principles that we see, in both in our customers account and more widely that we think define, the way that data teams can drive real impact into the organization, really change the way make themselves critical to the way the business is growing and understanding itself. These are the four tens. And I I'm actually gonna go through these four one by one, and then I can show how these all fit together with examples as well. So there's four of them here. First one is seeking operational clarity, which as we'll come to, we've been discussing already in this series. And then the other three, which maybe new will touch on as well in this session, is solving business problems, minimizing time to decision, and then measuring yourself. Now so far this series, we've been really focusing on metric trees, which very much sits in the operational clarity bucket. So I'm gonna focus on that first, make sure we understand that that principle as a whole, and then explain how seeking operational clarity is a lynchpin of how to move into these other areas of value that a data team can have. So hopefully that makes sense as a structure. So let's let's go. So firstly, let's talk about operational clarity. So we obviously need focusing a lot on power of metric trees, how metric trees can help clarify your growth model to the business, help formulate an understanding of, what what's driving performance and making the business still simple. And that is a very, very powerful way of seeking operational clarity. But stepping back, there is the the concept of operational clarity is broader than just metric trees. The data teams that we see driving real impact and being at the core of the operating model of their business, their view is that they are constantly ruth ruthlessly prioritizing, what information is in the business and the simplicity of of, how well I've been understands what's going on. So they they're focused on creating the the best common and operational context with the least amount of information, creating a real signal from noise. So this means that that these data these these teams are working with the business to clarify the leaves of growth. Metric is so great at doing that. But they're also helping the business understand the priority areas and of folk of of focus and even just making sure the way they're communicating and any work they're doing it's done is with clarity and conciseness in all ways. They're working as hard to remove information from businesses as they are to create new ones. And the beta benefit of this is that you're you're gonna have a faster and more nimble organization because, like, focus on the key priorities. You've got greater organizational resilience because you've got a a more climate working culture as you understand how everyone's role fits together. And by having a common operational context, everyone is pulled together in the same direction. And in contrast, as we discussed before, and if there's the traps, seeking operational clarity is about having the little amount of information you can get away with to make sure everyone understands what's going on. And that's in contrast to just providing the business information as they request it. Now how do you do this? How does operational clarity work? As I said, metric trees are a great a great example of that, and we've heard from Will about how they've Ruby have used meta trees to really drive, clarity in the product space and the organization about what's really going on with their with their products and their usage. But there are lots of other ways to drive operational clarity than just doing metric trees, and this document will show you that it has a lot of different ways you can do this across both the small day to day tasks you're running and the most strategic ones like your operational ports and metric trees. So, for example, just to pick a few out, running regular training with your team to understand the best practice for concise communication. Having a named business owner for every operational report you have. Make sure your metric tree has, every node of metric tree has an owner who can look at that KPI and understands it. Like, that alignment to the operating model, make sure that your as a data team, make sure that's happening. Depreciating all unnecessary assets every quarter or every I mean, every month is an incredibly powerful way to drive clarity and focus and remove, multiple sources of the same piece of information. Creating sort of monthly or quarterly overview reports, which maybe point to the metric tree, but give better more narrative that gives a kind of common understanding of what's really going on the business with with some with some storytelling is another great way to constantly bring people back to a similar understanding what's really happening. So what I'm trying to point out here is operational clarity is a mindset change where in the best teams, they are ruthlessly always trying to work out how to make the business feel simple in the minds of the wider business, make the growth model as clear as possible. And metric trees are one of the best ways to do that, but it goes beyond just producing a metric tree moving on. It's about the continual pruning of of that metric tree, refining it more, and just in the way that you're communicating day to day, making sure that everything you're doing is providing clarity rather than confusion. What do you think, Taylor? How does that sound? Well, yeah, I think we know. I'm I'm behind it, but I did wanna bring up something that I think I've heard, when we when we kinda bring this up, especially around the idea of of metric trees. If we imagine, you know, we're gonna build one for the the marketing team and we go ask them what their you know, what are the metrics that they care about, and they don't really have a good answer. And and suddenly, it's kind of up to the the data team to step in and help them find a good answer. I think one of the kind of things that I've I've heard is that, well, that's not that's not my job. It's not a data first job to necessarily define what marketing metrics should be. It's not you know, that should be something marketing should do. And so I think there's kind of this pushback of, you know, what why should I and and data have to step beyond what I normally consider my area to to do this kind of thing. I don't know if you have any kind of thoughts for that type of situation, but I think it's likely in an operational clarity sense that something like that might come up. You're gonna have to kind of step beyond the normal bounds of of responsibility. Yeah. I I think that's essential, actually. I think a lot of what we're describing here by getting to sort of an adult adult, like, critical friend relationship is that you're no longer just filling the gaps that's left by other departments that you're you're taking ownership for what the business needs. And because the data team has that, complete oversight over all the data in the business often, the role is best suited by you, often to clarify and question and enable the business to see where there's confusion and lack of clarity. And And if you don't lean into that when you see it, then you're undervaluing the position that you the responsibility that you have by being the, having the oversight over all the different processes in the business. Yeah. I agree. We're gonna move on. Let's move on to the second. So as you can imagine, operational clarity is a really important part of the way that the data team can most enable, really smooth, well understood business. And there but there are other tenants which as you as we go through and you'll see are also equally valuable. And as and you, as we'll go through, and at the end, we'll show how these three different all these four different tenants work really well together. There's a a virtuous cycle of how, working on these tenants together drives incremental value. So let's let's keep going. The second tenant here is is probably less controversial perhaps to people who've been in beta is the idea of solving business problems that data teams, often I I don't I go into data because I love the idea of problem solving, using data to solve real problems. And the best data teams focus on on solving the business's biggest problems and prioritize their analytical resource and their and their their time on solving problems rather than just solely maintaining the status quo. Data teams are fantastic problem solvers. And in the best organizations, the data team is seen as a powerhouse of problem solving for the wider business can pull on. And, it it's also not just about providing the key is it's not just about providing answers to questions the business has. In in the best data teams, the role of the team is not just to provide answers or to provide information to a question. It's to help structure the thinking of the, towards that solution. So, for example, if someone asks you to, I'm looking to this looking to improving our marketing campaign performance next quarter or help plan it, the data teams the best data teams are helping to structure the structure that problem solve into various pockets into various questions, not just providing the data, but actually helping the business leaders to structure their thinking and make it really clear. Now that's that can that can feel like a a step over the boundary potentially, but it's just allowing the the data team to provide information in a way which is most consumable and by nature is structured to help it to be understood and allow the business to take the things out of their brain and put it onto paper as well. Now already, you can imagine that it's very diff can be perceived quite tricky to get to a point where you're solving business problems rather than answering data. And this is where I can start to help. I think it's for the show the power and relationship between increased operational clarity and then how this helps this tenant to be more valuable. Because as you get to greater levels of operational clarity, as the business understands itself more, understand its growth model clearer, and it feels more simple, the areas of unknown, the areas of problem become much starker, much clearer. The the problem definitions become more obvious and less murky. And that then enables the beta team to more obviously say our priorities is to solve these these three or four areas of the growth model. Be that how to improve this metric of how to understand what the relation is with this particular, conversion, or this lever of growth. And so it's e once you have increased operational clarity, the ability for the data to push back on requests which don't drive incremental value becomes easier. It's not to say you can't solve business problems off the bat, but you can understand that as you increase the clarity in the business, so the ability to problem solve in the biggest areas of the opportunity become more obvious. And that in itself then allows that to be an improved understanding of the growth model as well. So it becomes this virtuous cycle between these two tenants and and the others we'll go to. Let's move on. Tenant number three. This is where, people people off the way, as as I mentioned, self-service. And, self-service is has a role in, and providing a way for the access to data themselves is a very important part of the data team's job. But, again, I think, it is often oversold as a as a euphoria, where it never really quite works that way, that people never quite get the usage of a self-service tool they they they would like. They never quite get the the grip and understand as well as they'd hoped to. And one of the things that we've noticed that we believe is that the better focus for a data team is to think less about self-service and to think bigger and to think about minimizing time to decision across the business. The idea of minimizing time to decision is it means you're looking at the decision making across different parts of the business and business as a whole from the most strategic to the most operational and working out the way to make those decisions, but but not just better, but also faster. And this allows the beta team to have a much broader scope for impact because though it may be true that giving a sort of traditional self-service tool may help a particular team in a particular part of their workflow, it doesn't necessarily help the company board making the most strategic decisions. They don't need a sales post tool. They have a different workflow, different decision making process. And the data team can have as much impact there by providing a pre read on time, for example, then just providing a kind of a a data map build to serve from. So we really strongly believe in the collective view of minimizing time to decision because it allows the data team more scope to think about the full range of solutions that might be needed and match them to the full range of decisions that are happening in the business, not just, by the not just against different decision types, but also by different departments. And thinking about each department separately rather than trying to look for, like, in a holistic utopia of self-service. This is a really important way for the data team to drive impact and also look for ways to, you know, save time and efficiency as well. So I hope that makes sense. It certainly it changes your the data team's role from not just minimizing your time serving data your business or my ad hoc request. It's saying I'm gonna lean into the process, not just provide the data into that process and make that process as efficient as possible to minimize my time, not walking away from the business and putting up barriers to to make the inefficient process easier. So an example of that which we we is is very powerful, which we we highlighted in our customers too. Good to go is the idea of agile working, that using a tool like count for collaborative problem solving or even building out an operational core or a metric tree collaboratively enormously short of the time to value because the understanding, the the discussion is happening all the way through, and the whole team is moving faster with a greater collective understanding. There are many other examples of of doing increased time to decision. Implementing version control data model is a classic example of minimizing time to decision by improving data quality. But it can also be, as I mentioned earlier, sending out a board preread one, one week in advance and asking for questions and feedback ahead of the meeting so version two can provide, the answers the all information the board thinks they need to make a decision, for example. So there's lots of ways that you can increase the speed to decision, and I hope what we believe is that the best teams think much broader than self-service and are really thinking about, the way they can drive they can drive value across all the decision making flows. I think another those oh, yeah. Go ahead. Another way I I kinda see this, maybe instead of just contrasting against, you know, minimizing time with stakeholders is also just trying to minimize time for a project. So I see, you know, people say, you know, how do I I just, I have so much to do. I'm just trying to get this done as quickly as possible. And I think that kind of mindset also makes it difficult to to ask those questions like, okay. Well, what are you trying to do with it? Because you see those things as kind of blockers for your ultimate goal. So I think kind of orienting yourself around this a a different objective around, like, getting to and not just the best decision, but minimizing the time to get there, I think helps reframe this as not a blocker to getting something done, but as, you know, crucial to getting, you know, getting the goal that you're trying to get to. Agreed. That's really helpful. Let's move on to the the fourth the fourth principle, the fourth tenant of a high impact data team. Now this is the one that people, get squirm most around because it doesn't feel very comfortable. It's also very difficult to do. This is the idea of measuring yourself, that the teams who are, providing the most impact we see are the ones who are constantly measuring their own internal operations to improve speed, quality, and costs. So it and people often one of the one of the impetus for the Zidibus project was when we saw in the market people talking about, thin team ROI and pointing directly to China saving data data computational costs. And though that is important, that is a complete minimization of the way to drive ROIs of data team because in reality, the biggest cost of the data team is in the payroll, often. And it's the allocation of time of that payroll, which is either gonna drive value or it's gonna be maintaining a service function. And what I wanna make sure I'm clear with this is that this measuring yourself isn't about providing a pound ROI number. The kind of paradox of this tenant is the teams who do this or strive to know they're working the most efficient things and the most high value activities and work out even in perfect ways of doing it, never get asked to prove an ROI number by their business because they're just already thinking constantly about how to make their their their lives better and make their work more efficient. It's a mindset shift thing rather than being a a kind of a a dollar note or or or a pound note thing. So what this is about is how do you how can a, a data team think through task allocation time spent? Do you have as a team a way of tracking what projects you're working on, which projects are how much time is spent on maintenance and and quality control, the status quo of the operation and this and the operational reporting you're doing versus doing work on high value active digits to move the business's understanding forwards. Again, you can understand how the these two tenants, minimizing time to decision and measuring itself can really work together. Because if you're if you have an understanding of where your team's time is being drawn, which teams, which processes in the business are asking a lot of your time, that can be a strong indication of where you might wanna get into what what where you can maybe add impact by improving the process or help the team who's asking for your or your team's time in a sort of inefficient way helps you identify where you can work more, what kind of intervention meant makes sense. So these two tenants have a very strong virtuous cycle as well. The more you understand where your time is going, the better you can potentially help. Not always, but it can help you point to where there might be time to maybe opportunities to minimize time to decision. It's not perfect, but it certainly helps. These two things together really help you to make sure that your team is being as efficient as possible. Again, lots of ways that you can do this both across technology, processes, and people. So one of the ways that we do that in our product and technology wise is just providing our customers with, like, really high quality telemetry so you can see what kind of reports, what kind of actions are being used, how long it's taking to build reports, where you where's your team spending its time, and where your business is spending time. It can also just be creating a daily weekly pulse report for each team member just to help help document on a sort of simple cadence, but just for internal purposes where time is being spent. It can also be that every so often, maybe once a quarter or once, say, even half a year, you just have a period of time where you're logging all the requests and projects that you're being as your team is being pulled into to help you just get an audit of time spent by different departments and different tasks, alongside absolutely looking at monthly review of computational costs, but it's definitely beyond that as as a really important part of it. So lots more examples, of this and across all the other tenants we have, lots of examples that we can share with you after the the the webinar. But, hopefully, those three tenants make sense. We recognize that some of these maybe you think you are already thinking about, like solving business problems or, maybe you're already after I measure where your work is going. But I hope that by painting them as these tenants, what I think what I'm trying to what we're trying to show you is that these aren't just one off things you could tick the box like a metric tree, drop down. These are mindset things that the teams who adopt these as a they're constantly striving to improve the way they work using these tenants as a guide. That is the best way to work. It's a mindset shift. It's a striving always towards it. So how can you start to use these tenants? Well, firstly, auditing your current operation. What we generally see with teams we work with on these tenants is there's usually one tenant which holds back the ability to execute on the rest. So for example, if if you're in this webinar series here, maybe the idea of operational clarity is what we really think is needed to drive a business forwards. And by doing metric trees, by providing better making business feel simple to the wider organization, That will then by doing that project, you might then find the next bottleneck becomes how am I now problem solving on these areas. It enables you to move on to another tenant to drive incremental value beyond that. So definitely don't think about these tenants as being can't be tackled all at once. It's really good to think about it more, which one of these is the bottleneck on the rest of the way we work. Running workshops to help identify changes that you can make quickly, that's another way to do it. There may be some quick wins that you can go away with and think about. Another very pathway to use these tenants is just to use this document. We've seen it many times. We've been very humbled to see it, that some some teams take this these idea of these tenants and go back to the business and say, this is the way we want to work with you. This is the way we can help you the most, particularly going to your exec sponsors and your executive team and saying, we need to work in this way to be the most impactful we can be with the resource we have. And that can be a wonderful way to start the conversation, talk about operational crash, talk about problem solving, helping the business see the data team differently, and start that journey, that journey forwards. The other way that we would like to recommend people use the tenants is to think about, them as a framework of value and therefore making your, any technology purchases you do, any team hires you make to reflect them against the tenants. That if I'm trying to make these outcomes possible, I'm trying to make sure my team can deliver against these core tenants, I'm gonna buy tools which enable that those outcomes or hire people who can help me enable those outcomes, and I'm not gonna choose a tool based on a cool feature. The feature might be enabler of those tenants, but it's it's raising the vision beyond just a feature based purchasing process and thinking more about the operation you're trying to run, not just making life easy for the data team, but making sure the data team's influence into businesses as big as possible. So that's that's those are the tenants. As I said, they have a very interlinked approach. For example, great operational clarity leading to a clear view of the business means you are more clear on the business problems to be solved, and that improves the greater understanding of the growth model. That virtuous cycle is a very, very powerful cycle to build upon, which allows you to constantly improve operation of your the the the business's understanding of itself. But also the ability to have faster decision making by that the team is working and improving this cycle, is another way again to get to better outcomes faster, which improves greater operational clarity. So, really, as you can see in this diagram, operational clarity is almost the heart of the data team's focus. It is a it's an enabler of doing all else well, but it may be the thing holding you back right now. The and then there may be other areas as well, but potentially you'll hear them operational practice thing you're you're you're most acutely aware of. And and that is, clarity being the kind of manager of the data team is a very important, ethos we believe in. Taylor, I've I've spoken a lot. I think I, is there anything I've missed before we open up to questions? I don't I don't think you've missed anything. Yeah. Please do drop any questions you have in the chat, but while while we're waiting for those to come through, I had a had a question for you. It's just if you had a kind of a a story or an example or you think best exemplifies using these tenants, maybe possibly using operational clarity. I know we talked about movies, but maybe a different one. Maybe something that's not metric trees, but still on this topic of operational clarity and and maybe how it how it changed things. Yeah. I I that we're we're we're very fortunate that that, we have a lot of customers who use count to help them with operational planning, both building metric trees, but also just using it as a way to build out process flow maps. And the one the wonderful thing about businesses is they all are ultimately all very similar. They all are combination of processes. And so and it can be very, difficult to to to understand how a whole business sits together, how these different processes interlace, the activity that's going between them. So we've seen, it's very common to see our customers using count, not just metric trees, but also for, doing a process flow map and mapping out what's the the highest level growth model as a kind of a full cycle a full cyclical process flow, not just metric trees. There there's been a customer recently who has who when we went through this with them, they, basically completely dropped their own all BI tool. They went to the student to the CEO and said, this is what we wanna do. Operational clarity is our is what we wanna focus on. We wanna provide a way for business to have complete visibility of how they all fit together. And they're now building a series of metric trees for every department in their business as well as having a single high level metric tree for the entire business, which goes to the board every month, which has, like, a high level visibility and then has metric trees for each individual department as as, like, the the second level down of that, which has been amazing to see, to see people looking for that that kind of, that more impact focused way of working. Yeah. Yeah. I think the it is good to think about yeah, you can do so many things when you kind of aren't restricted anymore by a single type of way of presenting information, like all the all the flows and process maps and, just any process really can be mapped out. That's just really powerful way. I guess another question then is, I guess, looking at this, it's easy for this to feel like a big change, like a big another big thing, and and when am I gonna get the time to to do this and prioritize this on top of everything else? Do you have any kind of tips for for somebody who says, like, this all sounds great, but I am I've got enough on my plate right now. How can I how can I do this easily? Yeah. It it so the first thing to say is this is not an so wherever you are right now, you can make incremental change. The key is, like, the key I think is what is the north star that you're working towards that you can you're never gonna you're gonna keep striving to improve against? What are the kind of principles that you're gonna keep working to that you're, I think, it's not about making big leaps. It's about making a mindset change and and making small steps. So that might be building a metric tree as we've discussed in the series as a way to start that process of clarification that can be often where a lot of people start. But it could also just be, you know, looking at the doing an order of your request that you're getting from business and working out whether it's inefficiency and operation to them by the time to to create space to, to go after this. It could be that you're I think you change your prioritization when you think about hiring to maybe finding more soft skill. People got more experience of soft skills and influence rather than just technical skill. It it's it's worth, as I said, doing that step to think about where am I really bottleneck most? Not just time, but you can make every decision you're making, you can make with a implication towards towards an increased better value. And I think what we've what we believe what I believe from working with hundreds of data leaders on these these tenants is that this is a really helpful North Star to work towards incrementally. Even if you're doing it in small steps, just having a goal is incredibly helpful. Yep. I agree. I think that that like you said before, the mindset shift can be a really powerful way to just reorient yourself. You'd be surprised how many things kind of fall out when you just start to to look at things a little bit differently. Well, cool. I I don't think there are any questions. At least they're not they're not coming through if there are. If you do have questions, you can email me. I'll email everyone a recording of this as well as all the sessions and the link to the presentation. So you can feel free to reply to that email, or you can contact Ollie. Everyone probably knows where to find you. Yeah. Thanks. This this concludes our our four part metric training session. Thank you for being with us. It's been great. Hopefully, we can do something else like this soon. Yeah. Any any of the closing words for me, Ollie? No. Thank you for doing it so well. I'm looking forward to hearing how people get on with it. And if you want any help with the tenants thinking it through, then you feel free to reach out to us. We'd love to help both on metric trees and the broader strategy piece as well. Yes. Alright. Thank you, everyone. Bye. Bye bye.