When the people often discuss the pros and the cons of embedded teams versus centralized teams, for me, it's really a simple case of knowledge share. It's the type of knowledge share that you need to optimize towards. So if you ever got a centralized team, you've excellent knowledge share between individuals in the team. They all know what each other are working on. They're sort of absorbing from each other. You know, they're much it's much easier to learn from your peers in that environment because you really are sitting in a stand up with them every morning, hearing them talk about what they're working on, maybe picking up some of the work that they had worked on previously. Whereas if you're embedded, you've got great knowledge share with actually what is happening on the ground with the engineers, with the designers, with the product managers, the people who are, like, building the product that the that the users will use. And because of what we want the analytic role to be, which is very much a strategic one rather than an executional one, they really are responsible for uncovering opportunities that drive the company forward. It is paramount for those individuals to have the maximum knowledge share of what the, you know, business goals are, what performance looks like, what the user problems are, what that opportunity space is. So they are embedded, into that space. So is it a question of is it a question of speed? Perhaps not directly. It's it's more one of the the sort of the deep product knowledge that they really need to understand in order to be able to actually work as a thought partner for the for the product manager, as someone who can really work closely with engineering and design and help them understand how they can, like, build better and build faster.