The Rise of the Data-Conscious Software Engineer: Bridging the Data-Software Gap | Mark Freeman | Shift Left Data Conference 2025

Talk Description

Data teams increasingly embrace software engineering practices to address quality and integration challenges, yet friction remains between software and data teams. This talk explores why standard practices alone aren’t enough and introduces the concept of the “Data-Conscious Software Engineer,” an emerging role critical to bridging these organizational divides. Attendees will learn how identifying and empowering engineers who deeply understand both software development and data workflows can foster stronger collaboration, improve data quality, and drive organizational change toward treating data as a strategic asset.

Additional Shift Left Data Conference Talks

Shifting Left with Data DevOps (recording link)

• Chad Sanderson - Co-Founder & CEO - Gable.ai

Shifting From Reactive to Proactive at Glassdoor (recording link)

• Zakariah Siyaji - Engineering Manager - Glassdoor

Data Contracts in the Real World, the Adevinta Spain Implementation (recording link)

• Sergio Couto Catoira - Senior Data Engineer - Adevinta Spain

Panel: State of the Data And AI Market (recording link)

• Apoorva Pandhi - Managing Director - Zetta Venture Partners
• Matt Turck - Managing Director - FirstMark
• Chris Riccomini - General Partner - Materialized View Capital
• Chad Sanderson (Moderator)

Wayfair’s Multi-year Data Mesh Journey (recording link)

• Nachiket Mehta - Former Head of Data and Analytics Eng - Wayfair
• Piyush Tiwari - Senior Manager of Engineering - Wayfair

Automating Data Quality via Shift Left for Real-Time Web Data Feeds at Industrial Scale (recording link)

• Sarah McKenna - CEO - Sequentum

Panel: Shift Left Across the Data Lifecycle—Data Contracts, Transformations, Observability, and Catalogs (recording link)

• Barr Moses - Co-Founder & CEO - Monte Carlo
• Tristan Handy - CEO & Founder - dbt Labs
• Prukalpa Sankar - Co-Founder & CEO - Atlan
• Chad Sanderson (Moderator)

Shift Left with Apache Iceberg Data Products to Power AI (recording link)

• Andrew Madson - Founder - Insights x Design

The Rise of the Data-Conscious Software Engineer: Bridging the Data-Software Gap (recording link)

• Mark Freeman - Tech Lead - Gable.ai

Building a Scalable Data Foundation in Health Tech (recording link)

• Anna Swigart - Director, Data Engineering - Helix

Shifting Left in Banking: Enhancing Machine Learning Models through Proactive Data Quality (recording link)

• Abhi Ghosh - Head of Data Observability - Capital One

Panel: How AI Is Shifting Data Infrastructure Left (recording link)

• Joe Reis - Founder - Nerd Herd Education (Co-author of Fundamental of Data Engineering)
• Vin Vashishta - CEO - V Squared AI (Author of From Data to Profit)
• Carly Taylor - Field CTO, Gaming - Databricks
• Chad Sanderson (Moderator)

Transcript

*Note: Video transcribed via AI voice to text; There may be inconsistencies.

" Share on, the slides at the Gable offices and now it's going. There it is. All right, I'm out. There we go. Thank you for buying me time, Demetris. Awesome. Well, my, my, my talk will be a little bit shorter. I can speed through this, but essentially my title is The Rise of the Data Conscious Software Engineer and really trying to bridge the gap between data and software teams.

So this is coming from our early preview of our book. If you go to gable.ai, you'll see the O'Reilly book. You can download the early release for free. Um, so a lot of this, uh, material's coming from there. And you'll see this kind of logo in the corner for things I particularly reference.  I'd like to start all my talks with like, how did I even get here?

Um, with my data engineering villain arc. Uh, I was hired as a data scientist at previous startups to do all the cool machine learning things. And when I got there, the reality was messy data lake, flaky bash jobs and untrust untrustworthy data. Um, you see the spaghetti dag right there. I think that's just kind of the reality of a lot of data teams.

And so what essentially happened was I started building the infra myself so I can do my job, but they were like, Hey, you're, you're actually pretty good at this. You should become a data engineer. Um, and it turns out I loved kind of building data models over ML models. So it was a great fit for that Next slide.

So this experience led to the, the following questions and ultimately why I started devoting so much of my time on data contracts. Like why am I writing a book on this? Why did I spend the last few years like focusing on this key problem? And essentially these questions right here, why is there such a huge disconnect between software engineers and data teams in respect to how data is used?

I was told having all this data easily available to me at Data Lake was a good thing, but why was it not matching my experience? Are the above just problems in my company? Or is this like an industrywide problem and it's industry wide problem? And actually what, that's what gravitated me towards working at Gable and Chad specifically, was he was actually talking about this problem and I was like, oh my gosh, it's not just me being incompetent in my job.

This is actually something really hard that everyone's struggling with. And so then the next question was, well, how do I fix this problem? Next slide. And so the agenda for this talk is, you know why software engineering best practices alone are insufficient for data teams? Um, I argue a solution for this is data contracts.

And through that some painful lessons from getting data contract buy-in. And through that, the other side of going through this process over and over again was identifying this person called the data conscious software engineering, kind of introducing who that is. And then finally I end with, you know what data teams can do today.

Next slide. And so why software engineering best practices alone are insufficient for data teams? Next slide. And this is pretty much the kind of experience that a lot of engineers have with data science. Um, the typical stereotype is the data scientists build a ML model in their, in their, uh, Python notebook, and they're like, this is great.

It works great, it does all the great things. Uh, engineer here you go, put it in production. And the engineer's just like, what is this? You, you expect me to put this in production? Like it's a notebook. What are you gonna do with this? Right? Um, and so engineers are pretty skeptical of a lot of data teams in their, in their engineering skills.

Uh, next slide. And so engineering best practices are very helpful in data. So I'm not against them, but having software engineering teams trust those practices implemented by data teams is a very difficult endeavor. And kind of speaking to that, in my last role where I shifted from being a data scientist to being a data engineer and going further and further into the application code base, it took over a year before the engineers trusted me to have ReadWrite access to their transactional database.

Um, they were surprised when I did a unit test right? Where I put things in production, it just was not their expectation of me. And so I had to build that trust over time and I started learning that other data teams really started having that as well. Next slide. And so engineers are skeptical and rightfully so.

Um, you know, while frustrating that like they didn't trust the work I was doing, even though I knew it was correct, um, I understood where they were coming from and I probably would've been the same if, uh, if I was in their shoes as well. Um, and so software engineering teams are the ones held accountable for application uptime, managing transactional database and protecting their code base and anyone implementing code outside of these constraints is a potential threat to the above.

And why internally have so many best practices to prevent these issues such as CICD unit test version control, all the things we've been talking about in shift left. Um, furthermore, while all software engineers are aware of these standards table stakes for them, it's more of a spectrum of understanding among the various data roles they interact with.

So me being in data engineering, I had a lot of experience with, with, uh, engineering best practice. But when I was a data analyst, right? I was very close to the business not thinking about things in production. And so there, there's like a litany spectrum of they they interact with and what's their expectation.

And it's kind of unfair for them to really piece that out from every single data role. Especially I think even a few years ago defining what a data scientist was was extremely hard and I think it still is probably, um, next slide. And so I argue that a solution to this problem is data contracts. And I'll provide a quick introduction to what data contracts are.

Next slide. So data contracts are a data architecture pattern that extends software driven collaboration to data teams via API like agreements that programmatically track and enforce expectations around data. And this is the big key thing within the CICD workflow. And we'll have some diagrams to show what that looks like.

Next slide. And so what are data contracts? Um, for contract driven data management, it has the following properties. One domain teams create data products. Um, this is really, I think coming from like the shift, uh, not shift left. The, the data mesh kind of the terminology I think is the mock really pushed this really far.

Um, in addition, all data products must have a contract. Um, contract modifications follow a process. Again, this change management piece is like the crux of what data contracts really try to accomplish through technology. And then contract metadata is programmatically updated. Um, we had, uh, we're talking about, uh, data catalogs earlier.

I argue that data catalogs are the foundation for what's happening with kind of the operationalizing of data and of data quality. One of the first steps to get data contracts in place is you need a catalog. Um, the, the reason before on iceberg, the reason why it's so powerful is it has a catalog to navigate the data lake, right?

Data catalogs are quintessential for just understanding the vast met data you have in your business. And then finally, consumers are informed of change in quality. Um, when I was a data scientist, that was one of the hardest parts of my job. When I go to the business person and be like, Hey, this dashboard's gonna be gone for like a week, and they're like, why?

And me explaining the intricacies of like, why the data pipeline's late or why this batch job missed or why this one value's wrong, their eyes just glaze over, right? And so being able to communicate that effectively to the right people at the right time under the right context makes it very powerful.

Next slide. And so what really starts is I call the business logic lifecycle. And hopefully you can see this on, on, on the screen. But the way it starts is the business has idea of what the reality is and what they want to capture. That's then translated to a team, typically engineers, where they have the application code and they transfer that into code that puts that data, those expectations of transactional database.

That data is then replicating to an analytical database. And one thing I wanna highlight here is that it is structured completely different. Um, and so then the next step is they restructure again to insights to inform the business. And you have this loop, but again, thinking about change management, next slide.

As they start to separate from reality, as they start to dis not communicate well with each other, build in different silos, that's when you start having data quality issues, is this deviation from the truth and expectations. And so those Xs is where data contracts really come in play to really prevent that.

Next slide. And so this is the data contract workflow, um, for this. And so where it starts, we'll start on the right side. Where you see that little red star is you have a consumer who says, Hey, these are my expectations for the data. This is how the business will use it. They then say, let's go put this under a contract.

It'll be a YAML file typically, um, where it can programmatically inversion control, say like, these are expectations. This is what we, um, uh, wanna have under contract. Then. Software engineer upstream has to agree to be on that contract. And that in itself is very powerful. You're finally having that conversation.

I remember in my last data science role, one of the big unlocks for us was when my manager worked really hard to bridge the gap with the engineering team and get us involved in the, um, product requirement document stage, where before they even started coding, we were able to negotiate with them saying like, Hey, you should capture this, or maybe you don't structure it this way, right?

Um, they're just providing a process for that and programmatically storing that. So then once that contract's in place, the developers, it can be a completely different developer had no idea about this. They go about doing their developer thing, doing the software engineering thing, providing value to the company, and then they merge code and the CIC check happens.

They check, Hey, did I change a data asset? And is that data asset under contract? If it didn't do any violations, happy go lucky. They pass a test like there any other type of CIC tests they have and they move forward. But if there is a violation, um, there's kind of two kind of failed tiers. One, they'll either be like, Hey, this is a hard stop.

This will be like detrimental to the business. You cannot merge this and let's have a conversation. Or it can be like a soft failure where it's like, ah, it'll be worse to have this data blocked. We'll flag it, but let's keep it going. Uh, next slide. And so these are the components of data contracts. Um, obviously have the data assets.

That's the foundation of it. Uh, next slide. Then you have the contract definition. So how do you define what the expectations are in the spec? What is the business logic? Um, do you have a data catalog place? If you have streaming data, maybe you have a schema registry. Next slide. Then you have the detection.

So what is the data coming in? How is it changing? Um, a big thing that's been really a huge unlocker data contract, static code analysis, looking at the code itself and how that impacts data. There's multiple things you can do here. Um, that'll be for a different talk though. And then finally the next slide, you have the prevention.

And I think the CICD component is the crux that actually operationalize and automates all these checks. And I think one of the biggest gripes that I've seen talking around industry with data governance was they do all this work, creating all these documents, talking to all these stakeholders. They have all these frameworks and it's really important stuff and the business sees value in it, but they can't enforce it because just in documents.

And so in, in incentivizing people to engage with that is much harder. And so I think really having this prevention step within the developer workflow via version control, via monitoring alerts and CICD, it really takes that hard work that a lot of governance people are doing and actually gives 'em teeth to actually enforce it.

Uh, next slide. And so going back to how this works for the CICD, so typically what will happen is you'll have your GitHub branch. You'll go merge your code, um, or do a commit, and then from there do the CICD check. You'll spin up a database, um, with the expected schema. And this is for a streaming use case.

So we will check Kafka schema registry, Hey, did this match expectations? Yes or no? And if it doesn't, it doesn't, it'll block it and they can't merge the code. And that's one of the most kind of impactful ways to get. The attention of software engineers is they want merge code. They wanna show they're, they're showing progress.

And if you get anything in the way, they're like, oh, wait, what, what I have to do now to make sure this goes through? Right? So I think CICD has been the huge kind of component to actually make this important to other software engineers and not just data people. Next slide. And so here we have an example of kind of what these building blocks look in action.

On the left we have example, contract, spec, and yaml. And then on the right is one of those messages that the, uh, engineer would get, um, in their poll requests when they're trying to do code review or understand why something is breaking. They have the context, they know who to reach out to. Um, and so they're incentivized to take action before the data changes.

Next slide. And so that is data contracting and be thinking like, wow, this sounds great. How do I get started? I had the same kind of experience as well. It's like I just wanna run into it. Tell the whole world about Mason's data contracts. I think they'll believe me too, not so much. There is some things we had to learn along the way, um, to really get to this point where we, we found the pattern to get contracts bought in by the wider business and specifically software engineers.

Um, next slide. And so, um, hard lesson number one. Next slide. Data teams who thought they could only implement data contracts downstream the database, they were really not set up for success. Um, next slide. We'll have this diagram right here. Um, this is a typical data stack that you would typically, uh, see.

Obviously huge simplification, but many times what's happening is they wanna put data contracts on e and g really downstream. And why would, why would they do that? Well, one, that's where they can control. They don't need to get permission from upstream teams. They can just implement it there so they feel like they can move quicker.

In addition, typically when they're looking at data contracts, they're having some huge data, quality data trust issues. And so they really wanna protect their data going over to their business users to maintain that trust and stop having basically have egg on their face being like, why is the data wrong?

Even though they didn't do anything about that. And so I argue that's a trap, um, because 'cause of simplicity, because of, you know, trying to stop the bleeding with, with the trust, it gives a false sense of solving issues. But then what happens is they have constraints for downstream, but upstream, they're still getting bad data.

And now they have all these constraints and checks that slowing them down. And so now their timeliness is starting to drop because now they have all these constraints stopping the data flows. The, the downstream teams are still mad because the data's late. And so I've seen this kind of a couple times over and over again where, you know, they need to go after the actual root of the problem.

The fundamental logic in the business is changing the data model, and they need to account for that change management next slide. And so they wanna work upstream, they wanna go to the engineers. Well, the next challenge we've seen is. Many data teams were hesitant to talk to their upstream engineer colleagues.

Um, if you think about it, if you're a data scientist saying like, Hey, my data's broken. Every time you go to the engineering team, you bring up problems, right? Or maybe time you did bring up problems, but nothing ever changed. Uh, I remember for me when I had, uh, data pipelines go down that needed help from other teams easily put on the backlog because data was a nice to have while the application code was like driving the business, right?

Uh, and so, you know, one of the first things you need to do if you're in this position is like you cannot pursue data contracts. If you're do not have a relationship with your engineering team, you need to go foster that next slide. And, you know, this is what we're seeing for many data teams. When a model goes down, they're just kind of pointing at each other rather than looking at the system itself.

Next slide. And so finally is alright, they, it will talk to the engineers. Um, what was most surprising for these data teams, and I think Zach talked about is, is kind of Glassdoor, um, presentation. The earlier conference is like nearly every time you bring up data contracts to engineering teams, they would say something along the lines of, wait, the data team is not already doing this.

And they were just flabbergasted. Uh, next slide. And there's like kind of two kind of components to, to facets of this is one, engineering teams expect that these constraints already exist for data teams. Um, this is table stakes for 'em. So they just assume that like the rest of the technical business is already doing this and they're shocked that it wasn't happening.

Or the other side was software engineers underestimated how hard this task is for data compared to code. And so you think about code, code is changing, um, it's very discreet, obviously there's some comple a lot of complexity to that, but then you add data to it, now it's code plus data changing. And so the kind of complexity doubles for that.

And so I don't think they really account for how hard it is to do that. Um, next slide. And so the missing link we saw all the teams that actually overcame all these three kind of friction points was what I call a data conscious software engineer. Next slide. And very, very intentional saying conscious not data aware, conscious is that you are painfully aware and sensitive to the pains of that.

There's a level of empathy to that, uh, for there. Next slide. And so teams who overcame these c talent have one similarity. Someone within the software engineering organization had a nuanced understanding of their relationship between software and data workflows and became a champion for supporting data teams because they recognized the impact of data on the wider org.

And so I call this person the data conscious software engineer, and I argue that and identifying this person should be like the first step in your data contract journey. And, uh, something I really wanna highlight here, one second. Lost my place in there is for this data conscious software engineer. Is that, I lost the thought I was free.

Freestyling it. Guess I won't anymore. Next slide. Well, what are the characteristics of, of the data conscious software engineer? The first one is there are often staff level or above where their scope oversees the wider architecture of the business and thus they have purview of how the software and data intersects.

And so many times when you're talking to a team that has maybe only focused on one service, right, they're very hyper-focused on what their application does. But once you start having a more kind of holistic view, you start seeing how these things don't talk to each other, how they have different silos, and your job is to kind of fix that.

Next slide. Second thing is they have been part of a data team. We're deeply involved in major da major data initiative. A common one is building out a data platform, um, where they took ownership of the handoff of data between software and data teams. Let's go to the third one. Despite their deep involvement in data, they recognize it's not their area of expertise and thus rely on a specialized knowledge of data teams such as engineers, scientists or analysts.

Um, I think maybe you've been that role. I've been in startups so many times. There is no data team, it's just software engineers and they're the ones that first build the databases and then you hire data engineers and you come back and you're like, oh, we need to fix some things. You actually need to put a proper data model.

We actually need to separate, you know, transactional and analytical database. There's things like that. Um, and so they recognize where their limit is for their expertise and know how to bring in the right people to complement it. Next slide. Um, they view data as a product within the organization and they seek ways to maintain this data in the same fashion.

They maintains software they see. Um, we've been hearing there's a lot data as a product. Um, basically is data shifting from being, hey, we're just doing a dashboard, doing reports to actually being a line of business driving revenue or mitigating risk that you serve to people or they serve the insights.

Um, next slide. And then finally, leadership views. These individuals that special ops who are Optum move to different units from the organization and they create structure and fix the most challenging problems across the code base. And many times I kept on coming across these, uh, data conscious software engineers and multiple calls I would do.

Often I would hear, yeah, I just moved to this team, or Yeah, I got pulled from this team and added to this leadership right here. Um, because leadership saw the value they had and really taking complex messiness and putting structure and connecting the wider business together. Next slide. And so what data teams can start doing today knowing that there's this data conscious software engineer somewhere out there in the organization.

Next slide. While this persona is a unicorn today, I imagine they're hidden within your very org and without anyone really realizing it. And if I were on a data team considering data contracts, I would highly prioritize finding a software engineer with these five characteristics and building a relationship with them.

Now, do they have all five characteristics, characteristics, characteristics? Maybe, maybe not, it doesn't matter. But you need to find someone who's actually really thinking about the empathy of data teams and how it connects with software engineers. Um, they could also potentially be the missing link to improve data utilization within the organization.

And I now just remember the point that I wanna say earlier, now that I have this slide here, was the biggest thing that this data conscious software engineer does is translate data language to the software engineering team for them to get it and get bought in. And one of the big kind of aha moments we had at Gable was actually talking about data lineage to software engineers.

So as data people, we understand data lineage. We're like, Hey, data goes here, moves there, goes there, we're following it. But when we talk to software engineers, they're like, data lineage. What's that? Then we show 'em a graph and they'll be like, oh, you mean dependency graph? And we're like, yes, yes. That is what we mean.

Um, and essentially is that having that translation layer, you can be talking about this very similar things, but having that key stakeholder that understands who you're trying to sell to internally within business can be the game changer that actually starts getting you buy-in. Next slide. And so that, that concludes it.

And so here's a little, uh, QR code that you can scan if you wanna download the early release book for free. And we can do q and a. Um, so you can stop sharing. Nice. Wait, don't stop sharing. Keep that QR code up. Oh yeah. Keep the QR code. Why? I didn't even get time to grab my phone. I want to get that. Oh, man.

So, all right. Amit was saying something that I feel like, uh, is worth bringing up here. A data conscious software engineer can also be a data product manager focusing on a data product. Cool. We got this. Got it back. What, what was the question again? Focus. Mark. Come on. Focus. What are we doing here? You keep forgetting thoughts and stuff midway through your talk, man, I'm just so smitten by your music.

I just lost, lost track. All right. Data conscious software engineer, uh, can also be a data product manager focusing on a data product. It's not really a question, it's just a statement that I thought you might have. Yeah, I mean, I would actually really agree with that, that statement too. Because the thing, again, think about it, what does the product manager do?

They oversee the larger business, they're deep talking to the engineers and they're talking to the business and they're translating between the business and the engineers. Um, I can see that being a very, very similar role. Yeah. It's uh, it feels like that has, that translation layer has been spoken about many times today.

And it is very interesting how we think that layer can be and what that actually does and how it gets enabled by different tools or different processes, whatever it may be. So, so I like that you're bringing it to that. We got another question for Mark. If you're working for a small team or a small project, at what point do you recommend data contract practices?

Sometimes as the organization gets bigger, it's harder to implement this practice, especially if you're not a manager. Any advice on how to improve your practice? Yeah, so I think one thing to separate is that if you're a small org versus you're a small team, because what really data contracts is helping out with is this change management.

And, um, something we talk about in the book is called Dunbar's number is after you reach a certain point there, your human mind can't manage as many connections as possible. And so communication breaks down, the business breaks down, right? And so that's where change management data contracts become very powerful.

But if you're not near that number and you're a small team, data contracts may be way too heavy. You can get by with just a Slack message and a walking over to the desk, right? Um, because there's only a few people that you interact with. So that's also another thing that I don't try to push data contracts for every single org.

You really have to have this scale communication problem that warrants needing to automate this change management and communication. Well put. I like it. And then the, uh, I think you make a good call out there, the differences between small team and small small org, right? Yeah. Now, yeah, because meantime you can have like data teams can be this nice to have that they're trying to experiment with to understand like, Hey, what does data look like to grow this function?

Right? Um, and for example, like the mini startups I've been at, right? Heavy, heavy software engineers for like the first few years and then they start adding a data team. Um, at the last role, I was the first data science hire, um, for that. And we slowly started building up. Um, there's a lot of data involved, but it was like a team of two or three, um, working with like 30 engineers.

Yeah. And it, and it's funny because at that point you realize why it just about all of us who have been to data meetups over time, you hear some form of a talk from a data practitioner that says something along these lines that I'm gonna paraphrase. We need to make data a first class citizen. We've heard that talk, right?

We've all heard somebody because they've been scarred in the past, and so they're going to a meetup and they're like, I need to change some things. Hopefully I can plant the seed and not let you repeat that mistake. And this, this may be, well not, I don't wanna say too spicy, but like I would argue that data kind of already is, is just that everyone's talking about differently.

They're not lying on the same definition so that they're basically arguing on the semantics of it. At the end of the day, everyone wants stable code, a stable product users on it, understanding how you can improve it, right? Software and data, hand to hand. It's the how you do it and how you prioritize it and all that gets lost in, in kind of conversation.

That's where I think data contracts are really powerful because it provides a mechanism of framework to have that conversation and have it under version control so that way people can be held accountable to it. Yeah. Awesome. So another question coming through here, and this one has come up a few times throughout the day, so I think it is maybe blog worthy since you're, you're the artist here with the blog and the, the pen is your sword.

What are the intervals of data contract updates? Like if the code is refracted, is that an automatic need for a contract update or something similar? Yeah, that's a, that's a really great question. And so I think there's something that, that needs to be understand is that, is there an unexpected change?

That's where contracts are really powerful and that you need to, you know, put constraints on the code or the data itself, or going back to that business logic lifecycle, is the business evolving and the, and the data actually, and code actually does need to change such as a refactor? Then I would argue the contracts itself need to change to align with this new reality of that.

Um, and so typically what happens that is gonna change regardless, but do you wanna have version control and change management and kind of a conversation about it, or do you just wanna find out later where your data model just kind of breaks and blows up on you? Hmm. So there was another part to that question that I'm gonna get to now, is what major reversible decisions need to be made to incorporate a data contract on a mature application?

Mm, that's really good. So what we, what kind of, going back to what I was saying earlier, the first step is the data catalog. You have to understand what's there. Um, I, I wish you can see this in the book now. We're currently editing, editing it, but we're talking about how do you find your first data contract project?

And it's a concept we call steel threats, where essentially as you identify, alright, here are the potential, uh, data products that we have in the business, especially if we established business, you're gonna have like hundreds, maybe thousands of them, right? You then need to start identifying which data products are actually driving value for the business.

And then among those, which of those teams you have active relationships with. And then from there, which teams actually wanna work with you, and then which ones can actually get budget for you. And slowly you'll start being willing down to like a few key set of projects. And then your jo, your job there is then to basically crush that POC and be like, Hey, we improved data through this process.

Um, other teams you should try to adopt this as well. And you start building momentum that way. And so the thing is, you know, uh, was the phrase that how you eat elephant one bite at a time, um, you have to identify, start small, but highly impactful and then grow from there. So you, you shouldn't try to boil a ho ocean at once.

Uh, when it comes to this brilliant. I. Think we are, I think we're at time. We're three minutes over time. That's how bad I am at this whole timekeeping thing. Perfect. Well, other, well, I'll stop sharing and then we can, uh, switch over to our next guest. Yeah. And there's more questions that are in the chat and in the q and a, so I'll let you get to those when you're ready.

In the meantime, we got another speaker that I'm gonna bring onto the stage 'cause uh, mark is outta here. Apparently he's, he's off the stage. I'm still here. I'm just switching over. He exited stage left, he shifted left on us, and now he shifted. So far left.  He's out of the frame."