Transcript
Speaker: Hey everyone, welcome to Data Knowledge Pioneers presented by Workstream IL.
Speaker: And we're exploring how organizations create shared consciousness about their data.
Speaker: I'm Nick Freund and I'm speaking with leaders and data practitioners around the, or about the acute problems they experience in creating, curating, disseminating knowledge about their data.
Speaker: Today, we're going to explore the issue or problem of data assets sprawl.
Speaker: Joining me are two awesome data leaders who really know how easy it is for analytics environments to descend into what I would call a state of chaos.
Speaker: First off, we've got Jamie Davidson,
Speaker: who's the co-founder of Omni, an awesome new BI platform that they're developing.
Speaker: So I highly recommend you check it out.
Speaker: And he's a former VP of product at Looker.
Speaker: And we also have Ted Conbeer, who's the chief data officer at Privacy Dynamics, which is also another
Speaker: great new company in the data space.
Speaker: I asked Ted to join because he was the former SVP of data and strategy at MakeSpace, and he was a very early adopter of Looker.
Speaker: Hopefully, we'll have some good discussions from both the builder as well as the data practitioner side of the house about this problem.
Speaker: Anyways, Jamie, Ted, thanks so much for joining today.
Speaker: Thanks for having us.
Speaker: Yeah, thanks, Nick.
Speaker: Of course, of course.
Speaker: So to start, I just thought maybe we could like dive into the problem of data assets sprawl and what we think it is and how we kind of want to define it.
Speaker: And for me, as I was kind of just mentioning, I kind of define it as this phenomenon of entropy in analytics environments or this like descent into chaos where over time more and more stuff gets created.
Speaker: And you just end up in this state where there's a lot of things and kind of people don't know what to use or trust.
Speaker: So, I mean, you know, Ted, we've talked a lot about this.
Speaker: I would just be curious, like, is that how you would define it?
Speaker: Would you define it in a different way?
Speaker: How would you characterize this problem?
Speaker: The way I look at it is kind of, you know, new tools like Looker and the other kind of modern BI tools have made it so easy to create and share analytical assets, you know, dashboards,
Speaker: And they say, with any software, 80% of the cost of building software is actually maintaining it, but no one is actually maintaining these analytical assets full-time.
Speaker: And they're not treating them like true products.
Speaker: There's a lot of talk of data as products, but there's really hardly any maintenance, there's no observability and things like that downstream from actually creating that asset.
Speaker: At MakeSpace for a long time, I was a data team of one, and then we had a small team supporting a couple of hundred people in the field.
Speaker: We would have to partner with power users across the organization, and they were really good at creating assets.
Speaker: But those things would quickly go stale or break or get out of date.
Speaker: But it wasn't clear in the tool which assets were trustworthy and which assets were maybe stale or out of date,
Speaker: me up at night.
Speaker: And that's really what I think about when I think about data assets sprawl.
Speaker: Makes sense.
Speaker: Jamie, I know you ran data at Looker internally for a while and obviously you've worked with lots of customers.
Speaker: Does that resonate with you?
Speaker: Does that sound right?
Speaker: Do you have a different take on it?
Speaker: No, no.
Speaker: I completely agree.
Speaker: I do think entropy is a good way of describing it.
Speaker: I think
Speaker: part of the value of these tools is they're lowering the friction from asking every incremental question so you can ultimately derive insight from your data, making it as easy as possible.
Speaker: The problem with lowering the friction, though, is you end up with a proliferation of logic.
Speaker: So every single permutation of every single question you get ends up with a new asset, a new dashboard that's looking at your sales funnel for this product line, for this region, for this time frame, and whatnot.
Speaker: And
Speaker: without sort of proper maintenance of that sort of, you know, those assets or without looking at like, you know, a software development process or a product process too and recognizing, you know, there's a cost to those things, you end up inevitably in sort of a state of like what we would call kind of data chaos, like where you look for what is my canonical sales pipeline and I get 15 different answers from 15 different dashboards potentially with, you know, materially different, you know,
Speaker: results and driving different decision-making too.
Speaker: So I think it's a key problem.
Speaker: I think it's a technology problem.
Speaker: I think it's also a process and people problem too, kind of like software development and product development in the first place too.
Speaker: Totally.
Speaker: I mean, do you
Speaker: If it's both a technology and process problem, do you think it's shared, like 50-50?
Speaker: Is it 80-20 one way or the other?
Speaker: Well, the people side is actually probably typically way, way, way more difficult.
Speaker: How do you deprecate assets?
Speaker: How do you discover things?
Speaker: How do you empower an organization to make good?
Speaker: good decisions.
Speaker: How do you, like even a simple, you know, there's been a rise in folks talking about things like the metrics there.
Speaker: How do you define your KPIs in the first place and get a canonical definition and agreed upon definition to across an organization?
Speaker: I think those things, it's,
Speaker: It's much more around the business, the process associated with it too.
Speaker: Defining the metric is actually not that difficult to do.
Speaker: Every SQL analyst or every data scientist will go and do this and redo it in every permutation.
Speaker: In general, it ends up being mostly a
Speaker: people problem.
Speaker: I think people problems can be helped with technology, though.
Speaker: I think technology needs to basically serve as a means to reinforce canonical definitions.
Speaker: Looker would talk about a single source of truth, having a single place that you define metrics and then
Speaker: have the ability to have change management processes like software development lifecycle, get version control and the like.
Speaker: That's absolutely... It helps with... It enables you to go and have some of that people process.
Speaker: But the people process is the most important part.
Speaker: That's where I think most organizations fall over.
Speaker: Ted, I think you were calling that out too, right?
Speaker: That a lot of this was felt as you were enabling...
Speaker: folks around self-service?
Speaker: Do you agree it's fundamentally a people problem?
Speaker: I guess so.
Speaker: I think in some ways the technology and the expectations around the technology have created the people problem from my standpoint.
Speaker: When you emailed someone an Excel spreadsheet, you put the date and the title of the spreadsheet, somebody opens it a year and a half later, they don't expect to be able to make decisions using that year and a half old spreadsheet.
Speaker: I'm good to go now.
Speaker: And so it's kind of fighting that default expectation of like every dashboard should live forever and every analysis is not a snapshot of a point in time.
Speaker: Like it's not something that used to be true back then.
Speaker: It's something that is true now.
Speaker: That is a really hard problem to fight is like, especially on a small team, right?
Speaker: I was like I said, like one person supporting 200.
Speaker: at one point up to a thousand looker dashboards and many thousands of saved looks.
Speaker: You could say that's a people problem because I enabled all these people to create that information to begin with.
Speaker: But we were getting a ton of value and unlocking a ton of great things by allowing that proliferation.
Speaker: But then not having any tools to scale myself to reign that back in was really where I ran into a bit of a wall.
Speaker: Just to pile on there too, I completely agree.
Speaker: I think if anything, the technology has exacerbated the people problem, not necessarily solved for it.
Speaker: It's something where it's one of the founding core ideas for Omni now is recognizing I worked with probably thousands of Looker customers.
Speaker: I probably met with personally a thousand Looker customers too over my time there.
Speaker: And I
Speaker: almost all of them ended up inevitably in a state where there's effectively data chaos, and we would call it model rot, where the content is suddenly disconnected from the data.
Speaker: You've lost columns in the database, you've lost tables in the database, you've now got inconsistent logic, even though you've got this overdevelopment lifecycle that can...
Speaker: govern the development of LookML, you end up... It's sort of like a net additive thing.
Speaker: You end up with a huge proliferation of it.
Speaker: And so I think one of the things that you were kind of highlighting, but I think it's super interesting, actually thinking about the maintenance of your instance too as a part of the product problem in and of itself too, where perhaps not everything should be shared and shared consistently across it.
Speaker: In Looker, we would have...
Speaker: customers that would turn off features like our PDTs, which is a way of creating a materialized table that would be in code sort of business logic and materialize it in the database.
Speaker: People would turn that off because they'd end up having a huge proliferation of it too.
Speaker: I think you see even worse now with DBT where everyone is now an analyst engineer and everyone's got their own schemas and they will add to the tables.
Speaker: We have to think of data...
Speaker: in data assets effectively as a curation problem.
Speaker: Maybe not everything should be part of a canonical data model.
Speaker: Maybe something should be siloed, but we firmly believe there's a maintenance step.
Speaker: There needs to be higher order constructs to allow for optional promotion paths for the things that are in fact actually reusable that need to be part of, you mentioned observability, need to be part of something that looks probably a lot closer to CI-CD actually.
Speaker: It looks closer to a testable, verifiable kind of a process for key operational metrics or for key operational workflows.
Speaker: Yeah, I totally agree with that.
Speaker: I think borrowing from software helps a lot.
Speaker: There is one key change or key difference between, I think, data and software, which is that
Speaker: in data, like your truth is kind of defined by who's using those assets.
Speaker: And there's kind of a social aspect of data and the conversations that happen around data.
Speaker: So you might have multiple definitions of a metric across an organization that might be similar, but meaningfully different and purposefully different
Speaker: team.
Speaker: But if you're on the ops team, what you really care about is like, what are the numbers that my boss is looking at?
Speaker: What are the numbers that the COO is looking at?
Speaker: You know, you probably, when you search for an asset, you shouldn't find the dashboard that the CFO is looking at, right?
Speaker: Like,
Speaker: that set of numbers in two years, so he probably doesn't care about them.
Speaker: Yeah.
Speaker: Literally when I was trying to maintain the data sprawl at MakeSpace,
Speaker: Even though I had in many cases built the canonical sales dashboard at one point or built the canonical ops dashboard, I would always reach out to our VP of sales on Slack and be like, what dashboard do you guys look at every day now?
Speaker: Because that's the one that I'm going to use.
Speaker: It doesn't matter what I booked for six months ago.
Speaker: It really doesn't.
Speaker: They might have moved on.
Speaker: And I think that's great how reporting can evolve.
Speaker: that would really empower especially centralized teams to understand what the heck is going on out there across all these data assets
Speaker: I completely agree, too.
Speaker: It's amazing to me, but we don't use usage-based features or functionality, too, to feed back into the consumption process.
Speaker: It's like, we don't know the metadata about who created things and when were they last used and who's using them in a disparate way, too.
Speaker: I think that that's...
Speaker: That's ultimately the most important signal.
Speaker: If this metric is what's being used to drive operations, that's the metric we should actually care about versus the theoretical best metric or the right metric or whatever it is.
Speaker: It goes to Ted's point about or the point in general about data as a product, right?
Speaker: What does that actually mean?
Speaker: if you're building an actual product, the most important metric about a feature or an area of your product is, do people use it and how do they interact with it?
Speaker: If they're not, you probably want to take that to end of life.
Speaker: That should be part of the discussion, but often it's not.
Speaker: I think also, too, their defaults are really important.
Speaker: So by default, not every dashboard should be a persistent dashboard for forever.
Speaker: By default, maybe, in fact, actually everything is auto end of life.
Speaker: Maybe you don't lose the conceptual logic, like we're not throwing away the sequel, but you have a big warning, hey, this hasn't been touched in three months, user beware kind of a thing.
Speaker: I mean, a lot of this, and this is where I potentially can jump the shark and take us in like a completely random direction.
Speaker: But, you know, as I've thought about these problems, especially like the people dynamics, I think a lot of it...
Speaker: a lot of it comes down in some ways to like the problems of information asymmetries, right?
Speaker: And if you believe that in some way, shape and form, like data builders and data consumers in an organization like construct a market, right?
Speaker: There's asymmetries in the information that they have about the data and how they use it, right?
Speaker: And there's like...
Speaker: There's whole theories in economics about how you resolve information asymmetries.
Speaker: And the classic example of a problem this creates is the used car market, right?
Speaker: Where the buyer of a car doesn't know whether the car is a lemon or not, and therefore they're not willing to pay a lot of money for the used car.
Speaker: But the seller can price things efficiently.
Speaker: And I'm not saying that
Speaker: every dashboard or piece of data that gets shipped as a lemon, but I do think
Speaker: folks are looking at what's available to them and you're like, well, is this a lemon or not?
Speaker: And how do I understand that?
Speaker: And there's an information asymmetry from the consumer side, but then to what both of you were just saying, there's also information asymmetry from the builder side because you then just don't have the information that you need to maintain the product or evolve it.
Speaker: Yeah, it would be like listing your car for sale and never knowing if it's sold or not.
Speaker: But I think there's also just the recognition that some of these things we build are lemons.
Speaker: Some of them aren't useful, some of them aren't accurate.
Speaker: Often those feedback loops are broken to begin with.
Speaker: But when you know that those things exist out there, yeah, it's impossible to build trust across an organization that there are extremely high value, very
Speaker: value decisions.
Speaker: That's a really difficult task for any data team is to build up that kind of trust.
Speaker: Because once you have it, the whole organization can move a lot faster, they can be a lot more independent.
Speaker: That's like the dream of self-service.
Speaker: But it takes a long time to build that and a very short amount of time to lose it.
Speaker: You don't always even get that feedback when
Speaker: Yeah, I completely, completely 100% agree too.
Speaker: I think ultimately it's really like it needs to be a partnership or like, you know, if you're building data as a product too, you got to be a product manager, you got to go talk to the customers and like, is there a contextualize the product that you're building?
Speaker: It's, you know, I think that
Speaker: the data folks often have the context for, you know, like they understand the schema, they can understand sort of, you know, the ETL process and the freshness of the data and the accuracy of the data.
Speaker: They often have a disconnect from like actual use.
Speaker: So like what is, what is actually important for, you know, the sales pipeline or for this product or for this department or for what, what, whatnot.
Speaker: And sort of, you know, the, the partnership I think actually is, is,
Speaker: I think this is kind of a people problem or a process problem, too.
Speaker: It's like, how do you contextualize both enough of the technical side with the sort of like pair it with that business context to sort of have that feedback loop kind of going both ways?
Speaker: Yeah, I loved sort of embedding or pseudo embedding analysts in teams.
Speaker: So, you know, I would have, you know, my team would report to me, but every week they would attend the marketing conference.
Speaker: you know, metrics review or every morning they'd attend the ops daily review because then they get to actually see, you know, how the teams are using their dashboards.
Speaker: They get to hear the questions that come up around the data and be part of that kind of dialogue.
Speaker: Because without that, yeah, you're completely blind.
Speaker: And I would, you know, if we got busy and our team members stopped attending those meetings or something like that, it just felt
Speaker: faster than you would think.
Speaker: And, you know, it takes a ton of engagement and a ton of feedback that honestly isn't natural for stakeholders to provide.
Speaker: Like they might not even know the changes that are happening behind the scenes or under the hood that might make their data less accurate.
Speaker: But it's also just like asking them to finish their day job and then think critically and think hard about, you know, how they could use data better or what parts of their reporting, you know, don't answer
Speaker: That's a lot to ask of somebody who's very busy with a completely different job.
Speaker: But that's also a very expensive people solution to a problem that we hope could be, you know, sort of supplemented or the solution could be supplemented by usage data or other kind of types of things that we talked about.
Speaker: Totally.
Speaker: I mean, I think...
Speaker: Part of the challenge there, just from having talked to lots of teams, is how do you manage the demands on your team of all of your various workflows?
Speaker: You've got all this engineering work that you have to do, there's service partnership-related interactions, and then there's the long-term product management.
Speaker: There's a lot to put on.
Speaker: generally a small group of people, right?
Speaker: And there's lots of context switching there.
Speaker: And so if you just lean fully into the people version of the solution, right, it's a hard one to scale and get right.
Speaker: It requires a lot of judgment, I think, in some cases.
Speaker: And in many cases, like, and I hope this is changing, and I feel like it is, but in many cases, our data
Speaker: 23-year-olds, smart, ambitious, but don't have the context and the years of experience to understand the long-range consequences of what they're doing.
Speaker: Often, analysts are over-eager to build
Speaker: and answer a question for the first time because it feels great, but they don't appreciate the costs of supporting that thing that they just built into perpetuity.
Speaker: And so that's definitely something that I learned kind of the hard way over and over again.
Speaker: And now having done this kind of job for many years,
Speaker: the difference between getting someone a quick answer and making it clear that this is like a one-off exercise or a one-off kind of analysis that might sort of be contributed to a knowledge repository, but doesn't become a piece of software that I have
Speaker: to maintain forever.
Speaker: And I make decisions about how I build it and how I communicate the results and how I set expectations in order to enable that.
Speaker: Because if you don't do that and you think you're in like kind of product building mode and you set those expectations or you make certain investments in building that product, like you can end up in a really bad spot, you know, six months down
Speaker: really tricky balance to strike there.
Speaker: You've just been talking about it now, but historically, you talked about embedding, what you were just saying.
Speaker: What are the top mechanisms or solutions that you had implemented to try to address some of this in the past?
Speaker: My biggest hack that I wish I could sort of copyright and take credit for is I would basically offer to do a dashboard review for anyone in the organization, turn around in less than 24 hours.
Speaker: So go out, build whatever you want, send me the link and I'll look at it and I'll give you a thumbs up or thumbs down in 24 hours.
Speaker: need to know about or be aware of.
Speaker: And that's the same thing for if anybody wanted to say, hey, I'm about to use this dashboard to make a decision.
Speaker: Does this look right to you?
Speaker: I found it.
Speaker: Someone built it a year ago.
Speaker: Can I use this?
Speaker: I just over and over again and almost
Speaker: every interaction with my stakeholders across the business and product and ops and marketing, I would just repeat this over and over again.
Speaker: I'm like, if you ever don't know, or if you don't use the dashboard every day and you just found something, you want to build something new, just send it to me.
Speaker: Because I can take 15 minutes and probably tell you if it's close to really right or not.
Speaker: But if you never send it to me, if you never ask, I'll never know.
Speaker: And then like, you know, I kind of washed my hands of it.
Speaker: And if you end up making the wrong decision, I'm going to like not back you up in that meeting.
Speaker: But I really think that that helped build a lot of trust.
Speaker: And it put this kind of people in process step in place that helped at least guard against like the worst case scenario, which is somebody wakes up, finds a dashboard and like makes a huge decision off of bad data.
Speaker: And I'm sure, too, that also enables folks to learn.
Speaker: You're empowering folks to go do self-service, too, because you've got a step to validate and verify that something is okay.
Speaker: But it's okay if the product analyst goes and builds a new dashboard and then can vet it.
Speaker: That's a feedback loop in and of itself.
Speaker: That makes a ton of sense.
Speaker: That's awesome.
Speaker: Yeah, it empowered people.
Speaker: I felt like it was time very, very well spent.
Speaker: And it dramatically lowered my stress
Speaker: clear across the organization.
Speaker: Ted, did people take you up on that a lot or was that more of the thing you did every once in a while but then people actually?
Speaker: Yeah, I did it multiple times every day.
Speaker: Oh, wow.
Speaker: That's a lot.
Speaker: Yeah.
Speaker: It wasn't a full request that Ted validates this and certifies this in perpetuity.
Speaker: This was more like a one-off gut check or was it more of a spectrum?
Speaker: I would say the request was always just like, hey, is this right?
Speaker: write in a month.
Speaker: Like people don't really think that way in my experience.
Speaker: So it's like, Hey, is this right?
Speaker: It's a quick message in Slack, like one line, like in a link, that's it.
Speaker: That's all I need.
Speaker: And then I would take 15 minutes and write back usually just a couple of sentences around, you know, yes, this looks great.
Speaker: Or most of this is good.
Speaker: This one thing worries me, or I want to make sure you're thinking about this metric the right way.
Speaker: Cause I know that metric can be really confusing.
Speaker: And I don't know that we've like,
Speaker: I've trained you on that metric yet, you know, things like that.
Speaker: So we kind of ran the spectrum.
Speaker: You know, the highest level of engagement for me would then be like, okay, I'm going to schedule a meeting with you for 20 minutes tomorrow.
Speaker: We're going to talk about my concerns about this.
Speaker: I'm going to push you in the right direction or train you on a new way to kind of get to the numbers that you're looking for.
Speaker: Or, hey, I need more context about what you're doing.
Speaker: Like, let's talk about that.
Speaker: And then I can give you better feedback.
Speaker: So it usually was a very high leverage activity.
Speaker: like once the team kind of scaled up, then either I would, you know, divert those requests to members of my team or like that would become instead of a one-on-one conversation, it would, you know, become a me and my team member with our stakeholder kind of a conversation.
Speaker: So again, we're sort of building that knowledge internally and building that trust and building a relationship between the more junior members of my
Speaker: a way that I could offer to be really helpful, like increase my engagement with everyone across the business.
Speaker: And it just, it always ended in these conversations that just felt really good and didn't honestly take that much of my time.
Speaker: Jamie, is there other things you've seen teams do or your teams have implemented in the past to try to solve some of this?
Speaker: I mean, honestly, I always loved sort of hub-and-spoke embedded analyst model, too.
Speaker: I think a lot of it, I think this is true for, like, my product teams, but, like, it's certainly true for data teams, too, building for product.
Speaker: You have to build empathy for customers.
Speaker: Like, that is clearly the best part.
Speaker: I've seen...
Speaker: Folks do things like office hours or training very deliberately, like as a part of onboarding, even like so they're doing a new tool or bringing new people on to the team, sort of like promoting an atmosphere of data literacy where there's some contextual piece like this is.
Speaker: you're the marketing ops person and like we're going to train you on the marketing metrics or the marketing dashboards and stuff.
Speaker: And like you sort of learn some best practices from that process.
Speaker: But like there, it's sort of, it's variable.
Speaker: It's variable with like the quality of the content and the engagement and then also to how much, you know, anyone like,
Speaker: I mean, basically, like, to contextualize it fully, it's like, how does this help me do my job better?
Speaker: And so, like, you have to kind of inspire the, you know, why look at data?
Speaker: Why will this improve your process and whatnot, too?
Speaker: And I think that tends to be almost like a cultural thing that's embedded as opposed to, you know, something that can be kind of
Speaker: you know, brought or like, you know, changed in a one-off, you know, handful, like having like the single office hours, I think it's hard to just, to just change it.
Speaker: Aside from that, like it's, I think the other area where like folks end up breaking down quite a bit is sort of like there's the interface between sort of the business and analysts and BI kind of folks too.
Speaker: Then there's also the interface between analysts and kind of the data engineering, you know, the infrastructure-y folks.
Speaker: And like the, that's whether it's like,
Speaker: ETL or 5Tran replicating SaaS metrics or whatnot, where there's losses in context there.
Speaker: And I think the rise of the analytics engineer is amazing and people are actually able to do...
Speaker: things like data transformation and pre-processing of data and Snowflake and BigQuery make things possible and FiveTrain makes things possible, which is great.
Speaker: I think you still see the product team ship the new feature and change how their
Speaker: their underlying data model works for their product, which is totally fair and should never be gated on by data, but may break downstream things or have unintended consequences for downstream things too.
Speaker: Another area where we see a lot of
Speaker: Just like, you know, like the entropy again, you know, in it where like the columns change, the tables change, like the, you know, the meaning of things may change, you know, in a way that's like not as intuitive to folks too.
Speaker: It can also still have that like same...
Speaker: terrible end-user experience where I thought all the logic was consistent, the SQL is good, but you're now throwing all of the experimental records in or the deleted records are in from Salesforce and now they're all present because the DBT model changed a little bit and we didn't really realize it downstream.
Speaker: But yeah, I think all of this is always an iterative process where you have to continually talk with more and more folks and go back to
Speaker: first principles like, hey, we want to solve this problem.
Speaker: We need this data too.
Speaker: Let's make sure it's all the way up and down the stack is verified too.
Speaker: And have partnerships all the way up and down to the end business user through the engineer who's actually enabling it.
Speaker: Yeah, I think, Jamie, one thing that you kind of touched on
Speaker: is for this is it's really hard tech to build.
Speaker: I mean, detecting sort of schema changes is one thing, but the schema doesn't have to change to totally break the recording, right?
Speaker: sales and then you launch a kid's line or something.
Speaker: The data can change without the schema changing.
Speaker: You could write a dbt test for what are the accepted values of that column, but that person
Speaker: who's a few layers deep in the marketing organization, who cares about the sales of kids' pants, is not going to go and write a DBT test to validate the assumption that they made in their dashboard.
Speaker: it's really, really hard to sort of future-proof something when there are so many kind of degrees of freedom and so many different ways that your data or your assumptions can become kind of incorrect.
Speaker: Yeah.
Speaker: No, I completely agree, too.
Speaker: Like I'd say, you know, it ends up being like a problem that has a bunch of different disparate sort of
Speaker: I guess owners of various parts of the solution too.
Speaker: And like they all have to interface in order for it to actually come together to work too.
Speaker: So like it's a, it's like, you know, when you're the one, one person data team and you're doing everything and like you have all the context of the business and stuff too, like that's a, that's a favorite, favorable place.
Speaker: And like, that's a, it's a, it's amazing.
Speaker: You can kind of go really quickly too, but then inevitably complexity creeps in and like you want to have specialization and like,
Speaker: and suddenly, yeah, that's exactly right.
Speaker: You've changed what the definition of these things mean.
Speaker: So as a result, even if SQL's still valid, it's not what you think it is, actually.
Speaker: That's exactly right.
Speaker: Some of these changes, it becomes impossible to control for all of them, right?
Speaker: And I think it goes back to what both of you have been saying around
Speaker: investing in the relationships and the partnerships.
Speaker: In some way, this is everyone's problem to address.
Speaker: It's not just the data people, but it's also the folks throughout the business who are consuming the data.
Speaker: Maybe it's the data team's job to go and evangelize that and to catalyze that.
Speaker: We ultimately have to create a culture around it where you've got the quote-unquote customers talking to the builders or the product people.
Speaker: Yeah, exactly.
Speaker: Cool.
Speaker: We've been going for a while.
Speaker: I think that might be a good place for us to wrap unless either of you have anything else that you think we should cover.
Speaker: And again, Ted, Jamie, thanks so much for joining and thanks for everyone for listening to
Speaker: uh data knowledge pioneers uh uh and again i'm your host nick froy and founder and ceo of workstream io um and if you're excited to learn more uh please join us next time uh where i'm going to be talking to the founder and ceo of brooklyn data company scott brighton donor uh and the head of analytics and future michelle ballon and we're going to talk about uh or dive more into uh kind of tribal knowledge about data and how to capture it and empower your team so
Speaker: Ted, Jamie, thank you.
Speaker: And thanks everyone else for listening.
Speaker: This is fun.
Speaker: Thanks.
Speaker: Thank you, Nick.
Speaker: Thanks, guys.
