[11.12.24] Breaking Free of the Service Trap with Count

If you're, west of me, I'm Ollie. I'm one of the I'm the CEO, one of the cofounders of Kount. As you probably heard of Kount, we're a Canvas based BI tool. Today, we're gonna be talking through a topic which is very dear to my heart, and I think it's one of the most important questions in the data industry right now, which is breaking free of the service trap. How does that work? What is the service trap? So today with me, I'm very humbled to say I've got two amazing people who are tackling this problem head on. I've made amazing progress. We've got Emily. Emily Lowe is director of data at MoonPay. Hello, Emily. We've got oh, sorry. Yes. You are muted. Classic. Go say hello. Yeah. Hi, everyone. Yeah. Glad to be here. Glad to be here. And we've we've also got Calum. Calum Ballard is analytics director at Omaze. Hi there. Hello. Thank you both for kind of joining me on this topic. So the idea of the session, we'll keep it relatively informal. It's gonna be a conversation. We'll talk through various different questions and frame this discussion, around, like, what is the service trap? So here's the agenda. We're gonna cover off what is the service trap? How do you define it? What does it feel like to be in the service trap? I'm calling it one of the biggest challenges in the data industry, so it's important we have a good definition of this, but we kind of recognize this challenge. And then obviously, the question that maybe we're we're wanting to ask and we were are we getting to Emily and come to tell us their story. Just talk about how do you break free of this. What does it look like? What's their journey's been? We'll also, give a bit of a principles of value. We have this idea and account called the tenants of high impact teams, which is a bit of a a framework to help think about, like, what it means to work in a different way, and what are the value principles of our data team working outside of the service trap. And then obviously talk about how we get started and make sure we have time for any questions. So that's the idea. Conversation bias not I'm trying to make a little of a presentation as possible. Very much a conversation between the three of us. We'd love to have questions from you as we go. If we're not making sense or you have anything we can pick up with, we'll also have time at the end to sweep up anything which doesn't necessarily fit within the within the conversation directly. So just dump in as you go. We'll make sure we cover it off. Calum Emily, are you ready? Yep. Should we get started? Okay. So as you can see, I'm actually using count as presentation. And what we're gonna do first is just talk about what is the service trap. I just wanna tee up some kind of relatively sobering stats which I just think helps frame the industry challenge and then we can go into more definition of the service trap itself. So one of the things that, really has sobered us at count as we look in the market and and sort of observe things, this is a statistic which, kinda was sad to me to see, which is basically from a HBR Harvard Business Review just surveying executives, I guess, the the people running, companies, the Fortune five hundred executives in this case, so larger organizations, where they basically said that the number of companies who said they were driving innovation with data was the same proportion in twenty in two thousand as this year. So it's like a zero percent in that group of of companies, there's been a zero percent change in their ability to execute on their data strategy and make data a driver of innovation, a driver of growth. And that's obviously one data point, which I think unfortunately resonates with me and really resonates with the wider community of, like, how do we actually change how we work? How do we actually become more intrinsic to the way our organizations run? We see the potential, but are we actually delivering it? The second stat, which I think is again just framing this, comes actually, from the state of analytics engineering survey that DBT, puts out every year. This is the latest data. And this is a question which was asked about the the the data teams that these the survey response are part of, like, how does your team measure success? And the thing which is really shocking about this is basically the way that most data teams or the minority data teams, only about twenty percent, ten percent it can actually well, ten percent can measure against financial goals, but twenty percent in general have a way to measure their impact and actually are trying to, I guess, lean into a business wide outcome from their work. Whereas the majority of people are measuring the enablement of teams or project completion. They're measuring task execution rather than be able to point to their ability to help move the needle for the business. And that isn't a great statistic in my mind. It suggests as a team with sort of as a industry, we've given up and actually feeling that we're connected to the drivers of business and it just plays into the support now support narrative. The third thing which really saddens me personally, I'm a, having been an analyst in a in a previous life, is to see that the analyst function, isn't being invested in. Like, we make analysts are the the the mechanism of delivery, for analytics, for BI in an organization. They're the ones translating data into impact. And, unfortunately, if you this is actually a great piece of analysis done by Motif recently where they showed that the career paths and the tenure of different roles in data in the business. And what you can see, which I think is really sad, is that the ability to go from senior analyst to staff analyst is an incredibly small conversion rate. There are it's the smallest conversion rate by about a factor of ten almost compared to every other port or path or discipline in the analytics space or the data space. Because all that means is that analysts find themselves not being valued and don't see a career path to being that value generating function and instead are moving to more technical roles like analytics engineer, data scientist. And this means we've got a brain drain. Not only are we not delivering impact, aren't we measuring ourselves if we are managing impact, also the mechanism of delivery of the analysts and how analysts are working with the business. They're not investing in that talent. These are macro stats which kinda point to a challenge for us. How do we actually break out of that service support function process? These are trends if you're against us in this and suggest that we somewhat might have given up again might have given up might have given up in the chase. Emily and Calum, I don't know how these stats fit with you. I know these are kind of high level macro trends. Are these things that you've picked up on in your sort of exposure in the market as you talk to colleagues and peers about data space? Are these statistics resonating? I know they're they're high level, but do they help frame the debate? Yeah. I'll go first here. Actually, funny enough, I have recently transitioned my entire analyst team into data science. One of the reasons for that was exactly kind of this. I think there's also a difficulty in the data space where analyst is a pretty loose term. Right? We, of course, in the data space in as data practitioners, we have a very confirm, we have a very firm idea of what an analyst is, the technical requirements that are and technical skills that you need to become an analyst. However, there are also plenty of other analysts. Right? Like business analysts, finance analysts, pretty much anywhere where you're an end user of the data as opposed to the builder or the modeler, which is what we consider to be an analyst on the data practitioner side. And so that spurred me to make this transition to data science, which is more clearly and closely aligned with engineering. Right? I think that there's a lot of debate as well, of course, as to whether that's true or good. One of the reasons, though, is exactly our topic of discussion today where it helps frame the optics about the value of data as beyond because that is what analysts do. They do a lot more beyond just presenting reports and dashboards, etcetera. And so data science to me seemed a better encapsulation of the practice of data that we're doing at MoonPay especially, versus, you know, analytics. Whether this denigrates analytics, it it shouldn't. I don't think that's the the the the point of it, but it's really to help others understand this is a technical role that requires a lot of expertise and a lot of broad and deep, both types of thinking that doesn't seem to be, yeah, I guess, like, marketed properly, let's see, in the industry so far as I've seen. That's cool. Yeah. The positioning is really important here, isn't it? And, like, where do we see value? Cam, anything on here on these kind of maybe maybe any of these resonate for you? Have you seen that in your in your in your own sense in the market about people being challenged about, like, feeling that value is is being there? Yeah. I I think that DBT surveys is incredibly interesting. I know that being a DBT survey may skew a bit more analytics engineer and and maybe enablement is a slightly more relevant kind of metric of success, for that cohort. But, yeah, trying to understand what the point of your role is as an analyst. Like, what is the end goal of you and your output? I mean, this is a topic we're gonna get into in in some detail, I imagine, in the in the coming half hour or so. But, you know, it's a path of least resistance, I think, to categorize yourself as an enabler. I am someone who allows other people to do their work, or I am someone who facilitates the actions of others, which is true to a limited extent. But I think as soon as your mindset is in that place, then you are kind of destined to be a service function. Right? Like, that is almost by definition. You are a service function if your whole shtick is enablement. Yeah. The challenge that comes then is defining what you actually are if not that, which is a nontrivial exercise and kinda gets you into scary places like, actually, no. You as a as an analyst are responsible for one of these key metrics that drives performance in the business, which is a little bit unnerving and a little bit, yeah, feels big if you're if you're an analyst and not used to that. But I think I think it's the direction that you probably want to be taking yourself when you're thinking about getting out of this this, this life of kind of being in the inner service function. The aspirational direction of where you're trying to go to, are you trying to double down on being an ailment, or are you trying to lead into a, being more valuable, getting more satisfaction from that? That's great. Thank you so much both. I'm gonna now I I sprung it on you. I'm gonna come down. What we're gonna what I'm gonna do now is maybe bring it down from the high level stats to the market and bring it more into, like, what is the service, like, the service trap and, like, how does it look? How does it feel? And to help us frame this, I wanted to I know you both have seen this before. I one of the things that we talk about at Cal and we've talked about lots of our community is, like, how to think about the service trap. Like, one of the ways what are the behaviors of a service trap which we think going unchecked kind of move you more that way? So what we talk about, these four kind of, operational traps. One of them is drowning the business with information that that data team who is just doing all the business requests is just pumping out assets, pumping out data products, dashboards into the business, which just leads to confusion, creates a bigger operation, and fragments understanding. You are just providing numbers without really helping think through why that's useful. It's an information production engine. And that coupled with that is the idea of answering every question in the business. So just, again, not just providing information, but also just delivering information without thinking through the wider context, helping the the business to think. And then that also leads to a the pain of this engine, the ad hoc engine as it were, leads to minimizing time with stakeholders, moving away from the operation, moving away from the valley generations, and just focusing on things that you're in your control, creating boundaries between the data team and the wider operation. And then your the end result, the kind of the really like, the bad behavior becomes fourthly, the idea that you're optimizing your world, the things that the business can't see and value. That may be very indirect actions which lead to business business outcomes. These are these are just four kind of failure modes which are interweave as we'll see, but these are ways to think about what the service the service trap looks like. Drowning information, answering questions as the business requests, being a resource to them rather than being a peer of them, minimizing time with stakeholders, making it even more transactional, and then focusing on areas which you which the business can't see the value of as much. And we call this the vicious cycle. The vicious cycle links those four failure modes together where that as you answer every question business asks, you're creating more assets, and that in turn floods the business with all these reports, all this fracture understanding what's really going on, which creates confusion. That's a that's a vicious cycle thereof. As you produce more, and you produce more fractured answers to questions, you don't give the the wood from the trees, and the business is just flooded with information. This means that as this gets worse and worse, you then start to blindly optimize. You you're looking to, optimize what you can control, and that means you're spending less time on the business, and that increases that context gap so you start being more and more of a support function. This is there's been a way to think about it, but this is the the vicious cycle we see again and again with the people we talk with, the community we deal with, is how to break the cycle, how to help the data team become more less and less of just a knowledge, like a data repository, and and moving away from business more and more. So this is how we think about that account. Emily and Cam, you've obviously got your own journeys and only only a version of this. Can you maybe talk through how in your current role or previous roles, how it's felt to be in this kind of vicious service trap? What does it feel like? When did you sense it? What was the kind of what did what was the, the context when you felt you needed to make a change? I'll go I'll go first. Yeah. So I, we we and I've seen this actually at most young data teams. It's very typical. Right? Because what happens is that data is not normally part of, let's say, the founding team of a company. It is very rare that that is the case. And even if it's a data practitioner, they're not wearing their data hats usually. They're using, you know, their founder hat, their entrepreneur hat, their operational hat, etcetera. And so, what happens is, normally, data comes in and there is a sense of we just need to see what's happening. And already, by, quote, unquote, we need to see what's happening, that is already the start of the service trap. Right? And, what happens is that, okay, we need to see more of what's happening. So you hire more people, you do the same things, and then eventually, you're in this place where no matter how good your data is, how good your infrastructure is, how good your tooling is, how good your even to some extent your governance, even if it's, you know, explicit or task fit, it still is a problem when the function of the data team is at the, we'll say, like, endpoint. Right? Only data data is only brought in when people want to hold themselves accountable or when they need to report to investors or the board member or exec leadership. Even to exec leadership themselves, right, that is also a very low level way of using data. And so this is, yeah, something I've seen time and again at most of the companies I've worked for. Some of them never get out of it. So I remember at, when I was a consultant at a digital marketing agency, and I think, Calum, you also work in consultancy. Consulting by nature is kind of the service trap. Right? It's more like, hey. We need to solve this one particular problem. How do you help us do that? Here you go, and then you walk away. That's kind of the job. And so the problem is that if you're seen as that level of consultancy and that's your outcome, then, yeah, it's it's kinda like that's your identity as a data team, and it's very, very hard to change that. That's great. Thank you. I I I think that's absolutely right. There's a real tension here about the needs the operational needs of the business to get going and seeing things, but then not falling into that trap of that's the most value at every stage of your business. I think that makes a lot of sense. Kyle, how how how's it felt for you when you've been, like, in the if you've seen the service trap or you've been in that function, like, what does it feel like? What were the triggers that made you realize it wasn't the the best best way to work? I think it's something that you can be blind to in the moment, but I think you can realize you're in it when you're getting to, like, milestones within the year. So, for example, like, in a performance review. And if you're sat down writing your performance review and you can think about, like, I built this dashboard and answered these questions, that's great. If you can't think about, like, and that changed x, y, and zed and resulted in this product feature being shipped or this revenue or conversion or whatever other metric materially shifting, that's not so great. Like, can you come back to the last six months of your work and think, yeah, these were the business outcomes of what I did? If you can, like, that's really good, but often, I think the behaviors and the operationalization that's described by this this service trap model leaves you in a position where you can't do that. And that I think is a really a really clear red flag of that being a problem. Yeah. We we can kind of obviously go into more detail later on, like, how you how you think about fixing that. But, yeah, there there's a whole, obviously, like, mind shift kind of, change that's required to kinda get out of that. But, yeah, really, really having an understanding of, like, what your contribution to the actual business outcomes are, I think, is is a really key aspect of this. One of the cheeky questions I love to ask is when I meet them for dinner or just in a kind of a conversation is just, like, what's your dashboard to employee ratio? Not that that is a perfect metric, but it does suggest there's a there's a habitual habit of producing assets as the measure of value more than, like, the outcome of a of the reported building driving metrics. Because if you're just you obviously, no one should really necessarily be looking at more than more than one dashboard for their day to day job for their operational metrics if they can have if it's a well organized organization. It's one of the ways I love to test. I think the ratio I've seen, which is kind of the worst ratio I've seen, oh, it's like it's like ten, like ten dashboards per employee. Yeah. The best I've seen is, like, is one to seventy. One dashboard for the entire or one report for the entire company, which I think is probably the others are probably far the other way around, but it's, it's just another sense of how am I doing here? Am I measuring myself? What was the, have I over indexed on a particular outcome, on a particular metric of production rather than just on a different measure of clarity or delivery, like clarity or impact or or revenue? Exactly. Sorry. I just wanted to add here as well. I think it's also reflected in in the feelings that you have on your team. Right? The team health you have is very much reliant on, breaking out of the service trap because everyone's demotivated. When you're building a bunch of dashboards, then you're not really seeing the impact you're having on a business. And, of course, it depends on your culture. There are some cultures in which this is totally fine, and that's not I but but I presume that's not what we're talking about here. But, you know, the the also, workload is huge because if you're answering all the questions from the rest of the business, you don't have time to have the strategic thought that you need to apply. And there's also, I think, another aspect of this where the rest of the business also tends to be very poor at truly understanding what it means to be data driven. Right? They think like, oh, I'm using data. Therefore, like, I see it in a dashboard. I use this dashboard every day, and therefore I'm data driven, but, like, that's not data driven. That is using I mean, that's reading data, which is which is nice. That's good. But you're not really comprehending it or taking action from it, and that's a very different ball, you know, kettle of fish in a lot of ways. And to so it's just to end this point, it's also key to transform the attitudes, not only on the team, also in the rest of the business. So we're talking about metrics. What happened is that if your team, as the data team, is not metrics driven, you cannot expect your business partners or stakeholders to be business driven as I mean, metrics driven as well, which is, you know, a huge problem if you think about the way a business is run. Exactly. I think yeah. I I think there's also a degree to which and, again, we'll we'll talk about this idea of, like, mentality. I think often, you know, going off and building the dashboards like that that ratio that you described where it was it was a very silly number of dashboards per employee. It wouldn't surprise me if the personality type of of kind of the analytics team there was actually, you know, they they found that quite a comfortable space to be. Like, you know, I'm I'm a technical person myself. I think most analysts are building out a a cool dashboard with, like, some sweet charts and some nice kind of filters and dimensions, but it's not as well. It's a lovely way to spend an afternoon, and it can be something that, you know, I guess becomes it it becomes a bit of a comfort blanket where you can say, well, what have I done this week? Well, I I have built this fantastic dashboard. I've done great. It it's somewhat tangible, maybe. It's a it's a it's a kind of quick fix. Yeah. It's the equivalent of, like, going to inbox zero. Right? You're like, oh, I did it. But then you're like, for what? I don't really it made me feel great, but it doesn't really matter. It's hard to say. So let's let's move on. Let's move on because we've described described the problem. We've described the problem in many ways, how it feels, the sense of lack of value, the sense of, looking for more tangible but indirect metrics of delivery, and the way that it can it's a reinforcement trap, which is tricky to move out of. Alright. Let's move on to thinking more about, like, the big question for both of you, but how have you broken free of it? Like, what does it mean? How did you and how did you start that? Like, you mentioned, Calum, for example, like, the mindset shift. Maybe we should start there. Like, what is the if someone wants to get more career satisfaction, wants to make sure that data is being to being valued, that data is moving forward, that it isn't just a transactional task that they're doing like a black box to the business, in a way an AI agent might be? How do they level up? What is the way to think about it? Yeah. The there's a range of things that go from very simple to quite complicated in terms of how you actually go about doing them. I think on the simple side of things it's about being fairly ruthless with yourself when you're kind of devising your own kind of backlog and your own work and how you prioritize your tasks, as well as saying what am I gonna be doing? It's about then saying and what is the point of that? Like, what is this going to achieve? What is this going to do? If you can say, well, I'm going to do this piece of work and outcome of that is actually will reveal an insight that I can take to this product manager, and it will allow them to make a decision on this feature that needs tripping, or, I'm gonna do this, power user investigation that's gonna surface, you know, a new type of user that maybe we didn't realize existed but are actually really great for us, great. Like if you can identify, you know, what is the tangible business outcome or even just like, you know, the potential tangible business outcome that comes from this work, fantastic. Go and do that. If you can't do that, then you probably need to deprioritize that piece of work. And it's interesting how just going through that little exercise on your to do list, this has certainly been true of myself, kind of of late, is just a really helpful filter in helping you just work on more impactful things. My experience with it has also been that it's helped me to take the step after in terms of actually seeing your work then have impact. Right? So, like, something that I kind of tell people I manage or certainly have done in the past is building, an insights deck or, you know, building out kind of a few charts that show or demonstrate an insight, like, that is your ground zero. Again, it's meaningless if that doesn't then go off and achieve something in the business. Right? There is something that you need to do as an analyst in order to go and make your work work. Yeah. And I think having that potential, that vision of this will be the outcome of this initiative or the outcome of this piece of analysis, like, quite clearly in your head before you even start, I think has been helpful in helping me to actually see that realization through. Yeah. So, yeah, that that kind of whole mindset that whole mindset shift of my work will have this impact or my work could have this impact has been has been quite a powerful just starting point. Yeah. So you've gotta have that desire to be different and desire to, like I think the way I've described it is if you think about the ad hoc and just sort of very quick example is when you get ad hoc requests or piece of work given to you, the number of people who if you ask them to think through, is this question a clarification question, or is it and how is this a well thought through hypothesis that I'm testing for you which can move the needle, or is it just them trying to understand what's going on because they don't they they give and build their mental model better? That's often where a lot of this comes from. A lot of the this back to the the model we've described here of the vicious so you if you identify that, a lot of the work you're creating is from yourself. As you build more reports, you get more questions. And, actually, it's about clarification what's really going on, what's actually happening. And then also people guessing. Like, give me some data so I can prove this guess I've made in my head in the shower. That's also a pretty big part of it. So the key mentality you said, Cam, I love that, is, like, I'm gonna make sure my work's gonna be valuable, and I'm gonna decide if that's true or not, not you, is a quite a big leap to make to actually better, therefore, interrogate the request you're giving and make and being backing yourself to understand the business as well as everyone else so you can discern what matters or not. And that's something you can work through with a stakeholder. Right? So, like, if you are in a model where you are a deployed analyst and you work closely with a product manager or or a director or whatever, like, it I'm not saying that that needs to be a decision that you need to bravely take on your own. Right? It's more like, okay. I can discuss the outcome with this stakeholder or this person. So it's it's it's more of a partnership in that case than in the example that you gave where, like, someone's just come to you and has just been like, okay. Now don't don't do this thing. Thank you. It's a more of a more of a conversation and more of a, like, validation between the two of you. So, Emily, like, tell me let's move on. How how have you what's been the catalyst? Like, you've made the you've made the you if you've seen the the the support function, particularly a younger organization Yep. What's been, like, the critic what's been the catalyst catalyzing starting points that you've built from? Yeah. I mean, there were a lot of shifts on the team that I had to deal with, and it was coming out exactly out of being a service function. Right? We were, and this is typical of a lot of start ups and scale ups to be fair. We were inundated with all these questions. We were getting or giving the clarity that we needed, especially giving. I think that's a very functional piece. And as a service function, what you end up doing is that you end up trying to wait, you know, for that, clarity to come. And then at some point, I realized, no. I need to make that clear for myself at the absolute least. I mean, that's also a that's also another problem. Well, not a problem, but it is a it is a personal trap in some sense as a data leader. I've seen this around the industry. Right? As a data leader, we have a lot of debate, I think, more so than anyone else. It's I mean, maybe product management, but it's a different kind of debate there. You know, as to what data is. And as a data leader, what are you responsible for? And I basically took myself out of that mindset, and I thought, okay. Regardless of whether I'm a data leader or a ops leader or what have you, I am a leader. And it is not it is on me. It is my responsibility rather to be able to have my own vision that's as clear as possible. And if that means prescribing what that vision should be for others on my level or up, then so be it. You know? I think that's another thing with scale up and start up. Things are moving so quickly all the time that if you're waiting for something, it's not gonna come. There's also a little secret where everyone's just trying to do their best. You know? Out. Yeah. Exactly. And so, you know, we're trying to look for we're looking that we're I always refer to a Spider Man meme where you point it's pointing at it he's pointing at himself, you know, himself in the multiverse. I know. And it's one of those things where basically, you know, everyone's just waiting for someone to say, oh, I volunteer as tribute to do those things. And the data team is actually in the best position to do so because we see the entire business. Everyone else is more or less siloed. Right? Everyone has has especially on a product led organization like MoonPay is, everyone has this idea of, like, I take care of this piece and I take care of this piece. Data is the only one aside from, you know, maybe finance in some sense, but that's a whole other this, like, perspective. They're not really looking at it from a point of optimization. They're pointing they're they're doing it from a point of, you know, what is the status quo? Let's make sure that's okay. And that's a very different, you know, kind of vision to say the least. So as a horizontal part of an organization, it is the data leader and my team's responsibility to tell everyone else, hey. This is what's going on, and here's what we recommend knowing what we know from all the parts of the business about what we should be doing from here on out. So I think part of it was that I was deferential in the first period of my time here at MoonPay. And as a result, it couldn't shouldn't have been surprising actually that my team was also equally deferential. As a leader, you know, it took me a long time to realize this, but, yeah, you are a your team is a reflection of you. And it's hard and that's what makes it so hard because when things are going wrong, you have to ask yourself first, like, what am I doing that is, you know, creating this outcome that is self optimal for a lot of people. And so that is one of the first things I did to make sure that we at least recognize a problem and then you can kind of, like, bring yourself out of that. And then it was sort of, and maybe this is a cultural thing or a personal thing. But once I have that kind of decision, I'm like, okay. Let's just start doing it. You know? We're just gonna own it from today. And so we, as like I said before, we made that transition to data science, and part of the new career progression framework is this concept of ownership. In the past, it was sort of like, who always the metric? Right? That's always a question. Is it the business who owns the metric? Is it the product manager? Is it, you know, x what? Is this this exec? What have you? And it's not to say that they don't have any skin in the game for owning the metric, but we're talking about who knows the metric best, how it's calculated, the impact, the model, and all the technical bits as well as all the operational bits. Right? It is the data team. It is the data scientist or analyst who's taking care of that area. And I had to make it very clear that this is also how it works on an engineering team. Right? Is that when you put out a feature, if we think about everything we do as a feature or a product, then they need to take care of those things if it goes if it fails. So the the, you know, the DBT run doesn't go, for example, if there's an error, there's a quality issue, that is on the analyst slash scientist to fix, and that is also on them to make sure they're communicating properly with the rest of the business. And so having that idea of ownership and truly trying to pivot on the identities of what analysts and scientists do at a company has been really instrumental. And this also enables people to be empowered to go to their stakeholders and exactly as you said, Calvin, like, be partners instead of, oh, you know, what do you want me to do? It's like, no. No. I'm telling you what you should be doing if you want your product to be successful. And that has basically been, very, yeah, very critical in the change that we're trying to make. Of course, we're still, you know, making steps because any type of change, especially at this level where, you know, you're basically changing who you are. Like, now I'm a person who goes to the gym every day. Right? You actually have to do the thing, and it's just trying to get into your head to, like, okay. Love it. I I think that's so helpful that you painted out a a very clear mental path for both of you have from, like, I wanna make a I wanna make a change, and I'm not gonna ask permission as I'm not gonna ask permission, and I'm gonna make the I'm gonna be on making the impetus. I'm not gonna wait for someone to give me a sense of clarity or a sense of purpose. I'm gonna define it. And I think the big thing that you've both touched on is the idea that the missing gap in most organizations is this how does everything fit together piece. Like, well, how does everything work? I've got you the data team is one unique strength more than even the executive team is that holistic view of the business. And therefore, the best way to break free to level up the role and the definition of this is to say, I'm gonna take ownership of making that holistic sense of the business clear. And then we call oh, I don't know you both because we call this operational clarity account, the idea of, like, mapping the business and the metrics, owning the relationships and the definitions and the owners, and taking the ownership of that piece of work. I mean, that's really that's a really good way that's a good way to start, I think. But the mindset comes first of wanting to take that wanted to not ask for permission, take that ownership is a key a key need state. And then you then you'll then lead the business, not be told what business wants. And, yeah, that's a really good way of putting it. And enabling your team to do the same. Right? I think that's also super key. It's, especially even from, you know, an associate level or an entry level up to the top, let's say staff. Right? I think there's a misconception that, oh, when you're less than senior, you don't have as much, sort of power to do whatever you need to do. I was like, no. No. That's that's not the case. Actually, everyone is empowered to make change as they should, and everyone does own a piece of whether it's the area or many areas. I mean, that's where scope changes with seniority. But when it comes to the ownership and the active ownership and what you're responsible for, that is the same across the board. And that is also another way to position, I would say, all of my my managers on my team. You know, we're they're positioned to be unblockers and coaches, not givers of assignments. You know what I mean? Like, there's a very big difference between saying, okay. We are the kind of team that tells you what to do. Because once you do that, then you go back to a service, like, being a service center. Right? You need to make sure that everyone on the team recognizes that they have the ability and capability, and, actually, it's part of the expectation that they need to push forward however they need to push. And, and and that, of course, comes with more technical skills and scope along the way, but the autonomy piece is exceptionally important. I love it. Cam, can you I know you've just you've just sort of joined a new a new organization recently. Can you talk through how you set up that to make sure that, like, the you're already working in a value led way. You're not in the support function mentality. I know it's been well received. Like, how how have you got about it? What's been the hero catalyst that sort of let you go straight away hit stick in the sand? Here's a way we can we can see things differently. It's a very good question. Yeah. So, I mean, for context, so I've been there for now about five months. It'll be six months at the end of the year. I think what I found when I joined was that there is an appetite or there was an appetite for the kinds of things that we've been talking about, but there just haven't been kind of a person or a team to to kind of go and make that happen. As it's happened, May is like there's a need to just build out a lot of stuff from from nothing. Like, I was not quite the date hired number one, but not too far off. So there is infrastructure work, and you know I have had to do some DBT work today unfortunately, but, you know, on top of that I think being able to identify a couple of those big business questions in the first kind of three or four months that had maybe been grappled with and had been hypothesized over some time, and actually just, you know, going away and being able to deliver, like, an insight off the back of that, I think, has been a nice way of just, like, whetting people's appetites for and this is what we will do. But, you know, once we're a full team, we'll be able to do that, like, for everyone all the time. So I think getting that buy in that way has been good. I think another thing I don't know if elephant in the room is is quite the right way, like, to describe it, but what myself and Emily have both been describing right does make the assumption that you have analysts in your team and in your business that are kind of capable of this way of working in this mindset. And actually, like, it's not a given that every analyst does. Like, you know, there are a wide range of personality types in that space and, like, you know, this way of working autonomously, thinking much more about business impacts and that kind of thing. Like, that is a a specific strand of thinking that actually, like, has been something that I've been quite conscious of when I'm interviewing to build out my team. Right? Like, that is that is something that's gonna be a long term payoff, but it it is it's it's not making hiring very easy because it's it's, you know, it's it's quite a fine filter. But, I think that's another important thing, like, you know, having the right people in place in your analytics team as well as, you know, facilitating everything as as the leader of that team is is also important. That's great. Yeah. I think it's the, that cultural element of it and leading that. It's a I often talk about it myself as, like, it's a as you describe, it's a loop. It's a feedback loop, but there's a virtuous cycle here. Like, and and that bumps that's a cultural cycle as well as it being kind of an asset cycle as well. So one of the things which, just to sort of point to is, just as a tangible example of what we're talking about here about operational clarity, here is an example which I know that you both of you have engaged with and book built. This is obviously built in count. It's the metric tree view of the business to show monthly revenue, breaking it down so everyone can understand the metrics and how they fit together. This is a one off exercise that you can do, but that is the wrong mentality. The mentality is to continually evolve, paint a clearer picture, be with your analysts, and show them this new way of doing it, and then evolving it and building a better understanding, a better cadence of it. So it's not a one off exercise. It's a continual educational thing. And it's like, just like you can do the service trap less or more, you can also do value generation more and more by mapping the business better and more clarity, problem solving areas better with more clarity. So it's it's there's a mindset shift. There's a cult there's a capability challenge there. But there's also just getting into the as as Emily said, getting into the heartbeat versus starting, getting going, and recognizing that maybe the place to start is playing to the strength of the day, which is that holistic view and then playing that back to the business in a in a clearer way, I think. Yeah. I think there's, sorry. We'll ask this about the metrics that would and I guess we're going to talk about this a a little bit later. But, yeah, the the clarity piece is as well very important. Right? I think that's actually what part of where it started where I came back from a period of leave. And I was sort of like, okay. Let me just take this as a reset of where we are at We'll bring it back now. Where the team is at and so forth. And, and this was around the time that you and I, Ollie, had started talking about count, more seriously. And it essentially came up to me where I was like, I don't even know what's going on in the business. So if I don't know what's going on in the business, how can I expect my team to? Right? And that goes back to what I was saying before. But Metrix Tree is also super helpful, not only for providing clearing for the business, which has been used in OKR planning and all those things at the business level, but also to assign ownership. And, again, going back to the ownership piece is to say each analyst or scientist is taking care of at least one of the branches on the tree, and that is their area. Right? And it was also this is the hardest part of the management part, which is similar to what you were saying, Calum, was to say was to hold them to that. Right? There's a element of necessity to hold the bar really high when it's been implemented in this way and to make sure that it is very clear amongst your team that that is what is required of their jobs. It's no longer about, oh, I made, you know, ten dashboards. I'm like, did it move anything, or do you even know what you're supposed to be moving? That is a big question. And so that also helps, you know, in some sense of being able to understand also where people's strengths and weaknesses are. Right? Some people are a lot more confident in that. Some people are more willing as well. And so there's also a teaching moment in a sense to be able to, you know, pull any levers you need to in order to get to the best possible outcome. Yeah. That's that's great. I I think we should just move on and talk a bit more about the value framework. I think that's a contextualized, sort of summary of, like, the answer. We've been talking around it, and I think let's bring it bring it sort of down. So this is, something I've discussed with both of you before many times, I know, the idea of, like, what is the alternative to the service trap? What does it mean to run a data team which is, like, driving impact and working differently? And the the there's sort of there's four principles to it that we we we subscribe to, and I think it makes a lot of sense as a as a sort of value framework for those watching. One of well, the first one of those is back to what we talked about, the metric trees, which is seeking operational clarity. The idea that rather than just pumping out information as and when you need to and creating this fractured view, you can do things like building metric trees, mapping out your business, put playing to the strength of the existing holistic view to create clarity and it and produce this sense of what's really going on. The business feels simple to everyone and everyone understands their role in it. And that's a leaning in more from a data team perspective to a bigger ownership level of, as you described, Emily, I'm gonna own how the grow how the operating model works, how the growth model fits. I'm gonna make sure it's visible and clear, and I'm gonna make sure that's that we have that sense of truth. Not just the numbers are correct, but the actual hierarchy of our business is correct as well. And that that is anything on that point particularly got you guys that you've you've experienced or has that been something which you felt has been key to you? I think, like, definitely in the context of joining somewhere recently, like it's a very helpful kind of opening exercise even for myself just to, like, have an understanding of those things. I think for the business more widely, I mean, the the classic example of how this can be used effectively is helping to prioritize the biggest needle movers, if you'll forgive the the metaphor. Like, it's it's a way of saying, okay. We've been kind of a bit fixated on this particular rate, which is cool. Like, I can see why more of that conversion will be better. But, actually, like, the overall impact of that compared to this thing over here, which we've been completely ignoring, is actually kinda small. So I think as a a way of prioritizing business goals, I think that's it's also, like, a a really useful thing to be doing. And, like, that's a, you know, a clear example of, like, an impact that that the analytics option will be having. Yeah. The biggest I think I mean, you mentioned this before. The biggest assumption is that we we think that the business understands us already, and the answer is they don't. If you're not giving it to them, if you if you're if you're not clear on exactly the structure and how these metrics sit together, if the data doesn't have that clarity, this definitely doesn't exist in the business. And that's the ownership piece of saying, I need to make sure that if I I get this clarity for myself and I could produce it for the rest of the business because no one has got this clarity. Exactly. Yeah. That's the model I basically worked off of. Right? Is that with the first metric I've I've been asked a few times, you know, oh, who did you get involved to create the metrics for you? Honestly, we already have our North Star, you know, for, at MoonPay determined by exec leadership. So at least that part was fine. But when it comes to the tree in and of itself, I limited it to just my team because, ultimately, we are the owners, like I said, and we are the ones who are in charge of pushing these things forward. And we also have a case of, too many cooks in the kitchen quite often. So once you start to open the doors, everyone's just gonna fly them with their own opinions. And not to say that they're not valuable by any means whatsoever, but, again, we don't they don't have the same visibility about the rest of the business as we do, and so we have to have faith. And I think there's a few things that we have to think about, like, emotionally in some sense. Right? It's like faith and being unafraid. And being fearless is very important, especially if you can go back if you go back to the the slide with the timing. Yeah. So measuring yourself, I think this is super key. This is also something that we're talking about, like, data teams. I think the DBT, survey, right, says, you know, most data teams don't measure themselves in the same ways that they actually have a double standard for holding other teams to, which is ironic in a lot of ways. And so I basically told my team and said, we're using the same KRs as the rest of the business. We are responsible for increasing, let's say, like, transacting users ourselves. If we can't do that, we can't expect anyone else to do that. You know? And so there is also that, fear you have to break through because it is scary to be held accountable. It's scary to hold yourself accountable. Right? And, I mean, again, going back to go to the gym, it's like, okay. I want to I don't know if anyone here has run a marathon, but it's scary. Like, oh, can I do this? Forty two point two kilometers. That's a long time for anyone to be running. But I think I'm just gonna and it's scary to hold yourself to those things, but this is the same thing. And there's, there's a tone you have to set for your for your team as well as for the rest of the business to say, we are unafraid of holding ourselves to this this bar of having these targets. And the funny thing is, like, even if you don't hit them, no one's gonna die. Let's be completely real. Right? It's not as dire as one thinks in their mind when they go to set these goals. Also, most people, if you have the if you know your team and you've hired well and done performance management, especially, right, is that they are more than capable of doing this. And being able to push them and to be able to push yourself to say that is what I'm holding myself to makes a huge difference as well. So all those things coming together really, yeah, kind of make sure that you're kind of coming from a place, I think, that is, again, not deferential to anyone else and that you are steadfast in some way about knowing the value of yourself, your data, and your data teams, you know, sort of role within the business regardless of what anyone else says or thinks. Yeah. I love that. I I often talk about the idea of, like, the the parent child the parent or parent child adult relationship model where the one way to describe the service trap is you have a the business is the parent and then the data team's the child. What you want is an adult to adult relationship where you appears and you're wrestling through this. I completely agree. Let's I'm just gonna finish off talking to the different tenants. We've got operational clarity. We've described described example of that with metric trees painting the growth model of the business making, not just the metric definitions, but visualizing the data and the business together. You've then got the business solving business problems. So that's again leaning into not just providing the data to someone else's question, but actually trying to frame and think through the problem with them. So you're not just that's again stepping out of the stepping growing the role into a critical thinker, not just a chart producer. The third one here is then minimizing time to decision. The idea of not just providing self-service and letting people go and do data as they want. You're actually thinking through the pros the decision making framework, the decision making process as a whole. What is the right day to prop to the right time? How do the business need to work with the data? So you're leaning into a broader definition of, decision making and that process, not just, again, the data input. And then as you mentioned, Emily, the fourth one being measuring yourself and not having a double standard, that you're working at how much time you're spending on value add activities versus the important but not, directly valuable, like, maintenance, side of things as well. And those are the those are the those are the principles that define a elevated role where I think in one way to put it is that you're sort of stepping forward more out of the the just providing the data, but actually saying I'm gonna provide more than the data now. I'm gonna give you a better way to problem solve, better way to see the business, a better way to think and make decisions, and I'm gonna hold myself to account as well about how I'm doing it. So that's the value I know we've put this before, but just for those watching, this is the way we often describe, like, the difference between a service support function where you're sort of servient to the business and how it means to work in a way where you're you're you're an adult to adult peer to peer where the that basically means taking more responsibility effectively for how the business sees itself, how you and you're helping them solve the problems they need to and make decisions as a result. We're running out of time. I've I've talked too much. It's been wonderful to talk to you both about this stuff. There's so much to say on this topic. We're not gonna get through it all all at all, but after after you get this recording, check out the blog. You'll see a lot more about this kind of topic, written up in Calm, but also, on the wider social media, sort of networks. You should go and follow Cam and Emily. They talk about this stuff a lot. I know it's very much very passionate around making this happen. Is there anything, Abi, as we wrap up, both of you, that you think is an important, like, takeaway that people need to to buy into? But there's, like we talk about where to start, but, like, what is the kind of unlock in the head or the one thing that you think people should take away from this discussion around service trap to value add? I think the point the point around rigor with understanding the impact of a piece of work or understanding the potential impact of a piece of work, I think, is is the thing for me. I think it's with the gym analogy, it's something that's hard at first, but you kind of get into the habit of it. And I I think making that a habit is is just such a helpful kind of first step to be taking. Thank you, Kel. I agree. I think, part of it is yeah. Exactly. Solution first thinking. Sorry. Problem first thinking, solution design driven, if that makes sense, so that, you really don't like, you feel free to question everything. Right? I think that's another thing too. I think data because data takes so many different formats and there are so many different practices within data, you know, whether it's analytics or science or or analytics engineering or engineering in general, we, I think, suffer from an identity crisis within the industry. And then when we receive these roles or we get put into these roles of leadership, it's super easy to kind of come from a frame of reference where, oh, I'm expected to do this, therefore, I'm gonna do this. It's very important, I think, Calum, as you came into when you when when you might have said, Ome, it's like, break free from that. You know? Don't think of it as I am a data leader. I am and like I said before, like, say, I am a leader in this business, and I have data forward, you know, solutions, but they don't also have to be exclusive to data. Let's just make that clear as well. And, yeah, I think that's the main kind of takeaway, and that's also where you can just empower everyone to do the same. That's cool. Thank you. Yeah. I I love that endpoint that you're actually a leader. And if you have that mentality, then the rest of the organization and the rest of the business will treat you as a result. And you've got and then your strength is the holisticness of it that you can bring what else can. But both of you, I'm so grateful you spent time with me. We've run we've way run over time. I could've gone taking taking way more time on it. I just wanna bring up your names so people can find you on social media if they wanna dig in more. I'm really grateful to you. I think I we've we've run out of time for questions. We're gonna cut the webinar here, but we'll answer questions. Everyone has them in the chat offline, and, otherwise, we can follow-up online as well. Thank you all, and thank you, Emily.