Hello, everyone. Thanks for coming. My name is Taylor Brownlow. I'm head of data and product at Count. Kount, as I'm sure you guys know, is a, collaboration data tool. So it's like a combination of BI tools, SQL IDE in, big ultimate canvas. I'm joined today by Sara Subzakari, who's a data analyst at Lockbox. Sara's story is really fantastic. I'm excited to have her on. I'll let her introduce herself in a moment, but I just wanted to give a bit context about, today's session. So Sarah and I were speaking a few weeks ago. A lot of what she was, telling me about how the team is using count, reminded me of a bigger discussion that's been going on in data about how to make sure data teams are impactful, focused on the right things, continuing to add impact. And so I thought Sara had some really great things to share about how her team at Lockbox is doing that. And it's important to share these kinds of stories, so that's the motivation, for today. But, Sara, thanks for coming. How how are you doing? Yeah. Doing well. Thanks for having me. I'm looking forward to this. Yeah. Yeah. Me too. Yeah. It should be great. Maybe you could start. Just tell us a little bit more about Lockbox and maybe the what it's like the data team there. Yeah. Definitely. So, Lockbox is a fintech company. It's a salesforce scale up depending on who you ask or what your definition is. So we primarily work within financial well-being. We build products that help users, get access to richer financial opportunities and just a richer life in general. So, what the actual products do is that it helps users build their credit scores, their credit history, also their financial literacy as well. And, yeah, we that's that's the theme or the vision that the product revolves around. In terms of the data team, there's about five data analysts within Lockbox. We've also got data engineer who sits primarily in the the tech function. And we kind of function as a hybrid team. So we've got, central data analysts that they take on urgent requests. They help with the data modeling, and then we've got an embedded analysts that sit in different, departments or squads or projects. And I'm one of the embedded analysts. So I sit close to marketing. Also, I do financial modeling for the commercial team and also product as well. So, yeah, it's a bit of that lockbox. Embedded in a few teams then, sounds like. Yes. Yeah. Definitely. Yeah. Oh, nice. Yeah. Maybe we can also cover the the tech stack might be a good place to to go to next year. Yeah. Definitely. It's it's evolved, for the last year. So I I joined Lockbox, over a year ago. It was last April. And when I joined, we were just introducing count into our tech stack, and since then it's changed. So, what we do currently have is we have our cloud data warehouse. We've got a desktop SQL editor, which I really rarely use now, for obvious reasons because I've got count. And, also, we had a few BI tools here and there. So we were, we had a tablet subscription of which we'd moved away from because we moved all of our reports over to count. So that's pretty much the tech stack. We're also, building our data warehouse using DBT. So that's a new project that we're going, with with launching as a team. So, yeah, I hope that covers it. Small project of getting into DBT world. I'm sure it's, not daunting at all. Wouldn't it be nice? Yeah. I don't think we fully see it. Like, we we're just about seeing the full breadth of the project now, and it's like like, yeah. Definitely more than just upskilling, but, yeah, it's a it's a it's a good one. Oh, very cool. Thanks for the intro. Yeah. I think, you kind of you unique position in that you started around the same time Count did. I don't know. Maybe you could tell a little bit about how you first were introduced to Count and what what that was like. Yeah. I think I had, like, the less conventional introduction to a a tech tool. It was actually just before I started at Lockbox. I went to a lunch with my team just to get to know everyone, and I remember they were raving about this platform called Count. I thought that's a really good name for an analytics platform. And, yes, they were trying to explain it, and it was it's very different to, obviously, the the IDs that I worked with before. And so I remember going home and googling count and seeing the demo and thinking, okay, this is very innovative. Clearly, I wanna know what it is that they use it for. And I didn't quite, get that picture yet because we were just introducing count into the platform. And so once I started, actually, the first, like, tool that I really got going on was count because it was just so effective at onboarding me and helping me get to know the schema, kind of the what are the the main reports, what are the main, you know, joins that we do. Like, it was it allowed me to really have much fuller visibility as to, you know, what data a lockbox looks like. So that was that was my first experience with the account during lunch and then actually tried it. Yeah. I think that, that experience of being new and trying to dive into the data and everything is something anyone who's been a data team had to do. I think I've I've I've had to do that many times. And it takes, like, months until you feel comfortable doing that. Yeah. I don't know. Maybe you could I I think everyone probably on the call has had that experience. So maybe you could talk through a bit more detail about what that what that meant or why that was different to other times that you've done that kind of thing before. Yeah. I can actually also show you what it was like, if that works. So, when I've worked on, like, different types of data before. It was, I worked in the government with antimicrobial sales data. I then moved over to an ag tech start up with looking at poultry data, like production data. And I know how painful it is to start in a whole new domain as well as a whole different business and, looking at, you know, the different data and different production systems. So, basically, Jamie, he did a really good job, with one of our analysts at the time, and he said, here's a bunch of tables that we use or queries that we use for our reports. Just dive into it, and you can use count. We have some interesting features. So I'm just gonna share my screen and show you what it what I bet I this was like a repeated process for me for, like, a week. So what we have here is a, it was a query that would build a view that would then feed into Tableau, and we would build reports on Tableau. And it was the most commonly used one. There were so many different tables that fed into it. So I originally, like, was reading through the query and making sticky notes. And then Jamie said, actually, you can just pull it to the side and split out the the CTEs. And so I was able to see, there was more transparency on what that was actually feeding into the model. I could document it in a way that I understood, and I could reflect back to it. And so what it eventually looked like, with these queries was, yeah, basically, my own kind of documented memo board of what sort of tables feed in for what reasons. I was able to visualize, see the frequency of different, you know, products that we that we have to offer for our users. And, yeah, that that was what the onboarding process looked like, which which isn't very similar to what it was like before in other organizations or companies that I worked at. Yeah. I really like this example. I think it brings up this concept of transparency, which I think would come up a lot in today's session and feeds back to kind of the original idea around, you know, focusing on impact. I think having these silos of information and silos of knowledge really gets in our way of trying to to be effective. Obviously, the faster you're able to understand these models, the faster you can be effective, the more the whole team can be effective. I think, you know, not just for onboarding, but we've all had that experience of, you know, if that query and Jamie runs that you know, manages that query and he's not there and that's erroring, you still need to go in and figure out what happened even if you've been there for, like, a year. So having this transparent space to break things down feels like a really big way for you guys to just try to get one fewer thing that's in your way, and you guys could just focus on what you need to do. Like, you know, in this case, understanding the data much more quickly. Yeah. Yeah. Absolutely. And that actually reminds me, like, on so many occasions where we've had, like, an important report that gets sent out on a daily basis and the visuals aren't generating, there's an error. I know the dread of, like, needing to go in and debug something that someone else has built, and now it's not as scary and it's not as, like, dread with or doom that you feel. So, yes, it's a really good point. I agree. Oh, nice. Yeah. And then I guess kind of as we moving ahead, so you got onboarded and then, you know, you're a full fledged member of the team now. And what were some of the challenges that you were facing then? Yeah. Good one. So because we were just about integrating count into our stack, we I I was still confronted with a lot of the typical problems that a fragmented analytics work flow would have. And there were two main things that jumped out for me. One was it's very difficult to maintain focus when you have to manage things like, you know, downloading things locally, importing them into a a new environment, analyzing them, downloading, blah, blah, blah, like, iterating through that process. And so I, I know, like, when you feel you feel kind of frustration, sometimes anxiety when you have to use all these different tools and things don't go well. And so your your focus ends up getting fragmented. And deep, like, deep work and focus is really important to me. And I think for problem solving for all of us, it's really, really important. So that was one main pain point. And then the other was, collaborating. And the stakeholder, whether it was a a technical one or a nontechnical one, who would depend on you to transfer these insights and knowledge, they were also on the receiving end of this fragmented workflow, and just lack of ease of distributing insights. And so those those are the two main pain points. And, at the time, I kind of, maybe selfishly, I don't know, I decided I'm not going to use the the traditional workflow. I'm just going to stick with count. And, yeah, I think it it gave me, like, positive experience with onboarding and starting a new business because I felt like I was really able to focus on the insights, and I didn't have to just try and learn this new tool or whatever, because this is pretty intuitive. So, yeah, I hope that answers your question. I have an example of a situation like that as well, like, the the difference between old tech stack, new tech stack, if if you'd like. Yeah. Yeah. Definitely. I think, the one term that I always think of with the the fragmented workflow is the the cognitive load of of trying to maintain, yeah, where is the data? How do I get it from this tool to this tool? And it is, as you said, like, such a distraction. So, yeah, it completely resonates, and I think that frustration, like, compounds, and we don't often think about the impact of that fragmented workflow on the the stakeholder who's receiving it, who is also even more confused. I think, you could just imagine that getting amplified as you go down the funnel. So, yeah, I should've said that resonated. But but, yeah, let's dive into to an example. I think it'd be cool. I think just as you said that, it made me think also, before I pull that up. How many stakeholders will just say, like, can you put it in a Google Sheet? Because it's just much more intuitive for them to use. And even that process, in itself, you know, it's so much nicer to have a tool that users can intuitively navigate because they're used to things like other canvassing and whiteboarding tools as well. Yeah. Great. And I think the transparency point as well, I think Google Sheets is well, and Excel in general is is transparent because you can always see all the data. So I think there's always that kind of gut instinct to gravitate towards that because you trust it more because you can see it. And I think, yeah, I can just back to the first point. But, yeah. Yeah. Yeah. That's awesome. And I I also found that some stakeholders weren't scared, like, scared of the tables on account as well. Actually, they were reading the sequel because it's a pretty intuitive, obviously, language. But, yeah. Sorry. I was, fangirling over the fact that we don't have to use Google Sheets as much. I will pull something up. So I as I mentioned before, I I work closely with, kinda maintaining and building our LTV analysis, the customer lifetime value analysis. And so I pulled out, like, a a mock report, just with, like, generic data, as to what these would normally look like. So, yeah, I've got control cells that allows users to filter for whatever different types of segmentation that you guys are used to doing. And this is what the this is what the report would look like, regardless of, like, you know, what tool we would express it on. But what actually the difference between using count and moving everything over this account was that, this is what the workflow looked like, before count. When I first started and I was onboarded onto LTV and the you know, getting to know the methodology, we had to query our data. And we then had to pull it into a notebook. And then within the notebook, there was a very linear kind of structured way to analyze it, many, many, many lines of code. Then we would, pull it into a Google Sheet, and then we would distribute it to our stakeholders. Now I just do all of that in count. And for a while, I wanted to move the service account, and I'm sure that many analysts have had this experience before where they get loads of questions from the stakeholder. Okay. Where did you get this number from? How does this you know, how what is the logic behind this methodology? And you have to flick through so many. It's just not transparent for them. It's not clear. And I think a lot of stakeholders are also capable of, understanding the methodology as well. So, yeah, now just to there's really no no no no other way to communicate this. It's literally just moved to count, and the analysis actually looks something like this. So previously where there were, you know, loads of lines of code, how to store the data to move it from one tool to another. And, yeah, this is this is what it looks like now. I see. It's kinda hard to I feel like the screenshots don't do the complexity justice of, like, just the yeah. Going from an IDE and, you know, probably some query you have saved on your desktop or something. Moving it moving it over. Yeah. Yeah. Absolutely. Yeah. And, yeah. What do you say so that feels like obviously, you kinda mentioned the the well, it was such a good cognitive load that, you know, this kind of workflow requires the old way of doing that. Have you sorry. I was thinking about how to articulate this. Have you used a really a term I really like, which is no. I can't remember. Just being on the edge of your abilities, basically. And I wonder if you could talk a bit about that. Yeah. Definitely. I I think with the thing that I love about data is you're constantly learning, and you kinda have to accept that if you're working within data, or to be honest, any any sort of industry or, domain that's constantly moving and adapting. And I really now sincerely believe that we have really low standards when it comes to our workflows, because there are just so many tools out there, and there are so many different, you know, workflows, ways of working, and most of them are fragmented. And so the reason why I originally brought up, you know, being able to focus in, the cognitive load and being at the edge of your ability is, I I sincerely believe that if you wanna solve a problem that's complex and it's not you know, it's an indeterminate problem, it's very difficult to define a very simple and, clear methodology to answer this particular problem. You don't wanna we don't wanna spend your time moving in between different tools. You don't wanna have to debug things on different platforms or environments. And it really strips away your ability to focus and concentrate on one thing at a time and to lean into that deep work. So, yeah, being I want to like, in many parts of life, like, I want to adopt things that enable me to be at the edge of my ability because I know that's how I'm gonna grow and learn and develop and, you know, pick up the other additional skills that will take me from step a to step b. I there was a an analysis that I worked on where I was actually confronted with this, and it was to measure the halo effect of YouTube ads. And to put it to put it simply, I'm sure, like, everyone can relate to this. They see a YouTube ad for a product, and they don't click on the link within the YouTube platform. They open a new tab and they search the product name or the business name. And so our marketing team, when we first experimented with YouTube ads, we intuitively knew and I'm going on a bit of attention, but trust trust me with this one. We knew intuitively that, or we we we felt intuitively that it would the YouTube ads would lead to conversions on organic channels, as, you know, people would jump the tabs or, you know, they become more aware of the brand. And so we wanted to explore if that existed, if that was actually happening, if there was any way to quantify it. And as you can imagine, if you're running an experiment for two weeks, two weeks worth of data, especially depending on the budget that you have, there's not a lot of data to work with. And then in this situation, being new to marketing, I was at the edge of my ability. I didn't know anything at that point about marketing. And I had to really collaborate with others in the team, the marketing department to really understand how to approach this problem. And also in in both research, what I wanted to do was just come up with a simple methodology to answer this crucial question of which the business needed to answer in order to to, invest in this type of marketing campaign. I can I can show it as well? Yeah. Yeah. Let's see. Yeah. Let me just get out. You have you've taught me a lot about halo effect as well. So it's, you know, educating on all fronts. Yeah. It's good. Yeah. I mean, it was it was, when when they first mentioned halo effects, I thought, you know, what what is that? But once you know what it is, it's intuitively makes sense. Yeah. Let's pull that up. So this this is I think this was, like, maybe two two, three months into my time at Lockbox. And yeah. So I so I I I built out, you know, what is the what is the problem statement? I did some research. What what was the the format of our ads? What are the primary or secondary success metrics that we're looking for? And I built out this I built out this canvas. And so there's two different ways for me the methodologies that I developed to determine whether there was a halo effect or not, and presented both of them. And we walked through it as a team, as a as a squad, to look at the results of this, experiment. And it generated so many other questions that then led on to new experiments, but I'll just show you what the analysis looked like. So I normally, what I do is I pull in my raw data, which at the time we were exporting from CSV and putting it into, count, and then querying locally. And then also getting the conversion data from our, data warehouse, visualizing it, experimenting with, you know, how can I what sort of methodology do I wanna develop to or analysis to define this? And this is how I built it out. This is what it looked like. And it's definitely not what it looked like initially. I can tell you that. So I had no idea what to do. Yeah. I think it's a good, yeah. Maybe talk us through the process of building this kind of thing and how how you got to this point. Yeah. Let me see. So let's see. What did it look like initially? Let's take it here. So, yeah, this is me kind of work like, it was like a workshop. I would also bring in some other analysts. I would show the team, you know, this is what the data looks like. And then as things developed, I think I pulled more structure into it. So you can see that, actually, I decided to approach this analysis in this way doing a correlation plot, and also, hypothesis testing as well. And then, eventually, it led to the final product that you saw. So, yeah, I think, it started to slowly take shape and, yeah, that that that's how I approached it. Yeah. I really like what you said about, you know, this concept of of nonlinear. Because I think we think about nonlinear a lot of times in in data or even analysis. Right? Like, your analysis in the way that you think isn't nonlinear. But I think also this shows that the whole process isn't as well that you might Yeah. You know, you need space to, like, oh, over here, I'm, like, testing the data quality. And over here, I'm playing with these two different approaches to this model and how this is gonna work and, you know, experimenting with this. And over here, I'm playing with visuals and what's the best way to lay this out. And just having the space to kind of iterate in all these different fronts at the same time and, in whatever way, you know, organically makes sense to you, I think that, that really comes across in this, which I I really like about that example. Exactly that. That's it was especially when you said, like, customized. I could customize it to what I needed rather than trying to come like, put everything into a Google Sheet or, I don't think you would build a a a dashboard for this. I mean, I'd I'd hope not. Yeah. Yet to be challenged for that, but, yeah, I agree. Well, you know, my views on dashboards. So that's why I guess my answer on that. Yeah. And you you mentioned this idea of, you know, bringing other people into this and kinda getting getting feedback and that kind of thing. I wonder if you could speak a bit more of, yeah, how others works with others within the data team, beyond the data team, yeah, what that looks like. Yeah. Definitely. I I'm def I I think feedback loops is, like, it's a big blessing in anything that you're doing, especially as an analyst. And I think the there's two core feedback groups that I think count enables for us as a for as a team, and also as a business, as a wider business. The the first is within our own analysis. So being able to you have yeah. You switching from, you know, querying your data, cleaning it, visualizing it, going back because you realize, actually, I'm pulling in data that I initially try to filter out for this particular segment of users. And, so there's because it's so nonlinear, because it's a canvas and, you know, I can move, you know, cells around. I can branch off into a whole new analysis. Then I can I have feedback loops then? I can I have feedback loops between the visual tools? I've got Python, so I can do more complex analysis. And then I have SQL. And then on top of that, because, you know, akin to, like, other platforms like, you know, Figma and Miro, you can actually see people use the, the tool. So I often if I if I'm struggling with querying something, and I don't understand the context of the data enough, I will pull in members of the team, the, yeah, the analytics team. And we're able to follow each other's logic and learn much, much better. Like, I think we solidify the learnings from collaborating much more than we would if, you know, I would say, can you help me, you know, fix this query? And then, you know, it's pretty urgent. So I'm like, okay. I'll come back to this in, you know, two hours once I send this report off to understand how they did it. I never did, let's be honest. So, yeah. And, the other feedback loop is with the business stakeholders. And someone mentioned the other something the other day about heat maps, and then it reminded me of the fact that we're gonna speak. And it's nice to see users interact with the dashboard. And I I think I kind of create a in subconscious heat map of the things that they're interacting with. Yeah. And yeah. So we have feedback loops from the business. They can confirm the assumptions that we have. They can confirm whether the the, the data, essentially, the product that we're building, whether it's a report or an analysis is answering their questions. And, at the end of the day, just to put it really simply, I feel like I'm doing my job better. I can do my job better as a result of that. Yeah. Yeah. I think those are both really good points, I think, especially when you consider the the kind of default way of doing both of those. Well, all three of them you mentioned, kind of three different feedback loops, I guess. There are one, like, personally process oriented, one getting feedback from your peers and kind of analytical feedback, and then another getting, external context and, you know, ultimately business feedback. I think, yeah, the alternatives to those are, yeah, very asynchronous, very, you know, I'll just send you a Slack message. I hope I get to it. And often again, like, very fragmented. You're never gonna see the whole thing. So I think even in, you know, the example you gave of trying to give feedback on someone else's query, you you might just be giving pure SQL feedback, right, or kind of, an approach like that. When really, if you step back and knew what they were trying to do, then you could say, actually, no. No. No. That's this is the wrong approach entirely. What you really wanna do is this, but you kind of need to see all of it at once. And I think a lot of what we have in place, data teams don't let us do that. You just kinda see little windows of time and and bits of information at once. Mhmm. So, yeah, I think, yeah, those feedback loops are so critical to how data teams work. So just having something that helps, like, facilitate that, yeah, is like a big step. But, obviously, you guys have to actually do the do the work. You can have a tool that lets you do it, but I think there's a lot that you guys have done to to make that work, to kind of create a culture where that feedback is accepted and and valued, and it's something that, yeah, perpetuates and continues itself forward. So Yeah. I actually didn't that you saying that reminds me of the, I think a lot probably a lot of people can, appreciate this, but working with the dev team, they know the data so well because, obviously, they they build out the logic to get it into the structure that it is for us to analyze. I for the the devs that I work with, they also love using count as well, because they're able to bring in their context and maybe challenge some of the assumptions that we've made about the products, how the product works, or the type you know, how we, you know, I don't know, particular field. What what does status mean in this table? So, yeah, I think I think it also, in a way, has fed back knowledge to them as to how we use the the the end, you know, the data in its state when it comes to us. And so we refine because of that transparency, we've we refine as a business, you know, what should our logic, what should the definition of a particular field be or the type of user? And is that integrated into the logic of our data as well? So they they really also benefit from it, I feel. And, yeah, I think that's just one example of many areas across the business that that we've experienced that particular thing. Yeah. Is it that's a good point. I was speaking to someone the other day, and they're saying, they have their kind of data engineering team actually gets to speak to the stakeholders, and that's kind of two or three levels removed. And it's almost like they would never be speaking to each other. They're so far away in the data pipeline, one end and the other, but they're actually able to just you know, how much value and just having okay. I need this. Okay. I can build this. You know, why why don't these two people actually, you know, speak together more more frequently? Right. Yeah. That's a good point. There's a I know you have, another good example. I wanted to touch on this idea of of prototyping as we're talking about feedback loops and Mhmm. And, again, also trying to be really efficient with your time. And I think one of the ways teams waste time and maybe you could kind of give more concrete examples of this is is building the wrong things. Like, I see a lot of, a lot of stuff out there about, you know, how to be more efficient and things like that, but it's to me, it comes back to, like, the most efficient thing is to not waste your time building the wrong things. Like, like, prototyping is a really, like, common sense way to do that. And so I don't know if you could talk through how how you guys approach prototyping. Yeah. The yeah. Definitely. A hundred percent. We have saved so much time just getting, the stakeholder involved in the beginning of building out a report. This is an example of, so we wanted to create reports, and these reports are important. We wanted to make sure that they are presenting the right information, and narrative as well so things can be misconstrued. And so there's a template. There's, like, a sea of templates to help with this, but I chose this particular template in count to structure how I would actually start building the report. So understand, you know, what is it that, that this member of the, I don't know, marketing or product team, what do they wanna get from the report, or the dashboard? What how do they want any alerts, what frequency did they will they check it? Are there are there any other success metrics that we would use to determine whether it was you the way that we intended to? And so, we would get together. We got together in a call. It was half an hour. It was a half an hour call, and I put some preliminary preliminary bits down of what I understood about this project. And then we just went through it together, and I I built out examples. And this is what, by prototyping. Like, this is how we approach it is this is like, kind of a a mock version of, you know, what what do we want a one month report to look like three months or six months or whatever it is. And, yeah, just having something to look at for the stakeholder meant that they could visualize the process a lot earlier, and and they could probably we were able or we were able to reduce the delay in the types of questions that we would get later on in the process, bring it to the front of the, you know, the end to end process. And and, yeah, just throw sticky sticky notes on there. I was able to just, like, I mentioned that the heat map just watch, you know, what it is that they were hovering over. Mhmm. What sort of insights or sections of the report were they interested in? And so this is this is a pretty good example, I feel, as to how how we save time with building dashboards or reports that will get used, to put it simply. Yeah. I think it's a good, a point kind of saving time. I think there's a, like, logical fallacy of, like, oh, this is an additional step. So it feels like it's gonna add time to my overall process, but I think, yeah, as you say, you do this for thirty minutes, maybe sit down, go through it, and then the time that you save on the back end because you're not rebuilding everything from scratch is is massive. And I think there's a huge part about setting expectations around this. You know, prototyping is just about getting to the right thing, but I think there's always a surprise when someone sees a a dashboard for the first time and say, oh, it's done. You know, here it is. Here's the final thing. And and so you just have this kind of shock, but I I don't know. I don't what is this? This is new. And so bringing them in to be like, no. This is what you should expect. That's already gonna be so much better, you know, just to have that experience of like, I oh, yeah. I know where things are gonna be because I helped design it in that sense. So yeah. Yeah. Absolutely. A big proponent of of prototyping. So Do you know what that, reminds me of? I think I was reading a book called, A Win Without Pitching, and I realized that as analysts or, you know, report builders or creators, we we've gotten into the habit of pitching reports. So we build it, build it, build it, and then we say, here you go. And it's as if we're like, this is our pitch. You know, this is our product. We want you to love it. And what what we we should be doing throughout the process is inviting them in and collaborating and having a conversation rather than just one pitch at the end. Because we're essentially building you know, we're we're creating, a product, you know, something that will be used. So, yeah, that was a that's reminding me of that. Yeah. I think that's a really good point. I always like to just think, you know, what if what if I were them and I was trying to use data in the same way that we kind of force them to use data, and it's just like, I have to I have to send some request to the form, and I hope you know what I mean. And then, you know, a week later, I get something back and, you know, it's kind of wild to think that we would be using data in that way. But, yeah, I think it's a Yeah. That's a really good way of putting it. That's a good exercise. Put yourself in their shoes, and it's really good exercise. Yeah. Yeah. Try to use data in a in a dashboard that you share. That's right. Yeah. Well, very nice. I'm just trying to see if there's anything else we said we wanted to cover, but, you know, maybe maybe it's good then to cover off from your perspective then. We've covered on quite a few points on, you know, the transformations we talked about about workflow, obviously, making sure the analysts like yourself can actually do right work, focus on solving the right problems, getting rid of, you know, the things that get in your way of collaboration, working more closely with your team and stakeholders. But yeah. So anything kind of or what would you say are the biggest things that are different now in how you work now to maybe when you started a year ago at Lumbox? What's that delta for you? Yeah. I think, well, it definitely looks different because we've moved all of our, reporting away from Tableau's account, because it just it made sense given the the benefits of the platform and the type of work that we do. I would say because and I think it really does come down to being able to we have the space to problem solve. And therefore, I think you're you're working in easy mode to problem solve more effectively. You're getting rid of the barriers that would waste your time. And so I what I've noticed in the team and also, like, especially myself, we can really focus on we we feel more embedded in the in the problem, and it means that we are more motivated to go and explore different methodologies, like different ways to analyze this, different perspectives. And part of that also comes down to collaborating with the stakeholder as well. So I think we've just become much more competent analysts as a result of it as well. I think it's nice to be able to log on and have all the context you need in one environment because you've pulled in all the necessary people from the beginning, if you've done it right, to provide the information that you need. And so you're just much more well equipped. I think that's the best way to put it. You're more well equipped. We're much more well equipped. And at this stage, if if something if the if if we can't answer a question effectively, it just means that maybe we didn't, we didn't go through the feedback loops, the necessary feedback loops from the beginning, but that was already at our disposal. So, yeah, I think there's, you know, I guess, two main things. One, everyone in the business works with count now when it comes to data, to and the data that we distribute. And two, we are just we're so much more effective with our time. Like, we are much more efficient with our time. And we I think I'd I'd like to speak on behalf of the team. I think we enjoy it more as a result of it as well. Yeah. Every time I speak to you guys, it does feel like you're you're having fun. So that's, it comes across this side. Yeah. I think it's really well said. Yeah, like I said at the start, I was really excited to share your story. I think, you guys are approaching analytics differently, but I think it's nice that it's not a a huge shift to kind of monumental. It's almost just kind of you're orienting yourself around, yeah, around impact, right, around how to make the biggest difference. And for you, that's meant, you know, changing how you collaborate with others and making sure all the roadblocks that get in your way of of being good problem solvers are removed. So, yeah, I think it's it's really wonderful what you guys have done. So, yeah, I just wanna say say thank you. If there are any questions for Sara, please feel free to drop them in the comments. Otherwise, I try to to wrap up. Maybe looking ahead, what's what's next? You mentioned the the DBT project. Is there anything else coming up? Yeah. I think the DBT project is probably the biggest one for us. So, we were aware of, like, the full spectrum of capabilities and features that count as a platform. And we're really excited to start, bringing in our dbt models into the canvases, editing them, exploring them, collaborating on them. And, yeah, I think that's the probably where that's the next stage of growth for us as a as a data team, and we'll have significant impacts across the whole business. So that's that's what's next. I see. Well, yeah, I'm excited to see it. Yeah. Well, it looks like no questions right now, but feel free to get in touch if you do have any questions. Sara, Sara, thank you so so much. I really appreciate it. Thank you for putting together those canvases for us and being willing to share it, and, thank you for your time. It's been it's been great. You know, my pleasure. It's been great chatting to you, Taylor. Thanks. Thank you all. Have a good day.