DataCamp Webinar - The 4 Tenets of High Impact Data Teams

Hello, everyone, and welcome to today's session. I am Reese. I'm not Richie. I will, yeah, be re hosting the session in his place today. I do have some good and bad news that I will, dispense out to you very shortly, and then we'll get into the session. But, yeah, we'll just wait for everyone to filter in from the waiting room, and then we'll get started. If you haven't already, please do check out all of our future sessions at data camp dot com forward slash webinars. I will tell you what's coming up early next week. We have on Thursday oh, we're actually quite late next week. Next Thursday, we have, enterprise AI adoption in regulated environments, and then the week after is where we, start to get into our August calendar, which is pretty stacked. So, the week commencing August fourth, we've got grounded via coding with MCP and QDRANT, or Quadrant. I don't know. Pricing and monetizing your AI products, that's gonna be a really good one. And then, the following week, we've also got creating a podcast generation AI multi agent with CrewAI. So we've got quite a lot of, cool cutting edge code alongs. Please do let me know where you're joining from in the chat. It's always good to see where you're joining from. We'll wait for a few more people, and then we will get started. But to the good news and bad news. The bad news is Richie's not here. I'm here in this place. Richie is still out hiking the Appalachian Trail. So, yeah, please do wish him well. And if you're in the area and you see a gentleman with no flashlight but still making his his way down the trail, that'll be Richie. The good news is he's back next week. So, yeah, if you attend any of our sessions next week, you will have, the glorious Richie back as your host, and you won't have to put up with me any longer. With that, let's get started. So, thank you so much for joining the session today. I am Reese. If you've not seen me before, I'm usually backstage moderating these sessions. Now, the whole point of having a data team is to have a positive impact on your business. While many data teams, profess to be impact driven, the reality is that everyone spends too much time creating dashboards that no one looks at. So today, we're gonna look at some principles for managing a data team to ensure that you can achieve genuine business impact. Our guest is Ollie Hughes. I will just bring him on stage now. Welcome, Ollie. Hello, Reese. Hello, everyone. Nice to see you all. Lovely to have you, Ollie. Ollie is the CEO and cofounder at Canvas based BI platform, Count dot co, and he's building a company to help increase analytics team's effectiveness. Ollie started the company after a career in public service consultancy. So, yeah, with that, take it away, Ollie. Thank you so much. Thank you, Reese. Thanks, everyone. Nice to see where you're all coming from. I am based, in not so sunny London. As you can probably tell from my accent, I'm just based outside of London. I'm in London right now, and it is gray outside, which is a bit of shame. But today, we're gonna talk about, data teams, data teams ROI. What what is the point of a data team? It's a question that I think if you are honest, if we're all honest, we're often thinking about it as an industry. What is the purpose of a data team? What's the most valuable things that a data team could be doing on a given day or week, what are the kind of North Star metrics of a data team, and maybe thinking further ahead, more complications happening nowadays in a world of AI as we look forward to a world where AI is maybe a a primary tool we're using to distribute data and insights, what does the role of a data team or the role of your team look like? These are big questions. These are questions that I've been thinking about for a number of years. As Reese mentioned, I have been working in data across, public sector, but also in retail, in FMCG, in manufacturing, lots of different places looking at data and how to use data to drive, drive businesses forward. And so my hope today is that I can leave you with a framework a framework of kind of value, a way to make sure that whatever you're doing, within your roles, within your teams, that the work you're doing is is driving your business forwards and hopefully gives you a mental model of how to think about that, which you can you can turn to. This is a piece of work that we haven't developed alone. It's been within hundreds of different data teams we work with this framework on, so I hope it'll be valuable to you as well. If you wanna talk to me afterwards, as I said, you know who I've I mentioned who I am. You can find us at count dot co, or my email address here is ollie at count dot co. You can feel free to ask me any questions if you'd like to. But to kick off, and to sort of set the scene, I wanna take you back to a period of time which shows my age. I'm gonna take you back to two thousand and fourteen, but it could be any real, it could be you know, so over a decade ago, when this is our, this is our this is the data stack you may be if you're working in data, you may have been used to. There'll be data warehouse which is coming on board. We had a BI tool, and we were using that BI tool to get information to the into the business. And at that point in time, the biggest problems facing a data team was that we that we would if you're if you're working data at that point, you would drown in ad hoc requests. People are asking for more information. If people were looking to use data to make their jobs better, they they wanted to use data. That mean you'll be flooded with information as a data team. You're building dashboards that no one's really looking at. That's another big problem we found. People were building dashboards, trying to work out how to get the business to to find the dashboards useful, and you're trying to get them to do more self-service. You're trying to get the business to to try and do their own exploration. And it felt back then if you were like me working in data at this point in time, it felt like no one that no one really feels that you're directly confident to the company's growth. You're just on this kind of hamster wheel of ad hoc request and dashboard building, hoping that you can influence the business in in in small ways. So that was over over a ten days ten years ago. Hopefully, that's not gonna cause PTSD to anyone here who was working back then. But let's talk about now. Where are we now? We've certainly got a more complicated data stack now. We've got better data warehouses, cloud hosted data warehouses. We've got things like DBT for managing our business logic. We've got loads of orchestration tools and catalogs and ETL tools out of our ears. And we've still got the same BI tools, and our biggest problems remain that we're drowning in ad hoc requests. We're building dashboard on what looks looking at, and we're trying to make self-service possible. And no one really feels like we're directly contributing to company growth. So the irony is that we probably spent, in real terms, I think, a number of factors more on our BI data tooling. Big data has driven that. But have we actually solved any of the big problems that we were facing ten years ago? Certainly, some some things have been solved. But broadly, if we're being honest, if you've been around data long enough, we haven't really cracked the way to turn that data into in analytical terms into real business value. That is the premise which I'm coming to this presentation with, and I'm coming with a way to think about how to unblock this problem. So I hope this is intriguing to you. If you can if you have been in data long enough to sort of be jaded a bit about this, this might be something which hopefully resonates for you. I'm hoping it could be valuable. The what I wanna pose as the kind of summary of this problem is that in data as an industry, we're stuck in a service trap. We are stuck being out of service to the business. We are a as data teams in general, we are seen and behave like a support function to the the goal scores in the business. And in some ways, that is true. That will always be true in some ways, but the goal is how do we become less subservient to the business and how can we lead the business? What is the role that we can take as data teams to lead the business to be more effective and then make our ROI as a beta team, be better? That is the problem that we we came to with this, with this piece of work. And I'm gonna pose this to you as that there are four parts of this service trap. I'm gonna show you the problems that I think we as a industry suffer under. Firstly, and I hope these resonate if I hope they don't, but I'm sure they will. The first sort of service trap, the first way that data teams get into this kind of support function mode is that we're drowning the business with information. The organization has access to more data than it can handle, causing confusion, operational bloat, and a fragmented understanding. What I'm saying here is that if you go back ten years or more, maybe into the naughties and I was just coming to my career, there was a real excitement of just getting data into the business. That business could just, just wanted more data. We just had data was a new thing. Getting data out there was a was a was a real primary driver of value, but we are in different times now. We're in a point of time right now where every single product, every software piece of software we're using is is full of metrics. It's full of data. Everyone's got access to data, more data than they can cope with. We're flooding with it. And the problem is that as a data team, we often are flooding a business even more information. And that is a real challenge, and we'll come on to why why why that's a challenge in a second. The second problem being in a service trap is that we see teams who are trying to they are optimizing around being able to answer every question the business asks, that the data team is seen as a portal of information. Give me that CSV. Help me understand this problem. I need to understand this data, please. And almost by nature, the data team are seen as a CSV portal, a chart building function, a way for the business to get to look at data, which underutilizes the skills of the data team. This is another way that we as an industry have fallen into a trap of being a service function rather than more value add. The third big trap that we fall into is this idea of minimizing time with stakeholders that partly because we are flooding flooded with requests for more information, flooded building dashboards to try and give as much insight as possible to the business. We actually retreat back and try and build barriers between ourselves and the business to say, give me a Jira request. Give me a ticketing system. I will answer it via I will almost go down to being a black box and say, give me a Jira ticket. I'll give you a chart. And we are minimizing time. We're setting boundaries of responsibility between the operation and the data team, and this this makes it more of a transactional relationship. Another sign that we're in a service trap. And then fourthly, one of the big challenges of as an industry, which I see again and again, sadly, and I have many, many stories about this, is that we often as a data team, because we're flooded with the with requests, because we're overwhelmed with information business is requesting and we struggle to do the work we know is more valuable, we actually find ourselves optimizing things the business can't see. We spend our times making our SQL as efficient as possible, minimizing the amount of database load we're putting on our data warehouses, minimizing cost there rather than saying my time is best spent, helping the business grow. So I don't know how this resonates or not. Maybe you should send me an emoji if if this is a a thing you resonate with. But this is what we define as the service trap. Thank you for I think we're on a group therapy session now. It's wonderful. This is the service trap that we are in. This is the service trap that was true in two thousand and fourteen, and it's true in twenty twenty five that this is the way we what we work, and this is the way that by default we work. It's it's understandable we're in this position. Just to make this more tangible, this is sort of five very simple pulses for the way, five checks that you know you're in a service trap. They aren't they aren't the full checklist. If you resonate with the things I said before, this is this is key, but these are five ways we know we have seen our organizations, work out that they really are a service trap mentality. The first one, is your dashboard to employee ratio close to one? As in, do you have as many dashboards as you have employees? That would be a sign that you have more information flooding the business than you than you need, than business can cope with. Does your team feel swamped with ad hoc requests that you feel unable to challenge the business about their value? That would suggest that you're answering every question the business is asking you. Does your team spend most of its spare time developing new technical skills? This is one that does make me won't make me popular with the data data get data camp team. But if we are just solely focusing on making ourselves more technically competent and efficient rather than so focusing on how to make ourselves more valuable to the business, helping the business grow on the soft skills that allow us to influence the business properly, that is a sign that we're becoming a we're boxing ourselves into a technical function rather than a business an ROI focused function. The fourth check here, your data team is spending more than forty percent of its time maintaining operational reporting and data quality. Now don't get me wrong. At some phases of of a company, you need to spend a lot of time on data quality. Getting up to certain level of of of competence is important. But if you're spending, close to half your time just maintaining that sales dashboard that people look at to know the business is alive, that isn't a good use of your time. You wanna be minimizing it for as much as possible. You're only spending as much of your analytical team's resource on the problems and the questions that let your business to grow, not just maintaining status quo performance. Does that make sense? And then the fifth sign you're in a service trap is that your CEO, your exec team, your main executive sponsors cannot list three ways that your team has directly contributed to growth in the last quarter. There's a question to ask you on next one to one. What are the what are the last three things you think have really helped contribute towards growth? If they can't give you definitive answer, then you've got a problem. So four four service traps, four ways we work, which devalues our team, makes us into a support function, makes us into a black box that the business uses rather than as a team who are on a peer to peer relationship with our partners and different functions. Five very simple checks that you know you're in a service trap. Hope that makes sense. So how do we break this cycle? The cycle that we've had for over for for over a decade for over a decade at least. How do we break this cycle? This is the question that we've been posing. What if there are four service traps, there are four ways that we devalue our work and make us less valuable to the business and make the business not understand the value we can contribute by just giving them information and minimizing our time with the business, what are the tenants that will allow us to be high value data team? What are the ways of working which are the the antidote to this service trap? This is the question that I have been working with with hundreds of data leaders, mostly in Europe and also the US over the last twelve months. We've been building a methodology here of some of the people, not all of them, who've been involved with this piece of work, over a hundred I've interviewed a hundred day data leaders and more on how they drive value with their organizations. And I'll be honest, it's been a relatively empirical piece of work where I spoke with people who clearly know they are or clearly operate in a very high value way, and and, like, being talking to people who obviously know they aren't and trying to look at the differences. And it's been a for a for a data person and for in the data audience, you have to acknowledge that sometimes an empirical approach does work, and I will talk you through where we've landed. But this is not me telling you. This has been a thing that I facilitated these conversations, build a community around these principles, to allow us to discuss this, work this out, and as a community to develop what is the purpose of a data team, what are the activities that we should be doing. And as I hope you'll see as we go through this, as I mentioned at the start, these are ways of working which are, which are defensible against AI as in, like, these are always valuable activities, which an AI can help a data team do more of. And it and that is probably the most powerful proof of this is that these this is not I can replace an analyst with an AI bot to answer questions for the business. This is this is a thing a human can always be doing to be better where AI can help. And I think that's been a really powerful test for us as these are universally true, and an AI isn't gonna replace these activities or these methodologies. So I've spoken about it enough. Let's run through them. Let's discuss what are the activities, what are the tenants of a high value data team. I'm gonna start with the first one. The first one is a thing which I think having gone through this hundreds of times, I know this is the thing which is probably the most surprising, the biggest concept. So listen in. This one I hope is I'm gonna say as clear as I can. The the core value a data team can bring is to seek what we call operational clarity. What I what I mean by that is that rather than drowning the business with information, more and more dashboards and reports, the goal of a data team is to make the business feel as simple as possible. So you what you're doing here is trying to create a common operational context with clear business priorities. You're trying to make the business the business the wider company have a clear alignment about what's what matters, how the business works, how it fits together with the least amount of information needed to get to that picture. In in in a sort of I used to be an engineer. I, and the concept here is a high signal to noise ratio. Max amounts of in of understanding and insight with the least amount of information to do that. Like, make the signal strong. If a data team is doing this, it's focusing around clarity, focusing around helping the team the business understand what matters and and allowing this to understand itself really clearly, you are driving the most value you can into your organization. The data team, thankfully, because of data warehousing, is the best place to function to give the business to to pay the business clearly to itself because you have all the data. So a test for you here is if as data teams, you do not know what's going on in your business or how your business is operating, There is no way anyone else in your business really does either. They may pretend they do, and I'm sure the CEO pretends they do, but they definitely don't have a good vision of vision of what's going on. And so what we know from looking at the most valuable data teams in, in in many companies that we've seen is the ones who are working hard to minimize the number of charts in the business as possible as it were or making sure the charts they are using are incredibly intentional to create clarity and focusing on that as a key metric are the ones who are gonna light up their business. An example of that, as you can see here, is on the right hand side is what we call a metric tree. Now metric trees are a kind of well, they often call KPI trees. You may have heard of this. This is an incredibly powerful tool for showing KPIs in context, showing with the way that you have this hierarchical plot. You're showing how metrics relate to each other, and you're basically paint painting the operating model of your company to show what matters and what's going on. It's a I mean, hundreds of times of what we've heard, what they have told us that when they've shown this to the CFO, the CEO, the COO, and said, I thought you might find it interesting to see our business this way, you almost hear this mental sigh of relief where the executive suddenly sees their business in a way they haven't done before where they feel clear. So operational clarity is an amazingly powerful concept, which, is a kind of bedrock of this whole principle. It's about the antidote of rather than drawing business information, you are making that signal to noise ratio strong. You're removing clutter. You're removing noise. You're removing duplication, and you're trying to paint the performance of the business as clearly as you can. Now there are other ways you can achieve this. Doesn't have to be a metric tree, but that isn't that is one of the best ways you've seen it done. There are other examples of how you can deliver operational clarity, but across t TPP, technology process, and people. One of the ways you can do that if you look on the right here on people is running regular training with your data team on best practices for concise communication. That is a very small way that everything that your data team is building, they are communicating clearly and concisely. That is an that is obviously a lever of a way to drive clarity into the business. It's not the high impact way, but it's a very sensible way to get your data team to be far more effective in how they communicate and drive clarity. Another way of doing this is obviously to have a named business owner for every single operational report in circulation. So there's owners of assets, and they are the ones owning the KPIs. There are a lot of ways that we've seen organizations when they, like, get the principle of operational clarity, how they can adopt it in big and small ways. And it really depends on your context and what and your stakeholder map and how where you are as a business and your maturity to really determine what is the best approach to start. But we what we do know is that this kind of metric map for you of how our metrics fit together, that is an incredibly powerful high impact way to get there quickly because you'll find your executive team leaning in and grabbing that very, very hard when they are finding you giving them a mental picture which is clear and concise in their brain. If you have any questions on operational clarity, please write them down. We'll come to them later. But I I think I hope that makes sense. I know it's a very high level principle, but this idea of, like, how am I making my business clearer is the kind of driving force that we know teams who wake up and think about that are are always adding value. The second tenant, the second principle of, high impact data teams, is a is a is a thing which we will already know but maybe not doing, which is the idea with the high impact data team is one who is solving business problems rather than answering every question the business asks. We are all in data probably because we love solving problems. We love that rush of finding an insight which we know is gonna change our business in a positive way. That is why I want the data. It's why I think every person I spoke to generally gets the data, and solving business problems is is one of the things that we as data people are really good at. The big challenge is is if are we doing the problem solving or is the business. So the big lift, the big difference between, doing this well and doing this not well is are we helping the business think through problems? Are we leading them and facilitating the problem solved? Are we just an input to their problem solved? So let me explain that better. When we get asked a a request from an executive, we often do a problem solve in our heads to think through what they're asking for, what's the way to go solve that problem, what's the best query to write, how do I make sure this is accurate. We're doing problem solving already. The question is, other than just doing that problem solve, how can we make sure that the problem solver's going on in that executive's head is done well? How can we take the problem solving sort of the the problem solving out of that executive's head, which is usually very fuzzy, and make that problem solve clear as possible to the to the executive? Help them think clearer. Help facilitate their problem solve with them as partners rather than just that they're asking us for data which we give them in isolation, and we hope their mental model in their head as their in the shower is forming. We need to take a bigger lead towards facilitating that. So this is about treating the the analyst particularly as specialist problem solvers. We are very good problem solvers. How can the business understand that and use us? And that requires us to lean into the business. It requires us to have good domain knowledge. It requires us to when we present back to structure our thinking of what we how we've tackled the problem, what we think they're asking for, not just giving the answer. And it's about developing soft skills equally technical ones. This is what we're seeing the high impact data teams doing is they are effectively becoming the hit squad of their business, the people who go and solve problems. Maybe you're doing this, but the the challenge is often when you're asked for data as a team, are you doing the problem solving or are they? That's the big that's the big question. Again, other ways you can achieve this, you can create a progression ladder for data analysts. One of the things I would if I could die on one hill, I would love it that that that data analysts had a career path as well mapped out, and is getting as senior as you could do in data engineering or in data science or analytics engineering. Data analysts have a equally valuable skill set, which often I see them going to more technical roles because they can see a path of progression. If you could do anything with your your org structures, that'll be great to know that there's clear about clear progression ladders for analysts to become senior analysts to become lead analysts, to maybe becoming a staff analyst who is working directly for the CEO, for example, and with their their their soft skills, their communication skills, their statistical knowledge is being valued as a problem solving resource for the highest levels of the business. When I've seen this done well, usually, as they go up that ranking, they are reporting to a staff kind of the the the kind of trusted adviser of a a VP, an SVP, and a CEO, and and that's the org structure you want. You want a data analyst to be sitting alongside these people, helping them think. That's one way that you can really enforce and encourage great problem solving from the analytics function. There are other things on this list that you can come back to and read over later. But the principle here is, are you a problem solving function? Are you a reporting function? Be a problem solving function, please. So the third tenant, the third tenant is the best teams are minimizing time to decision, not minimizing time with stakeholders. What I mean by this is that a data team is taking ownership at least in some way of the decision making processes across the business. What data teams shouldn't be doing is saying, my job is only to give the data to the business and how that business how the business uses that data, in what forms to make what decisions is not my responsibility. That is a that is that is not the job of a data team who's succeeding. A data team who's succeeding is looking at what decision the team made or happening in the business, working out if that workflow is efficient, working out where to interject data at the right points, or even automate away decisions if it could be done by machine, but thinking about decision making holistically in the business rather than just saying, my job is to give you data that you can do your own jobs. That makes sense. You're almost trying to think through the process of decision making and putting the right data products in the right places to maximize the the speed of decision making. The best the KPI here is the speed a great decision is made, and that isn't about self-service, just about. That could be about doing, anything. That could be about making decision in an automated way or strategic way. To give you a good example of this, one of our customers' account, is a very, very well known dating app, and they, have a board meeting. I think it's monthly, I think. And they used to, you know, do a board board board deck for the board to discuss, and they realized as a data team that the board weren't really making decisions in the board meeting. They've received the preread the day before. They'd read it, and then they'd spend time discussing the numbers rather than making decisions. And the data team realized or made the decision to give the preread a week earlier and ask for feedback the week before the meeting took place. And with that simple change at the most strategic level of business, the board meeting's ability to make decisions increased dramatically because they could share some information that different members of the board could ask questions, understand that, get the understanding correct, and then come into the meeting and make decisions. So that subtle change, thinking of the process of decision making at even that most strategic decision making level unlocked a lot of value for that business because they can now start using data the right way and in the right form. So the it's not just about self-service. That's I have no self-service happening there at all. That's just the data team thinking about, I'm helping the business make decisions better. Am I finding the right information the right way at the right time and optimizing for that? And that could be, as I said, operational decision making. That could be, like, automating away human involvement at all in the most tactical decisions. And it's so think about the also the most strategic decision making. How can we help that? And and minimizing the time to decision is a great KPI to think about rather than just think about the data team's capacity. Hope that makes sense. I'm gonna move on to the final the final tenant. The final tenant here is the idea of measuring yourself. So that rather than a data team optimizing things the business can't see, the data team should be constantly working out if they're applying their resources to the most valuable problems of the business. To be clear, I don't have a formula for what data team ROI is. If you're looking me to give you that kind of metric that you could say pound per chart or whatever it is, that doesn't exist. What we found is that the data teams who are thinking about their allocation resource almost don't need to justify their ROI because they're already thinking about it. It's the ones who are can't articulate their allocation of time to the business, the ones who just justify ROI more. It's kind of a catch twenty two scenario. What we're saying here and what is often true in most businesses is that the data functions payroll, the headcount, is often ninety percent of a data team's functions costs. Time, not not database load, not tooling or software licenses. It is time spent on the data team, the salaries of the data team, which are then by far outweigh any other cost in the business. So if you can't articulate where that time is going and minimizing time spent on, like, day to day hygiene and data quality and maximizing time on, we've put one analyst full time on this critical business problem and you can't articulate that to yourself, that you're not working the result from where you can be. And it it's it's a mentality. It's not that you're gonna justify it necessarily to anyone. It's just knowing that you are you cannot you can justify that your time is being spent in the right locations. And the teams who are thinking about that all the time, it's a heartbeat of how they think are the ones who are often doing it. So a few examples of how you can make that measure yourself easier. Telemetry and tool usage, really powerful. Keeping a log of the ad hoc request you're receiving, who they're from, how important they were so you can work out if you're spending time in the wrong places and are these questions valuable. Having a daily, weekly pulse with each team member explain what they're working on can be helpful. What I'm not advocating for and what I haven't really seen much is like a time you know, like, every six minutes or every hour of my day is blocked. That is a bit extreme. It's more about that kind of resource steering, whatever that resource steering thing is that you know you're working on the biggest problems in the business. So we've talked about the service trap. We know that we don't wanna drown the business with information. We know that's painful. We know that instead of drowning this information, we should be seeking operational clarity, creating signal from noise, removing confusion, aligning the business around a common set of metrics. They can all understand how what what matters more by more more themselves. Effectively, you're painting the the the operating model of the business within data. Rather than answering every every question the business asks that the data teams are solving business problems, rather than minimizing time with stakeholders, data teams are minimizing time to decision. And rather than optimizing things the business can't see, data teams are measuring themselves to know they're working on the best most important problems the business is facing. These these tenants, these four tenants, as I said, I know work. They are high level. They apply to any data team who is any analytics team working to drive better decision making in their organization. They are high level, but I they are high level enough, but I think tangible enough that hopefully you can be thinking about what this means on a day to day basis. There are many ways to achieve these tenants. These are never ending goals. You can never tick off operational clarity. This it's a guiding principle, a tenant that you know that if you're keeping striving towards operational clarity, solving problems, minimizing time to decision, and measuring yourself, you are operating, in the most valuable way you can be to the business at any given point in time. And the teams who have got that mindset or work and continue to make these things these four more star metrics happen are the ones who are driving that change and are being valuable to business and are plugged in to the business in the most effective way. So having gone through this, I hope this is making sense. I know it's that I hope it's not completely wild. But the question would be, why did the tenants make sense? I often hear from people, this just make I yes. It makes sense. Thank you. It's great to have written down on paper. It's I obviously, this you can't argue with this. It generally makes sense. But why does it make sense? How can I justify this to you? And the reason that I think this is powerful, the reason I know this makes sense is because of the improvement cycle. What I mean by the improvement cycle is it is effectively a scientific method. It is the way that you go from information to business value. The way that, anyone who's using data or information to make a decision is they are using data to identify business opportunities and problems. They are then exploring and finding solutions to those opportunities and problems, ideally using data. They are making decisions. They are taking action, and then they are monitoring the change to check that it has made a difference. Very, very simple approach. You hear this in any, Lean Six Sigma methodology, in many growth programs talk about this, Marketing, talk about this kind of experimentation cycle. The idea of identify, explore, decide, maybe different terminology, but the idea is you're running experimentation to check that you're driving improvements. You're finding opportunities, finding solutions, actioning, and monitoring. These are the this is happening if you're using data to make decisions. The question is, how well are you doing it? And if you look at these four boxes, if you buy into the improvement cycle as a very primitive way that you can make decisions better, you'll see that these boxes align with the tenants. That operational clarity gives you a better way to identify business opportunities and problems. Exploring and finding solutions is all about problem solving. Minimizing time to decision allows you to take action faster and then monitoring and measuring yourself. Are you working the biggest things? Is it working? This is why you'll find the business responding well if you are working with these tenants in mind because this is what the businesses needs to make decisions better. They may not articulate this to you very well, but this is what is going on badly now in your organizations if you're not working this way. You're enabling this cycle, this this culture of continuous improvement to happen. So these tenants are powerful. It should make sense to use a data team, but we also know, as you can see here, it's also the way the data the business needs to work. And that is why they're gonna respond well as you start to think and work this way because they are you're you're helping them enable them to do this. I often get asked when people again, I'm I'm hoping this isn't so that when you see this, it is clarifying rather than completely, like, completely off piste. I don't believe that any of these ideas are completely revolutionary. They're just packaging up what we probably already know already have been thinking about in a very discreet, very clear framework. That's what I'm I'm hoping you're getting across it, maybe a bit more reflection. But the question I often get asked is we know this is true. We know this is how we should be working. We know that it doesn't make sense to further the business with loads of different dashboards saying that's the same different numbers of the same metric. We know we should be problem solving. We know we should be having this and make decisions better. But but why is it difficult? Why is it so difficult to do this? Well, part of that is we're not defining the problem well. We aren't defining what matters. We're not I think we get lost in the weeds and and don't have this framework. I think that is a very powerful thing to have. But I also agree, and this is maybe where I'm getting the a bit a bit more I also believe that BI tools don't help. Because what we talk about in data a lot is reporting and ad hoc ad hoc analysis. And, really, what we're saying is if we bind to the improvement cycle, these tenants, then what we're really saying is reporting is monitor. It's like, can we see what's happened? And BI tools are great at this. We're good at monitoring's great. Maybe not monitoring the right things, but we we know we can monitor things. We can see a number. We can see a change. We've got that nailed. But if you buy into the improvement cycle, identify, explore, decide, we don't call this this stuff. We call this at all of this mess on the right hand side ad hoc analysis. We bucket it as the same thing. We're just doing work for the business. And what we need to talk about instead of ad hoc analysis is saying, we are trying to help the business identify opportunities and problems. We're helping them find solutions. We'll help make decisions. And the better we can compartmentalize that was ad hoc. That's what is the activity of growing the business and stop calling it ad hoc analysis, start realizing what it should be. We can start to have better conversation about where our role is, and we can start saying no to the wrong analysis in driving towards the improvement cycle. I know I've gone through a few different paradigm. I know I've gone through, like, tenants and then the improvement cycle. I know they're they sound they're they're similar but different. I I I hope you can come back and rewatch this and realize what I'm saying is I'm trying to talk in the language the business understands and talking to data people in the way they understand as well. The core idea here is that there are four ways that you can drive the business towards better operational improvement, focusing the right things, and that's about making ad hoc analysis structured, informed, focusing on biggest problems rather than just a swathe of information. So in the last few minutes before we get into q and a, the question often is, how do I get started? Well, firstly, you probably wanna go back and watch this presentation. I think Reese is gonna kindly share this presentation with you in a PDF form so you can read over with your teams. I I think that there's there's lots of things you can discuss around these ideas. I I reckon hopefully, this this starts some good conversations for you all and gives you a mental model that you can trust to think about, am I are we delivering against these four areas? But if you want to get into the meat of this problem, if you want to start to really drive progress, though you can tackle any four of these talents, like time to decision or problem solving, what we often find eighty four out of five times is that people gravitate towards, I wanna do operational clarity. Done it because it is the unlock of lots of other things. The more you human business feels simple, the easier it is to solve the bigger to get the the to start working on the biggest problems that the that you now can see. And so the way to do this is, can you take a part of your business? Could be a a single function, a single business process, could be the whole company, or could be very much in the weeds. And can you map that process out? Can you create a common understanding of that process with data so that that whole process is very clear, it's very measured, and it's unambiguous of what's going on in that business. Then when you've done that, can you work with the stakeholders who own that process and say, does this give you better understanding what's really going on? And if so, what are the biggest questions that you now wanna understand better? Where's the biggest drop off rate? Where's the k where's the KPI that doesn't make sense? Let's go tackle that problem together. Work with the business on that problem solved. Show them what you're building. Work the problem with them, and then come back and and get to an answer and show them that what you've gone through there is the improvement cycle, whether they know it or not. They've gone from identifying the problem because you've seen it. They've seen it clearly. You've problem solved it with them. You've done exploratory analysis in the right place. You've helped them reach a decision, and you've helped them see if there's gonna change. If you're doing that, you could do it on a small example to get things going. You could do I've seen companies go straight for, like, kind of revenue KPI chart and get the the CEO bought into it, but you could start small as well. But just start to focus on mapping out and giving clarity to visualize the business, not just visualize the data of the business, basically. That's it's it's a very fun exercise to do, and even the conversations around how to visualize that business area, and map it out will deliver a lot of value if you get into that space. It'd be remiss me not to say that we've obviously built count to make all of this possible. I wanna be clear. Count is the best tool to use for this kind of work because I obviously have made it so now. I know this is the way we should be working. But a lot of the principles you've learned today, I hundred percent believe you can apply them in any tool you have. It isn't a tool specific way of working, but some tools enable better than others. Please go ahead and build metric fees wherever you possibly can, in any way you possibly can, and know that it's valuable. Build that whatever dashboard tool you have. Please clear out your dashboarding tools of all the metrics which are duplicated and and minimize nonreports that are available to the business. These are all the principles that make sense regardless of what tool you're using. Please please feel that, but know that is there if you're if you are in the market for a new a new tool to enable this kind of stuff. Otherwise, I have finished. And I'm thank you so much for listening, and thank you for your emoji support if you've gone through it to know that I'm resonating in a small way. You can learn about chat to me more if you want from cam dot co or ollie at cam dot co. But I'm gonna spend some time now answering your questions. You've recently got it. Brilliant. Yes. Yeah. We've got loads of questions. So, yeah, thank you so much, Ollie. That was, that was fantastic. You're quite an eye opener for me, considering a lot of the problems I've heard, my wife, who's a data analyst, go through in a similar situation. So, yeah, this is definitely a slide that we're gonna come back to. So I will just hide the slides backstage for the moment, and then I'll bring them back. Cool. So I I'm gonna jump straight into the audience questions because we do have, quite a lot of good ones, and then I've got a couple of, questions that I might ask towards the end as well. So first question comes from, William, and William says, do you agree the closer the data team are embedded in the business, the faster they will start to solve a real business problems, and it's not always about the tech. So yeah. Do you agree and why? I agree. I I I completely agree, William. I, technology is an enabler of, can smooth processes, can make things faster and easier, but, obviously, the humans are the most important part of this and how humans communicate, work, and make decisions. I think the closer the data team is to the business, the more business context they have, the more the understanding ability to visualize and clarify what's going on. Yes. I think that is true. I I think I I don't wanna die on that horse, though. You could have if you are a centralized team, you can obviously work hard to make this possible. There's a lot of debates about I know there's lots of values for, like, hybrid team where you kind of you have a hub and spoke model so you can have some centralized standards, but then you're close to the business. I I don't think that there are probably better structures than others, but I don't think it's the single most important lever to deliver this kind of value, but it definitely helps the close you are to the business problem. You can't argue with that either. Yeah. Brilliant advice. Next question is from Erica. Erica asks, any advice on how to get executives to stop viewing the data team as a service team and switching to viewing them as a partner and including them in the decision making and and problem solving? That is the big question, Erica. I love it. I I have a lot to say on this. Let me give you my top three maybe or what comes to mind now. One obviously is, as I mentioned before, like, so if you can help executives have a build a better, clearer, simpler view of their business, they will only thank you. Like, I've never seen an executive say, this metric tree is is too simple. They love simplicity that you give them. They are bombarded with information at the lowest and highest level all the time, and they are craving you to give them clarity and simplicity. So, that is one way that we've seen today data teams instantly level up and have the executive team view them differently because, like, suddenly the data team's giving me simplicity and clarity that didn't have. I'm gonna lean on them as a crutch. That's one. So that's not the only thing, but that's a very I've seen that hundreds of times now. The second thing is, data teams need to think about being internal consult management consultants. There's a fantastic, book called, Trusted Advisor, which is effectively the book that any man any junior management consultant will be told to read to help them drive value for their for their clients as it were. And it is an amazing book full of ways to for a data function to think about how they can be more influential to an executive team. There's a lot of gold in that book alone, so that's trusted advisor. It's an old book. There's loads of secondhand bits on Amazon, but it's a very valuable book. It's obviously written for management consultants, but the principles apply very well. I think the other thing is just data team sharing methodology is a huge win. So, if you think about it, if a executive asks a data team for a number, I know people think they want to have less information, but what they really crave is confidence and trust. And that can come from a very well documented methodology, which they can follow through. That often is an unlock for them giving you more helping them think better. There's loads more ways of doing this, and it it can be a case by case basis. But I know that the tenants are the way to to ultimately get there. But the tactical tactics to get to that point, there's a few different starting points. But hopefully that's a bit of a a bit of a starting point because that is obviously the mission. Yep. Next question is from. So this one might be good to get the the slides back up for. So, good framework can make sense. However, how do we make the transition from the left hand side to the right hand side of the tenants? To borrow from Scott Belsky, so many data teams are in the messy middle. So I'll just bring the slides back and then also we've got that to reference. It's like it's okay to be so first off, it's okay to be messy middle. You you to be clear, you never I think if I'm honest well, I know this is true. The best teams I know who are doing the right hand side would say they're terrible. It's one of those things where, like, the more you do it, the more you see opportunity to do it better. It's a never ending journey. The key is, you know, you're making directions towards it. I know that sounds very that sounds very trite, but it it isn't a you can never get to the right hand side as a pawn to make. It's a journey never ending. As you make that if you see the hill arise, you can see more value. That's the fun of it. It it's not there's not a tick box exercise for this. There are things you could do that better and worse. You can go up and down the hill is the unlock. Because if you don't have operational clarity, you are the business is not clear, that creates a vicious cycle so that they may bear with you. If you if you make the business clear, they will ask you better questions. That means that you're working on more valuable things. If the business is not clear, they'll be asking you questions to clarify what's going on, and that creates more mess and more work for you. So I do believe that this the operational clarity is probably the highest impact way to make a delta shift, because now the business sees itself clearer and everything else becomes easier. So clarity is is probably all these four, the biggest unlock, which makes everything else easier. Yeah. That's that's probably where I would start at the messy middle is to get more clarity. That comes back to the slide on the slide show for how to get started. Map a process. Let's make a bit of our business really clear. Yep. And, yeah, for anyone else who wants to go reference these, the slides are in the resources, tab, and they will also be sent out with the recording, that you'll receive in your email inbox tomorrow. So they will be there as a as a handy reference should you need them. But, yeah, that that point of moving over to one hand side and constantly chasing the better part of it. I think there was it was either an NFL coach or an NFL quarterback that said, greatness is chasing perfection knowing you'll never get there, which I think translates quite well. Yeah. That's a great way of putting it. I I really love that. Yes. It is a mindset shift. It's a mindset thing. Growth mindset is another way of putting it. Right? Yeah. Yeah. It's great. I mean, I and I also love feedback on this stuff because my goal is that these talents become the definition the whole my whole industry understands and agrees to because that that gives us a lot of power to say to a CEO, this is what data team's for. Are you using us that way or not? Which is not people in sales and marketing, they already have a well defined, understood value. We need the same thing in data. So please take these and run with them, basically. Cool. So next question, we've we've got kinda got a two parter from Jose. So I'm gonna I'll say the the two parts, and then I'll come back to the first one. So question one was, regarding metric trees, are there any platforms that facilitate the process of preparing and maintaining this view or approach? Jose has not been planted by me in this business, but, obviously, count is a tool which actually build a BI tool that actually build metric trees because I having to be clear, just to say that it's the inside line, we had built count, and then we did this piece of work to, like, get to the value of the data team and realized how important metric trees were, and we've now built count to make that better. I just can't I can't I can't hide that fact. I believe this tenants tenants have driven me to make that strategy that way. There are other metrics you can start with a white any whiteboarding tool, really. Use the, you know, the Zoom whiteboarding tool. There's There's things like Miro and Figma out there, which let you get to the idea of building out process flow mapping, which is basically what we're saying here. And I'm just saying there's real power than adding metrics to that layer. So, yeah. I I think, it is possible to do this in other tools. I think if if they're flexible presentation layers, you can you can wedge it in. I think, for example, I think Google Data Studio can do it a bit. So I don't wanna be like that's not we're not the only tool in the world that can do this, but there are some which make it easier than others. But you don't need to start with a BI tool. Start with a whiteboard tool. Just get alignment on the metrics and then even hard paste them in and say this is what the metric were last week. Do we like this? We can make it live later. And then short answer is book a demo. Okay. You will need to book a demo to make this possible. I wanna be really clear. I just my own principles, these principles make sense. You should do them with you can do whatever tool you have. You know? You can do it. Okay. And Jose's, second question. So what are the ways to facilitate or smooth out the process, to enable the data and analytics function to measure itself? How do organizations that, are successful do it? He says he's tried some of this type of processes in the past, but there's always some resistance. Yeah. Thanks, Jose. I think it's a good question. I I don't as I said before, I don't have, like, the formula which means you can prove ROI. The thing which I think really matters and you can help with it is if the business has really, like, a good definition of the size of the prize for certain initiatives. Then if you can show that you've applied your resource analytics resource to those problems directly, that's a pretty good place to be. At least you can share in the the price as it were. I think that's that's a that's a very simple answer, but that is kind of the mental model, I think, that I see many VPs of analytics doing. They just go, what are the biggest problems? What are the OKRs? What's the biggest opportunities we need to go after? Have I got my team working on those biggest opportunities with the most of it as much time as possible? That is the men's mindset you need. There are certainly ways of measuring the negatives. So a very powerful, tool for that is is to do an for a month maybe or a few weeks, depending on how your cadence works, just doing an audit of the analytical request coming from the business. It's an enormously powerful tool for getting to that minimizing time to decision, by the way, of, like, where are we getting asked for questions? Is it the same person in marketing that keeps asking us the same question? What are the what's the complexity of the ask? Is it is it the same question in just a different form? It helps you weed out all the repeatable low level stuff that you could probably, like, solve as a data product or initiative or just teach them some SQL. And so that measuring the requests and analyzing that dataset for yourselves does allow you to free up time. So do you see well, I didn't I didn't have time to go into as much depth, but they're these tenants pair quite well because it's in tenant one of operational clarity makes problem solving of the right things easier. If you, if your minimums come to decision, you are therefore working on the most important things. You're measuring yourself against hard problems. So there there are pair. There are two pairs. It was it's not there's there's more to talk about that. But, yes, I think you can measure yourself and move move the negatives quickly. Next question comes from Pamela. Obviously, we've been covering, data and analytics, but, Pamela asks, do these tenants apply to a data engineering team? And in your in your opinion, what is the biggest hurdle for data engineering teams to overcome or change tools that become high impact? Feel free. But if if you don't want answering this this one, that's fine. No. Thank thank you. I think that's a really good question, and I I appreciate it. I've been thinking of this quite a lot. I I don't think so what I what I do know is that these these tenants are not appropriate for people working on commercial products. Let me see what I said. So if you have, like, a if you're working on, like, providing analytics to customers, Though that there's some very sensible ideas in here, if you're, like, providing dashboards that you sell effectively or data that you sell, this you should be using the value framework of a of a of a software product, like product management frameworks. This these tenants are about how do you offer internal analytics teams helping the helping your organization to drive improvement. Now I'm not saying there's overlap, but, like, that's the definite carve out, not for data products that you commercially sell. There are other value chains like revenue, which you can measure to achieve that. This is for internal analytics and BI. And therefore, in data engineering, the question is, are you aligned to internal analytics and decision making? If so, these definitely apply. Or are the data engineering delivering commercial products, in which case you need to solve there's a different value set there based on revenue, like, if that makes sense. So that's the first question to answer. And if it is internal analytics, the data engineering team is at least a portion you're working to. The question is how can you make these four things easier, basically. For anyone who is interested in the data product side of things, we do have quite a lot of, previous webinars and extra content on data products. So just just Google or search engine, data products, data camp, and you will find a treasure trove. You can also head over to data camp dot com forward slash webinars sorry, forward slash resources forward slash webinars where you'll find lots of stuff on data products in there. We'll go for one more question because I do appreciate that we're coming up to time. So where are we at? So we've got this one from Leacat. I'm sorry if I I've put you to your name there. How do you deal with situations where data teams are dealing with dynamic changing data points, and how, reliable would the reporting be, considered by stakeholders? I'll just do this one to reread that one. How How reliable will the reporting be considered by stakeholders? I I think that is a that's a difficult problem always. Right? If the data qual I'm gonna maybe I think this question is asking about data quality challenges effectively, like dynamically changing data points. There's data quality. That is obviously a, that this this tenant's framework does not say don't have good data quality at all. It's just letting you so data quality is not enableable of all of these things. Right? If you can paint the operational part of the business and give a clear view of what's going on, there's an explicit assumption that it's gonna be the data is gonna be correct enough that the business what what is a big mistake I see back to the negative service traps is, like, we are gonna make the data quality, like, from ninety percent to ninety five percent, and no one in the business cares about that level of accuracy. There's a kind of there's a there's a there's a data quality diminishing returns curve, which we wanna be a long way away from ninety nine percent quality. Like, no one cares. And that's where we see the failure is data quality being like, the, you know, the the almighty thing. If we'd get this right, everything else would be fine. We're not actually there have been some amazing innovations to make data quality much better, and we don't wanna overoptimize on it. So if data quality is a genuine problem where stakeholders are not trusting the data, fix it. But, also, there is a diminishing returns curve there. Not every single data quality issue deserves to be fixed because transient or the data itself is never possible, and that's about good communication to say, this data is not very good. I'm not sure I can do about it. Yeah. Do you wanna use it or not? Let me give you context. So, again, I just think the principles here, like, the more you're working with the business, the more you can talk through this stuff and help them make decisions within perfect in imperfect situations. So communicate as as you probably imagine, it's communication and improving data quality where you can with a kind of clear view on ROI. Perfect. Very clear. Brilliant. That takes us up to time. Thank you so much to everyone who attended, and thank you so much for the, everyone who asked a question. Those questions were were very good to run through. So, yeah, very, appreciative of your engagement, everyone. You will receive this email. You will receive an email with the recording of this tomorrow. Please do check out our upcoming sessions. Richie is back next week. We'll we'll be back to our regular cadence. Yeah. Thank you, Ollie, for for presenting and for your insights, and, Yeah. Thank you to the audience once again. So, Yeah. Hopefully, we'll see you again soon. Thanks, everyone. Thanks so much. It was a real pleasure.