So we talk in this presentation about the service traps. These are the ways of operating, which we believe we've seen again and again in an empirical study, I guess, that we think emphasize the the parent child relationship. And that there's four of them then and they're kind of, we can go through each of those for now. But these are the dynamics which we believe, like, undervalue the skill and the and the influence of data team can can otherwise have. So let's go through those four, and then we can move on to explain the four tenants that we believe lead to a kind of adult to adult relationship, and we'll and we'll go through more examples of that. So that's how I was hoping to structure the session. Getting questions as we go would be fantastic, but we'll also make sure we have time at the end to do that. So here are the sort of the four we call these traps, basically, service traps. These are things which, as I said, we think, emphasize that parent child relationship and make the data team run to the the tune of the wider business. So the first one of those is drowning the business with information. The idea of the the data key the business keeps asking for information on the data team, and the data team keep providing it, And that continual provision of the information without any recourse leads to confusion, operational bloat, and, fragmented understanding. As you can imagine, that very much goes against the principles of metric trees that we've been discussing in this series. So we'll come on to the how that can be a help with the the counterbalance. The second one then is just answering a question the business has that the date the business sees the data team as a source of information, and treats the Ben team like a service rather than being a function with high with a role which is higher value than that higher impact and ultimately undervalues, underutilizes the scale of the data team. The other way that the data team can be undervalued and have a a sort of a a power dynamic difference with the business is why the data team putting up barriers between the business and the data team. It's very understandable reaction to when you get, you know, swamped with questions to try and create processes and formalize the way the business and the data team work. Sometimes that that is a requirement and are useful, but it it can also make the the data team feel more like a black box and, again, just minimize the role it can have in the wider business. And the fourth one, which is a and also a temptation and I think is very easy to do is to focus on up on tasks which have diminishing returns and value or the business doesn't even understand. It's very easy, if if we're not careful as as data practitioners to focus on the things we can control, which may be our own code, our own infrastructure, own stack, and affecting that with the out actually being a genuine outcome of value creation elsewhere in the business. So these four, sort of behaviors, we consider to be, operational traps. They're very easy to fall into. This is not to say these are things which every team does perfectly, but these are the four ways that we can remove ourselves or devalue the work we're doing by the nature we're asked by the business.