I've had the pleasure of meeting hundreds of data leaders over the last few years. And one of the topics which keeps coming up every single time is what's the ideal structure for your data team. Team. It's one of those things which a data team mind has to think through or is just thrust upon them by the wider organization. So in this episode, we're gonna be looking at what is the ideal data structure. If you're new to our channel, this is more than numbers. It's a a podcast for data teams who are trying to break out of the support function mode and become, engines of growth their organization. I'm Molly Hughes. I'm the cofounder of Calm dot co, which is a Canvas based BI tool, which takes data teams out of the dashboard factory, lets them become their organization's problem solvers. To help us think through this topic of data team structure, I'm really pleased to welcome Lydia Monnington, this this episode. Lydia is the data science lead at Google DeepMind. Lydia's had an amazing glittering career. She's run data teams at organizations large and small such as Ocado, Tonnet Meta, Stuart, and now at Google DeepMind. Lydia, thanks for joining us. How are you? Thank you very much. I'm I'm very good. Thank you. Cool. Well, I to start off, I love asking everyone the same question as an icebreaker. And this question I wanna ask you is, like, when did you know that you wanted to not just use data in your career, but actually be a data person? When did you first fall in love with the idea of data? So, yeah, I think the first time I really enjoyed it, my first job out of uni, I joined Citigroup on their grad scheme. So Citigroup is an investment bank, and we were doing kind of credit research. So looking at businesses and deciding which ones we should invest in or our client should invest in and giving recommendations. And one of the things I did as part of that was really understanding companies really deeply and, like, modeling them. So we wanted to look five, ten years in the future and say, like, would would they have a stable cash flow? Would they be able to pay back their debt? And one of the companies we looked at was a care home company called Care UK. And what was really interesting about that was building out they had, I think, seven or eight care homes, different sizes, and they had two income streams. Either they had beds that were dedicated to the local authorities, like the council would pay for it. Mhmm. And that was a guaranteed income stream. That was paid whether there was someone there or not. But it was a little bit less profitable. Or it would be a private person, but, obviously, they would only pay if they were actually there was someone there. So there was an there was an occupancy rate. Yeah. And so one of the things we were doing was modeling out, you know, what that profitability looks like, what it looked like a different, like, demand for their services and different fullness of the store of the care homes. And then we could then see that, okay. In these scenarios, they'll be profitable. They'll be able to pay it back. These scenarios, we won't. How likely do we think those are? So it really gave me a sense of, like, how data allows you to understand the world, but also how data can be used to answer really important business questions to be used for business. So yeah. I I love it. I think that's that's so true. It care homes is just one of one of many things. I mean, I remember when I was, similarly in my early career, I got incredibly deep into the idea of problem solving, how to how to make strawberry punnets in in supermarkets. You've got a brilliant detail of that. It kinda doesn't matter. Just problem solving with data is just a a joy regardless of the medium sometimes. It's just the it's the pure problem that you get from it. It's cool. That's that's that's a good answer. I love it. I, well, I I wanna move on. Let's talk about a bit more about where you are now and before we dive into the the content around team structures. Maybe just tell us most people probably know what DeepMind is, but maybe you can give us a bit of an overview of where you are, the data team there. I'm sure there's lots of people thinking, what does it mean to do data and what is ultimately a data company? So tell us a bit more about DeepMind maybe and and Yeah. Through the team. So DeepMind, if if anyone who don't know doesn't know, our mission is to build intelligence to benefit humanity. So as part of that, DeepMind builds a large language model, so kind of a competitor to ChatGPT or Claude. It's called Gemini. But we also solve a number of other really, really interesting, like, problems that are very important to the world of data. So things like, we've got a team who's trying to work on managing the plasma so that, like, fusion can work. Because one of the big problems is, like, the plasma hits the edge of the fusion reactor, and then you're not doing fusion anymore. We've got a team who's working on forecasting typhoons so, obviously, people can get out of the way of those storms ahead of time and being more accurate. And so working with a number of weather services around the world, including, like, the US and Japanese ones. And, obviously, as people have probably heard of, like, AlphaFold, which, DeepMind won the Nobel Prize for last year, which is very exciting. So, yeah, that's that's DeepMind. Those are, I mean, those are some big problems. I mean, we've gone from care homes and, sorry, pun it, to some of the biggest challenges in There is some really cool things. Yeah. Yeah. Yeah. It was one of the things that, like, I was really excited about when looking at joining of, like, how many different really cool things are going on. And and so tell us more about the and, actually, you're currently even hiring. So one thing we should shout out is, actually, you're currently looking for a few people to join the data team. So we'll get we'll share some in the show notes. You can find links to those job descriptions or point if you don't already know about DeepMind's, careers page. But, Lydia, tell us more about, like, how does a data team fit? What is your team like? How do you work given that pretty much everyone in the organization is basically doing data of some description for very, very different reasons? So tell us more about your team. Yeah. So we are quite a small team. We're about fifteen people. We sit centrally kind of so we look across all of DeepMind. And we're not doing things like, you know, what is the data to train Gemini, for example. We're doing things like how do we how how do we answer the most quest important questions for business? How do we make the most important decisions more effectively with data? So one example is, like, how do we, focus where where what you know, how do we look at what the teams will work on? How do we look at how we manage, like, compute most effectively across the org, things like that. That's cool. That's a cool problem as well. That's that's awesome. So I think you often ask people to tell us more about, your data stack just to help people with people with tools. But I it sounds like I imagine at Google, I think, like, based on all we've we've I've heard before, things like BigQuery span out of in as an internal tool, probably you're using a lot of very weird and wonderful tools that aren't available to collect. Yeah. I mean, I don't know that I'd call them weird, particularly. K. It's like they are almost everything is an internal actually, I think everything is an internal specific tool. Right. But they they enlarge fill the niches that you would expect other tools to fill. So we have a tool to do pipelining. We have a tool or data transformation. We have tools to do orchestration. We have a query tool that's pretty good. We have a dashboarding tool, things like that. So there's nothing in that sense out of the ordinary, but it's built internally. Got you. Obviously, you worked in places before like Stuart and Ricardo where maybe that's more standard kind of well, what's the word? Sort of external tooling that you bought in. Maybe the question I'd love to ask you, again, you've worked in both places, is like we obviously, you're using proprietary tooling, but can you give a sense of, like, the, people who can often have a kind of idolized view of big tech and think big tech solve everything. But maybe you can be I'll be honest and tell us that if if you still have the similar kind of problems you you've seen elsewhere even in Google. Yeah. And I'd also talk about Metro as well, when thinking about this because people often come to me and say, oh, the data must be perfect. I think there's a few things that I found that were really great and kind of show, like, the value of the tooling or how that's being thought about. So one example I found in previous jobs before working at Facebook, I found that if we wanted to log a new piece of data, like, we need to do analysis. We need this piece of data. I once had an engineering team tell tell me it would take six months. And then I got to Facebook, and I'd be working with an engineer, and we need a new thing logged. And we were partly, it was we working on the same team, which I think makes that a lot easier. Yeah. But, we would you know, it was literally one line of code for them. It would send it somewhere that I could access it. It was all done. Literally, it could be done in ten minutes kinda thing, And that was a really big game changer. So velocity is a is a big diff is a big difference. And just the the ease. So, like, the tooling had to be built out to just make that work. Yeah. But I think the flip side of that, which is maybe obvious if you're thinking about it, is the sheer quantity of data was incredibly large. And so one of the big problems we had was, you know, people are logging things everywhere. You can create your own thing. So how do you know what is, you know, the source of truth for a particular thing? So we then, some really good data engineering teams then did the set sorts of, a gold or a validated datasets owned by data engineering team. This is like, you know, if you want data about people, you want data about ads, this is the source of truth place to start from because otherwise, I know you're searching through a thousand tables that have almost identical data. So, the scale problem is is definitely there. And so you're almost building things on top to fix that. Yeah. But it says also it's a problem which every organization is suffering with, like, the single source of truth. The how do I get how do I understand human involvement, people doing things about communication. Those sound like familiar talk. I have some preliminary problems that every single data team Hundred percent. That's awesome. Well, look. Thank you. That's a really helpful background. It's what you're doing sounds so interesting, but we're gonna switch now and talk about something which I know is dear to your heart and you've spoken about before, which is, like, the data team structure. As I said at the beginning, this is a thing which everyone has to think about if you're in data. It, like, every everyone is either gonna be thinking about what's the ideal structure or, wishing there are a different team structure or they'll be told by people up high that there's now a new team structure they gotta start managing within. It's not always a thing they have full everyone has full control over. And it's one of those things if you think about the tenants, the tenants of, like, data teams, it's one of those things which is a a real enabler. Like, you know, operational, crowded problem solving, time to decision, the the ability to measure yourself. These are things which are fundamentally that we we know we've talked about many times on our show, and these are always the case. But often, the enabler of all of these four things is getting the right team structure to have the right kind of conversations and may and make collaboration just generally easier. So I I wanna tee you up for this and just ask you to just talk us through the different types of team structures. Like, how does it generally evolve? And we can then talk through the pros and cons. And, hopefully, as we talk through it, people can help us, we can help people think about what's right for them and whether it is actually one perfect answer. So we're gonna start off with where do people usually start and what are the Yeah. So most most companies usually start with a centralized data team. The reason for this is kind of obvious. If you've only got two data people, you're probably gonna put them together. Rather, like, opposing forces that Yeah. Like block the other team. Exactly. Well, it also like, I think if you're separated in that kind of situation and why one team is valuable is you get to share a lot of knowledge, you get to build out best practices. You know, if you have ways of working that are more efficient, you can build out data foundations that's shared across the org. Let's say you had someone in, you know, sales team and someone in operations team, they might build out completely different sets of revenue data which don't align. So having one team is really good for that. It also means everyone's reporting into an analytics leader, so you get things like, your manager can help you progress. They actually know what you're doing, so you're not having a manager who kind of doesn't actually understand the depth of your work. So they can help you progress and grow and do training and all of those things. You could be coached by other analytics peers. All of those things are super good in this scenario. Yeah. But where does it where does it start to fall down then? What Yeah. So the thing that tends to happen is you have a small team, and more and more requests come in, and you're trying to manage that workload. And often if you're sat centrally, you don't have that depth of relationships with the people you're working with. So, you know, you maybe will only chat to someone from finance a couple of times a month, and you're, you know, you're not, like, part of that team or someone from ops. And so what that means is they'll be asking something and you're you know, know, they'll say, okay. I need this piece of data, and you'll give them that piece of data, but you don't know what they're gonna use it for. You don't know why they care about it. So you're kinda like a data, you know, data factory or data treadmill. We don't like that. There's two kind of cost to that. One is you're producing stuff that might not answer what they actually need. You're just kind of turning out data. You're not actually being a true partner to them. And the second is you can't prioritize effectively because you don't know what is being used for. You don't know why it matters. So how do you make the right choice about where do I spend time or which one do I prioritise? And it ends up with this very bureaucratic process where you are having to kinda litigate between different parts of the org. Say, like, this is high priority than this and this is why, or this is our backlog, and, you know, we need to have some way of managing that. And so it becomes you're kind of, like, devalued, but also, like, people are very in a very bureaucratic process, and that's that's not very effective for anyone. Yeah. You're you're you're you're basically becoming you're being distilled down to the the most fundamental thing you can do, which is give them data rather than actually the the high value functions that you could be doing with them and leaning in more and being more useful in that area. Yeah. And when so when does this I guess this can happen pretty quickly. Right? I mean, I've heard I know there's the there's the the bravest role I think in in in Techland is this is the solo data person, the first day to hire a start up who's gonna build the stack and sell the business. That is the the place that the people go to cut their teeth. I know many people who've been through that journey done that. And then They've done that before. The the second person who brings it is, like, the savior of that person and starts to give breathing room. And so what at what point does this become? Like, do you start to is it really start to become even practical thing about doing anything else, like, to have a different structure at all? I think that's an interesting question. I think it's, you know, at the point where you've got enough that you could have a team in each area so let's say you had finance ops and sales. If you had, say, twelve people, so you've got a manager and through two or three reports each, I think that would then be very feasible. I think it's also at the point where you start to feel these issues happening and this lack of connection is when often companies start swinging the other way. And then what's the other aspiration? So then you can swing, and you can swing a long way. Yeah. If you swing to the other extreme Yeah. Let's go down. And this often happens actually almost unintentionally. So let's say you've got this bureaucratic process we were talking about. People have to wait maybe four or five months to get something they need. And some teams, I actually I really need some data stuff to do my job to for my team to be effective. I'm just gonna hire someone in my team. And this is sometimes called a shadow data team. Yes. And so either these can be a few people or this can be the whole data team. And in this case, you are reporting into the area there, so from into the sales lead or into the ops lead. And what's nice about this structure is you are part of these teams. You know, you'll go to their team meetings. You'll understand what their goals are, what's really important to them. You'll, you know, have a real deep knowledge of the team and how they add value and where you can add the most value. And the ideal of this is then you are going in and you're like, okay. What I know what's really important to the sales team. I know how I'm gonna solve their problems, and I'm gonna, you know, proactively solve that or work on that and deliver those results. And so that's the ideal of that. Yeah. You've got the maximum of domain knowledge. You're shoulder to shoulder people that you can really work on. It's you you have you're able to have more autonomy, maybe more agency to do what actually matters because you're part of the team, and a good idea is therefore, accepted. You've got the maximum trust. Yeah. Yes. The way things can go wrong here, the first is you're kind of the opposite of the previous case. You're reporting in someone who doesn't understand analytics. So, you know, they might ask you for something and not really understanding how long it takes. You won't get that development. The other thing that can happen is, ideally, you're kind of a true partner in this scenario, but often, you know, you're still just pulling data because they're just like, oh, that's the data person in the team, kind of you're not really respected necessarily. And the other the bigger, like, insidious issue that's kind of a longer term one is that people start building out their own separate data stacks. And so you start getting inconsistent answers between different departments, like, wrong answers when you try to, like, tally things across. That's a lot of duplicated work. You've got a lot of inconsistency, and that caused a big problem for the business. It also means, like Shadow shadow BI tools, like shadow data teams. You just have the shadow data stacks appearing Yes. You would have to stacks appearing everywhere, inconsistent. Yeah. So a lot of duplicated work, and, like, duplicated process and maybe you know, sometimes I've seen different companies have different stacks even. Like, you know, one will be using dbt, one will be using Snowflake. So it's completely completely separate. Yeah. That's the that's what you wanna that's when it gets really hard to fix as well. So you wanna try try and capture that. So Try and solve it ahead of time. Yeah. Try and solve it ahead of time or unpick it. I know that's language when I are we when we're speaking in an interview recently in a in a previous episode with Lena from, Bumble, she was talking about the kind of the one of the big jobs of coming into a new role and getting started is just like that the survey of, like, where are all the data people, where are all the data tools, that kind of surveying the landscape to work out what is the structure that's implicitly built up, and often hasn't been thought through, and you gotta fix that as one of your first things to do in that first year as a data leader. So, yeah, we it's a kind of thing you might even just be presented this problem to solve. Yeah. Exactly. So let that but bold bold push then. People will probably be mostly in one of those two extremes, the centralized or the embedded, extreme, which is the other swing that we've been talking about. Like, what is do you wanna put forward a a bet for the the ideal structure then? So the one I found most effective is kind of what's called a matrix or hybrid team structure. Yep. And the idea behind this is you're trying to get the best of both worlds, but to make it work requires, more than anything, quite a lot of trust, actually. The reason it requires trust is you're taking if you're in a embedded model, you're taking the people out of those teams. They're not in the direct reporting lines of those orgs anymore. Yeah. But they are still, in a sense, dedicated to them. So that's why I've kind of put the data team, like, still close to those orgs. Yeah. And the idea there is you still get the knowledge of what's important. You still get the relationships. You still feel like part of the team. And thus, you get the ability to build the most important things, answer the most important questions. But you're actually in a central data team. And that gives you a number of things. The one thing it gives you is a level of independence. So if you're embedded and you're, say, reporting into head of sales, it's very difficult to say, hey. I think our sales strategy is wrong. And, actually, that's something that's something where analytics teams could actually add a lot of value, like being a real independent voice for the org. Yeah. And so if you're sat like this and you report into a data leader, you're able to do that. But, hopefully, also your relationships are such that you can, you know, say that and have that land in effect. Well, actually, you don't have the you don't have an opinion to know that's the case. Right? You've got best of I understand really what's going on. You know I know, and I've got the backing of a of a another department to come in with this kind of view. Yeah. Yeah. Yeah. And, obviously, the other things the other benefits you get of reporting into a data leader of your progression, your growth, standardisation across the org of both tooling and process, using centralised tools are all there by virtue of having this structure. It is a little bit more complicated, like both organisationally and partnering, because you effectively have all the data team people who are effectively in two teams. And so, like, relationship wise, that's more complicated. It takes a little bit more time. But, actually, if that when that works and when you've got that trust and that expectation that data is independent voice, that's a very powerful structure. And that that's that it makes a lot of sense. And, yeah, that the comparisons you're playing about the pros and cons of this decent the decentralized and then fully embedded model, it kind of it does naturally sound like the right mix of of both both best the pros and the cons. I wonder if you I want to unpack this a bit more. I I guess the question that a lot of people will be thinking about is this is really helpful, but, I'm not able to make this decision myself as a data leader or as a team. How how can someone make the case for this without, you know, without getting to the politics of people thinking their headcount's being taken away? Like, does have you seen that is there different versions of hybrid basically where, you know, some people, the payroll sits in the different departments versus the data team. How I the practice counts is a bit quite tricky, and I guess, similarly, how you introduce it to as a suggested structure. Yeah. I think this can be. If you're not in the structure, it can definitely be difficult to get there. So what there's some things you can do which sort of start to get there without going all the way. The most common one, I think, if you're in in a kind of embedded style model, is having some sort of, like, data community. So that is Yes. The data teams meet every month. They share best practice. They start to build relationships even if it's not the reporting line. You know, if the teams are, like, building really strong bonds between them, you can start to get some of those benefits without going all the way. That's really helpful. That's like yeah. So rather that you can the the data people can just form that that community best practice together and get Yeah. A lot of that a lot of the benefits without necessarily being formalized. That's good to go there. Yeah. And if if you are in a day if you are a data leader in a team that looks like this, I would strongly recommend that. Like, one of some of the most, like, rewarding and excellent experiences I've had is, like, relationships is with data leaders from other, like, teams. Like, where we share, we understand each other's problems. You start to think about best practice and training, and it's been you know, I had that. Ricardo had sort of a number of data teams. We had amazing, you know, some of our data science team leaders, like, did training sessions for everyone on kind of precision and recall, and that was really useful for the whole org. Partnering with teams across Europe was similar, like, finding problems, working out what we could solve as a group. Yeah. Really can be really beneficial. And then, yeah, if you do from either side, if you're trying to switch in if you're trying to switch in from embedded, I think it is that how do you build that trust with teams that they will get the support they need even if then they don't own the reporting line. Yeah. And trust is one of those things that it takes time and you have to kind of show good intent and keep working. And I think some of it is if you've got a couple of people who are high, you know, centralized and a couple of people kind of so embedded, can you show that the people who are centralized are giving them the support they need? If you're coming from centralized, the problem is actually, how do you change how teams see the data team? Like, how do you make them feel like these people are part of your team rather than part of a central data team? And that's actually on both sides, both on the teams you're trying to embed in. And how does your team feel? Because if they're used to being, you know, we get a task, we do it, actually sitting as part of team is quite a different model. So it's actually a coaching part for your your analyst as well. Good. Is is there is there any sort of advice you give for someone going from centralized trying to make it more matrix? Because I think you give a great, very practical, very relatively easy thing of, like, into your best practice to go embedded to to to hybrid. But what about centralized? Is it, like, actually going with your desk to be if you if you're in an office, go sit next to that team. Is is that that's on those really, like, very basic but very helpful levers that you can take to just be available. Go to the team meetings maybe. Is that it's like Yeah. Going to the team meetings as a as a data leader, I've often said, like, hey. Can you add Sally into your team meeting from now on? Because I'd love for her to feel more part of the team. Some of it is, like, literally just sitting down with those leaders and saying, like, this is what I'm trying to do. What can we do so that, you know, people in my team feel like part of your team? Like, what are the team meetings? What are the, yeah, off sites they do getting those involved to start that relationship? That's really helpful. That's really practical as well. That's really great. Thanks for talking us through that. I actually as you know, we often have a kind of anonymous data question from the more numbers community, which you can join the more numbers community by going to account dot co slash MTN. You can find links to other episodes and also join our kind of, our vetted, community of data leaders. One of the things that I got a question from, I think I've teased up to you before because we actually talked about it earlier this week when we had dinner, was, how does this kind of structure work by discipline? So if you have a data science organization, data engineering, analysts, like, does that change the the answers of team structure when you have those more specialisms within a data org? Yeah. So I think about this some of it is like if you're thinking about data foundations, if you've got a team that's like data platform, sometimes this is called data engineering. So, you know, those are people managing your AWS instance, so the people managing, you know, making sure Tableau works or making sure DBT is set up correctly. Mhmm. That team, I think there is value for it sitting centrally. Because for them to be successful, they have to understand what the analysts and data data engineers or data analytics engineers are doing, but they don't have to understand, you know, Sally is trying to do this problem for, finance day. Bob's trying to do this problem for, sales day. So that being central, I think, almost always makes sense. Yep. Data engineering or analytics engineering, so which I would define as the people who are working to build, you know, process data, build data pipelines, think about how we do that most effectively. That you can argue either way, and it depends a little bit both on how many data engineers you have. Yeah. Often companies don't really have enough in my experience. I'm a big fan of, like, if you have data engineers, they make all your data scientists and data analysts much more effective, so you have quite a lot of them. But a lot of companies have maybe ten, you know, ten or twenty data scientists and data analytics and data data analysts, but maybe only, like, two or three, data engineers, I feel like. Yeah. That's my problem. Ratios and I think about, like, the There's some good blogs, like, something in the order of, like, three to one. So, like, for every three of every two data scientists, you have one data engineer. I found it very good. But it also depends where you wanna draw the line between the two roles. Yeah. If you have a really small team, I'd probably have them really focused on what are the absolute essentials we need to have. So what is, like, our most essential raw data? So that might be your sales data. How do we process that into a really easy to use form? Maybe how do we do the, like, you know, most the cleaning of that, maybe some of the metrics on that? Yeah. Because that's almost like your foundation for everything else. But then if you've got enough that you can then say, like, this person's gonna build a really great data stack for the sales team, then you can start embedding them as well. Yeah. That's that's a helpful rule of thumb there, I think you mentioned, which is the, like, when the decentralized sort of embedded decision is based on, firstly, how, ubiquitous is the task they're doing. If they're managing a platform, which everyone's gonna touch, that's a more central role. Mhmm. And then the second Libra is if you only have a few people, they kinda need to be centralized. But if you have a certain number of them, enough that you can start to lean more in and specialize their task, then embedded, that makes sense. It's kind of Yeah. Those are the two levers to think about, which I think is really a really good answer. Thank you. That's Yeah. That's a good number. Say, regardless of where they sit, the relationship between data science and and data analysts and analysts and analysts engineers or data engineers is incredibly. That has to be really tight. That, like, has to be really good. Otherwise, you're gonna have a lot of problems. So yeah. Yeah. Talking about, you know, that understanding and that relationship is really key. That makes sense. Awesome. Oh, well, we've got a few minutes left, and I wanted to ask you the last question just as we wrap up, which is just you've been through a lot of different companies. You've been big tech, smaller tech. You have been in government. You've been in investment banking. So I just would love, like, what is the one consistent thing that you found to be, like, incredibly useful for where wherever anyone else is in their career, wherever they're doing data, what is the one piece of advice that you that you have held on to or really found useful across all those different domains and and organizations? Yeah. So one of the things I found that was a really big game changer for me was, like, focusing on why I'm doing things. Like, I used to be when I was at Kado, I would get a really interesting problem and kind of follow every single rabbit hole and realize I was solving a bug that affected two users a year just because I was like, oh, this doesn't seem quite right. Let's go and work out why. And that was really fun, but it was not incredibly effective. And so one of the really big things that changed for me was at the start of a project saying, like, actually, what am I trying to do here? What is the, like, outcome we're trying to achieve? What does success look like? I'm being really clear on that. Like, let's say we're trying to make a decision. Have I had the conversation with the stakeholder of, like, okay. If I present you this, this, and this, will you be able to make the decision from that? Or, actually, do you also need, you know, this extra piece? Or, actually, could I only give you this first piece, and that would be enough for you to make the call? And so just being, yeah, just being really clear. You know, the other thing could be, like, you know, the idea of hypothesis driven analysis of, like, what are the key hypotheses we have that we wanna prove or disprove, doing light laying them all out first and really making you know, thinking about what those are and how we make them. And And then the final piece is, obviously, you know what you're producing, and then you can build a really clear analytics plan. Like, these are the tables I need out. This is probably how I need to write the queries or what stage I need to go through. And then at that stage, you start coding. And, actually, that means the thing I find is the thinking and the coding is actually quite difficult to do at the same time. But if you separate it, you can actually have a really clear time. You just, you know, plan everything, and then you're just like, code done. Everyone's happy. And it can and it also reduces the rework because if you've had that conversation with someone saying, like, okay. How are you gonna make this decision? You know exactly what they need to see or not see, and you're not producing anything you don't need, and you're producing everything you do. It's almost like I mean, it's almost like you need a data white you're almost like you're pitching a data whiteboard here, by the way, just because because I I was really interested in it was just a fun way. It is wonderful pitching pitching for a data whiteboard. Canvas brings BI tool. But, I mean, I mean, but I'm joking when jokes aside, that that's an amazing piece of advice. I love the idea of just what you said there, a little nugget of, like, when you go to a stakeholder and say, if I give you this, would you make a decision? I mean, even that alone is just such a powerful piece of advice. It's a very powerful framing, actually. Yeah. Because sometimes you'll come to people and you'll say that, and they'll be like, oh, no. I just think this is interesting. And then you can be like and I actually have had this conversation with someone who's just like, I agree. It's really interesting, but I'm not being paid to do interesting things, sadly. I'm paid to, like, help make decisions that matter to the business. And and right now, we're they're paid to help you solve fusion and sort of general purpose they are for the humanity. So I've got other things to do. That's great. I love that. Like, like, always ask why is a really, really great piece of advice, and is it just it it just explodes lots of different practical examples of it. Yeah. That's wonderful. Lydia, we've we've run out of time. It's been an absolute joy to speak to you. Thank you for taking so much talking us through the different team structures, their pros and cons, the way to get the max amount of value from your data organization, and if you're fixed in a particular structure, and then talking about the purpose, the why. It's been a really great, great conversation. Just a reminder for those watching, if you wanna look at more of the episodes or get into the show notes, come to account dot close slash MTN. Also, a a quick plug, good Google DeepMind are hiring right now in a few roles. Definitely check them out. I can imagine. I can't think of any more better better data problems to solve than what Lydia's teed up at the start. So you wanna work with Lydia and and join Google DeepMind, then you should check out their careers page. Now, Lydia, thank you so much. It's been an absolute joy. It's been great. Lovely. See you. Speak soon. Bye. Speak soon.