Increasing the perceived value of your data team with Aaron Wilkerson - Episode #62

Welcome to the Agile Data Podcast, where we talk about the merging of agile product and data patterns in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

I'm Aaron Wilkerson.

Hey, Aaron. Today I thought we might want to talk about the value of data teams, or more importantly, the perception that there is no value in a lot of data teams. And why that's a problem, how we can see it happening, and more importantly, what data teams can do to increase their perception of value in the organizations they work in. But before we do that, why don't you give us a bit of background about yourself for the audience? Sure.

So I'm Aaron Wilkerson. I'm the Director of Data Strategy and Products at Carhartt over in the US, based out of Michigan, just outside of Detroit. Metropolitan area. So I've been working in data just over 17 years. I'm one of the, the fortunate few where I've been working in data even outside of college, universities. This has been my kind of career since I got out of school and got my degrees, working in data whole time, which doesn't happen a lot. A lot of people fall into data from different areas, but I happen to have a job out of school with data, and I learned about it and just kept going and just built my career working different parts of data. So I started with A lot of background reporting. So Business Objects, back before SAP bought them, acquired them, I used to work with Business Objects, building out physical servers, installing software, doing security, all that. Um, years later I got into this thing called ETL. So I learned about what ETL is. I learned about data warehousing and got involved with data architecture and then really got into leadership. I realized that I had a lot of questions. I wanted to dig into a lot of things, but I found that being an individual contributor, I was very limited in what my opportunities were and the conversations I could be in. So then I said, I want to try this thing called leadership. So I would say for the past over 10 years, I've been doing different data leadership roles. So I've been a team lead, been a manager, senior manager, now in a director role. So I've done many different parts of leadership. So always leading data teams, working in data the whole time. It's been an interesting career. Done all the different parts of data development, Reporting, been analyst, architect, all different parts of data. Only thing I haven't done is like pure data science type of roles, but I would say anything else in data, you bring it up, I probably have some type of experience with it. So it's been a fun career. I would say now I'm really looking into, along with the day job, also doing what you call it thought leadership. So I'm very heavily on LinkedIn. That's how Shane reached out to me, just sharing thoughts of, hey, I've been doing this for a while, so I probably have perspective about it. So I just start to share just things in my head about what I'm working on, what I used to work on, challenges, opportunities. Communities, and you'll see me a lot just posting almost daily on LinkedIn. Also have newsletter I'm working on. So really just trying to start to share with the world my experiences. I realize that it's a pretty small world. So like we're talking, Shane, you're on the other side of the world, and I'm sure a lot of things I'll say resonate with you. So we find that there's a lot more that's similar about us when it comes to data that's different than us. So I think that's the next level of my career is senior leadership plus just building out a data community on social media.

Yeah, it's good, good to find another old school data person, Business Objects Brings back a whole lot of memories of the Business Objects, Cognos, SQL Server Reporting Services days. And as you said, 10 years ago, we wouldn't be doing this podcast unless I'd flown to the States or you'd flown to New Zealand. And for me, it's quite interesting that these changes have meant that our ability to improve our time to market for the data work we did should have been perceived as us providing a shit ton more value. I remember the days, because New Zealand's at the end of the world. In fact, it's so far away that when people talk about Carhartt, I didn't actually know what that company did until I saw a whole lot of comments around clothing and who's wearing what. It's amazing how disconnected you can be. And back in the Business Objects days, we were at that stage where we had to ship servers into New Zealand to rack and stack them into our data centers before we could actually do anything. It was a 6-week delay before we actually got access to new compute, whereas now with cloud, we click a button and and increase the size of our database or create a new service in a heartbeat. So, given everything we do seems to be able to be done faster, there still seems to be this perception that data teams aren't adding value. And I think a lot of it comes from when the downturn happened, a lot of data teams got hit, like a lot of good people lost their jobs, and that reinforced this message or this perception that data teams aren't adding value. What are you seeing? Are you seeing that? Is it just a result of that downturn or do you think there really is a large perception in organizations that data teams aren't helping the organization deliver value?

Yeah, I would say the perception and narrative is there. I would say that they do recognize the efforts of the team, but I think it's always, we should be able to do more. It should go faster. Why is this taking so long? And I think the reason, I think it really depends on the organization. I've been part of a lot of organizations. Michigan, we have a lot of companies that have been Ralph Lauren for a long time in cars, been around for, I think, 130-somethings. So you have a lot of these legacy businesses, they fell into data and they didn't really know what they wanted data to do. So they started with, usually it's like a database, right? You have a bunch of software developers, you give them a database and they start creating this stuff in databases. And then all of a sudden someone decides they learn about data warehousing. So it's okay, let's turn the database into a data warehouse. And they start trying to build out a data warehouse, but it's really just not a lot of great models. You have these different models. And a lot of their use cases start operational, right? Hey, we need to move data from one place to the next one, and we need our own application database. So they just threw it all in the data warehouse just to move data. So I would say expectations, I would say, started pretty small around, hey, we just need you guys to do these couple things. But then as you start to build out reporting, for example, like you mentioned, we mentioned BusinessObjects, Cognos, SSRS, like all these different capabilities came out, and I think that you started to see just more expectations coming out of the data team. So it really depends upon just how the business sees the role of the data team. I know some of them, if you have a newer team, the expectations are very high. They're like, hey, we, we're paying millions of dollars in salaries and benefits for this team to come in, transform our business with data. So like the expectations are high and you're expected to produce. But in some companies it's, we don't really know. We, we want you guys to show us. I've been part of a company like that where it's, you guys show us what we can do. We have a bunch of data in this database. Can you like give us a report? Can you build something? So I really think it depends on the leader and really what that mandate is. What were you brought in to do? What is your team being asked to do? But if you don't know, then I really, then that's also on the leader to define that and say, hey, this is what I think you guys want us to do. This is what I think is important. Am I right or am I wrong? So I would say the narrative is out there around probably not providing value, but it really depends upon kind of start with just what. Is the expectations, or are there any expectations, and are you meeting those, or are you expected as a leader to bring that to the table and say, this is what we can do?

I think that point about show us is really key. I often think about data teams as startups. If you're a startup and you've built software and you're trying to change the world or fix a problem, sometimes you actually have to educate the potential customers about what their problem is and the art of the possible. And what I see with data teams is often they sit in the cupboard, they sit behind this wall of data work, and they never really go out and showcase what they've done. And so they don't sell it. And more importantly, they don't experiment or show what's possible to the organization if they use data. They wait for the request, the Jira ticket, the demand to turn up, and then they get very busy and then they give it back to them. Whereas if they spent a bit of their time for understanding the organization's strategy, like where's it going, what is its goals, and then effectively playing with data as data experts to say, hey, given that goal, if we use this data in this way, it may have value, and then going back and treating it as something they have to sell internally. I think it'd be really more fun for them because they get to play with cool data, do good shit, like actually try and help the business rather than just wait for a ticket. But also that constant feedback, that constant showing the organization potentially what could be done with data would increase their perceived value in my head. What do you think? Do you, have you ever tried that as a, as a pattern? Yeah.

And I would say I had to, I agree with that now. I would say it took me a while to get there because I think a lot of us, we came into this job because we wanted to be coders or programmers where you believe that, hey, I'm just showing up to write code and make, to build something, but it's not my job to sell people on what I'm doing, to tell people. That's like the manager's job to tell people what I'm doing. Tell people what I'm working on, why is it important, like marketing. A lot of us are back in, you know, many times nerds, where I just know how to write stuff and then someone else's job is to do, is to take care of that. But the challenge with leadership is that a lot of data leaders are just like former programmers themselves. They're the best programmer and they were promoted to be a manager, and then they're like, I, I don't know how to sell, I don't know how to market this stuff, I just know that my team is cranking out this. Up to your point, like, we're waiting for a ticket, the process is we get a ticket that comes in, we write it and we give it to someone else, and someone else's job is to sell what we do. And I think that's where it's come to detriment. So if you don't naturally get that or that doesn't come to you naturally, then I think that's where we fall short. And I was like that for a long time. I think only in the past, I don't know, 3 years I've really made that switch and say, you know what, as a leader, I have to sell what the team's doing. I have to make sure people are aware of it. I have to ask the hard question of, okay, why is this important? How does this help the business? But I would say that's not the norm. I don't think it's a natural thing, but that's because of our background. Like a lot of us, we went to school for math, so it's okay. You have left side of the equation, right side of the equation, they have to be equal. So we have very logical thing. When we work in like sales and marketing, there is no right answer. Only right answer is, did someone buy the product? Did someone purchase it? Did you make a sale? So how do you convince people and persuade people? That's an entirely different set of skills that a lot of us are not prepared for. And I, I, I think there's a lot of work there to bridge that gap, but I think that's where we fall short is we're great at delivering. We can build stuff, we can code stuff, we can come up with architecture and all that, but I think in terms of understanding just the importance of it, that's where we have opportunities.

I think also as technologists, as engineers, as data people, we probably have a negative view of salespeople. We're used to the vendors coming in and trying to sell us the magic beans that will get rid of our job or automate a whole lot of stuff that we know we can automate faster. So what I tend to say to teams is look at product management, right? If you look at those types of roles, which we're starting to see that role of data product manager come in. Into teams now, and it's not sales and marketing. It's basically understanding the business problem and then trying to figure out, ideate how you could solve it with data, discover which option is actually the best one, and then go and implement it. We don't have to go out and be incredibly salesy or incredibly marketing. We just got to go back to product management and pick up the patterns of understanding the problem, getting into that early.

Think about it, like to that point. Imagine you go to a grocery store and you see all the different products on shelf. You see cereal, you see bread, you see, I don't know, popcorn, whatever. It's not enough to put all that stuff on the shelves. The expectation that someone's going to buy that, someone's going to consume that and purchase that, and that's someone's job, right? Someone's job is to make sure that the stuff that you're putting out there, someone's actually buying that, or else it doesn't stay on the shelf. You don't see products out there that just sit there for years and no one ever buys it. The store will stop letting you get that shelf and the company go out of business. I think that we think that our role is really just to get the stuff on the shelf and someone else's job is to worry about the other part of it. But we have to go end to end in what we do.

Our store is the data catalog. And I'm always intrigued when data teams believe that having a data catalog, pumping more data into the catalog, and then that's the end of their job. Somehow everybody's going to come shopping in the catalog. Whereas actually data catalogs are only designed for data people. You go talk to a stakeholder, they don't want to use your data catalog. They don't care. There's a bunch of data in there. There's no value to them. They're not data people.

Yeah.

It's not even that, even if it's simple, it's just a bunch of data and they're not data people. So data catalogs are built for us. The idea of what's our storefront, that's an intriguing question actually. How do we surface the fact that we got 5 cereals and then We never really kill any of our products. We push out these datasets, the ETL gets automated, it keeps running. We never check anybody's buying it. We never turn it off. So yeah, there's a lot of behaviors we can implement on our side to increase the value, the perceived value of what we do. I just want to go back to one of the core fundamentals for me, which is you said, yeah, you work for a company that's been around for 100+ years. And so I'm assuming in the early days, there might've been a paper ledger, maybe with some information, or it was just run by line of sight. Aside. And often organizations don't understand the value of data, let alone the data team. They don't understand that data can be treated as an asset that can be monetized internally. And an example for me would be if your organization got sold, but they sold your organization without handing over the list of customers. So the people that bought your, your company buys the factories, buys the employees, but has never given the customer list. I can guarantee the value of that company is much lower than if the customer list goes with it because that piece of customer data has value, but it's not treated as an asset in an organization. I worked at one organization where we experimented with running a form of a balance sheet where each piece of data was effectively an asset and where what we were trying to do is depreciate the data to use that as money coming into the team to invest in automation and paying down technical debt. Do you think that's part of the problem is that organizations don't understand the value of the data and therefore that's transposed onto not understanding the value of the data team? Or when they look at the data team, it's, as you said, it's all around effort, how busy are they or the work they're doing rather than the valuable data they're creating.

Yeah, I think it's that. I think organizations, I think they know that data is valuable operationally of, hey, I need to know what's going on in my business. Like I think biggest thing they know is that They need to have visibility into how much product did we sell last week? Are we delivering to our customers or clients our products or services on time? So I think it's that part. They realize that they need that because as an organization becomes much larger, you need that because without it, you don't have any visibility to it. So I think it's visibility, but I think the, the challenge is it's the next level of the 4 steps of analytics realm. I think descriptive, diagnostic, predictive, and prescriptive. So our value then becomes how do we not only just tell them the story, we tell them why is this going on? How How can we do things better? You have these corporate metrics. How do we go from, let's say, example, customer satisfaction. How do you go from 90 to 95%? What are the drivers of that? I think that is the gap of seeing the value in data in terms of using data to help improve outcomes. Not just telling you what the weather outside is, but also telling you, okay, how do I make it rain or how do I stop it from raining? I don't think there's as understanding just how data can also be used for that, for also helping to guide the business, not just telling you what's going on.

I'm not sure how it worked back in the Business Objects days for you, but back then, we used to have these roles called business analysts. They're still around, but they're not. And their role was to go out and look at a business process, understand how that business process was being done, typically use data to understand that process to a degree, then recommend some changes, and then we'd benchmark whether those changes were successful or not. And what I'm seeing now is instead of those business analysts or those analysts working in the data team, they seem to be just decentralized. We're creating these forms of silos where the engineers are just working with data and the people doing the analysis are sitting somewhere else in the organization. And that causes a disconnect because the people that are serving the data aren't analyzing it to understand where the problems are and how to solve them. Whereas for me, if we brought those two skills or roles back together where we can analyze the data at the same time that we're actually engineering it, I think we're going to go back with more recommendations on how to change the organization in a good way rather than just serving up data and saying, you work it out. So, how does it work in your organization? Are your teams siloed to a degree, and does that cause you a problem, or do they tend to that problem definition and a potential solution for a business problem, is that delivered by the same team that's doing the data engineering?

Yeah, so I would say right now we have a centralized data team from a data engineering, business intelligence perspective where all that is being built within a centralized team that sits within IT. We do have a group of business analysts within our data team that does work closely with their business counterparts to say, okay, What are you guys working on? What data can you use for different processes? We do have a couple— well, some business units have a couple analytics teams because they're able to do that. Some business functions don't. So that means that the data team serves as their kind of analytics team because they don't have individual analysts that can do that. But even when you have business analysts that sit within the business, to your point, you still need to have that connection. So I think that's where the, the business analysts help to bridge that communication gap because you don't want data engineers just in a silo, just building tables and pipelines and like that, you do want some type of connection to what they're building, why. So I would say it's definitely evolving because I think there's always opportunities to learn more about the business and not just understanding what they're asking for, but why do they want it? Like how they plan to use it, or we've built these things the past couple years, so how do we go back and figure out, did you do what you said you're gonna do? Did you use the information? Are you using data? So I would say it's a hybrid, which I think is usually best. All the data comes out of a core team. But you can't expect that the data team by itself will service every single business request. I, I think we have a hybrid model, but definitely there's always rooms for improvement to continue to work with some of our business partners. Because to your point about process, I think the challenge in 2025 is that you have so many different technology partners with SaaS, you have SAP, you have all these ERP systems where a lot of departments don't even know their business process. They just know that I get an order, I need to issue a PO. All that's done behind the scenes, like all that's done with an SAP. Or Oracle ERP or ACM, like all the different processes are hidden in these applications. So all they see is that there was an input and output. They don't really know what happened in between. They just know that the output's not right. So now we need to reconfigure the application. So I would say that's the challenge I think we're having is that the concept of business process is becoming more and more like from IT where IT tells them, hey, like in order to issue payroll, you have to run these different steps to issue a payroll out of your HR system. So the business can tell you in the implementation what happens, but after they've gone a couple years later, they're like, I really don't know what it does. Just this magic where I click a button and issues payroll, but I don't know how they issue payroll. So I think that's where we're also facing that now. We have to bring in our technology partner. We have to bring in as well because they know more about our vendors, right? They know much more about our business and processes than the business does because the business, I run 2 steps and I get an output.

Actually, I think part of it, like you said, is that business users are disconnected from everything. So technology's automated some of it, but also they're no longer given the time to sit back and look at their processes. If you look at a lean manufacturing organization, you know, there's that concept of walk the floor. You'll see a leader in that organization spend between 30 and 50% of their time walking the manufacturing floor because that's how they see the flow. There's machines physically, they can map out nodes and links of the way the work's moving through the factory. They can see where the blockages are. They can see the stuff moving, but when we talk about a digital company, we can't see those zeros and ones flowing through the systems, but the data team can. And what's interesting for me is if you work with a data team, we love to do data lineage. We love to do this idea of nodes and links to see the flow of the data through our system. And why do we do that? Because that map helps us visualize the work's being done, understand what's happening where, understand where we can fix it, where it's broken. So, for me, data teams have some real value by just mapping out the organization's flow of data outside of the warehouse as nodes and links. And then that map has value, the perceived value of that map will come back to the data team. And then they can also then identify where they have data for each of those nodes. So, as you go through the manufacturing process, they can say, we have this data about inputs coming into the store, inventory and stock. The just-in-time delivery schedule. There's a whole lot of things where they hold data that can help the business or their stakeholders. And they can serve that up as a shopping list rather than a smorgasbord, rather than a catalog or a store where you go help yourself. They can say, hey, would you like fries with that? We can see that the just-in-time numbers are killing a downstream node. And that understanding the organization flow with data is something that we're good at. But it's not something we talk about or not something that we use to solve business problems.

Yeah, to your point, data lineage has always been out there and it's, I think one of our biggest challenges because to your point, that's what the business asks for. Okay. If I show a number, let's say a revenue number, the question always is, okay, where'd you get this from? Like, how'd you calculate that? Where'd you get this from? So I think that was the thought behind the data catalog is, oh, I can give you this catalog and the catalog will show you where I got it from and all that stuff. But then we just mucked it up and just threw a bunch of crap in there and the business, I can't use this. This is way too complicated. Is an overly engineered solution to a very simple question. And we have all these data lineage tools, but a lot of those tools are very manual where it's very difficult to say, because a lot of the logic is wrapped in SQL, like it's wrapped in SQL logic, WHERE clauses, AND statements, all these CASE statements, all these different things. So it's very difficult to pierce through that to give very simple answers to those different questions of, hey, I got this from here, here's how you can use it. So I think that's also one of our challenges around value is that we've overtooled and overcomplicated a lot of the work that we do. And it was very difficult for us to give the business simple answers to questions and say, oh, it's your revenue has come from your sales minus discounts. And that's where, that's how we get your net revenue numbers. Like very common business language. We use our, we say if revenue type equals C and the discount code is this, but not this, then you like, no one understands it. That's all application logic. So I think that's also the challenge too, is though, who's responsible, right? Those roles and the team. To translate that and speak that language to show people like, yeah, we can, we can help you out here.

And that complexity is not our fault. We gotta live with it. We've gotta solve it. But yeah, if you think about it, if I've got SAP, heaven forbid, and big complex beast of a product, especially if you're a data engineer trying to go in and understand the tables that you're getting given in the back. But let's say I've got an ERP and it's got a table called customer. The theory should be simplicity. I should be able to go in there and go, Account customer and whatever's in that table is a customer because the table's called customer. And that's our account, really simple. But as you said, somebody's then decided, actually we have these things called prospective customers and we want to manage them and there's no prospect table in there. So let's just slam them in the customer table with a type field of P. Oh, and then we've got inactive customers. They're the ones that they're a customer and they bought something off us, but they haven't bought something off us in the last 12 months. We could implement that in our ERP, but actually that takes a consultant to come in and do it. So let's move that logic somewhere else to the data team and they can implement that. And that's value because actually it's cheaper and faster for us to implement that logic on our side. But now what we're doing is we're implementing the complexity that stakeholders are asking us to, but we somehow wear the cost of that complexity. And so I'm with you, I think we love to engineer. But sometimes we over-engineer something and that bites us. I think the other thing then, and you touched on it, is we're asked for data by a stakeholder because they have something they want to do. There's some value they want to add to the organization and they need data to support that. And somehow we're held accountable for the value of that data. Not the stakeholder who's trying to make that business change. And I'm intrigued by that one because our customer, effectively our stakeholder, is the one that's delivering the value. But often they're not held to account. And part of the reason I think is data requests are free. You create a Jira, you ask for some data or you create a Jira ticket and it just goes into the magic queue and then somebody does the work and you get your answer, but you never pay for that. There's no internal charging. And I'm not saying a pattern of internal charging is a good idea because I actually think it's It's an anti-pattern because as soon as you start doing that, they'll use alternatives. But there is this really weird disconnect, isn't there, where the person responsible for delivering the value is different to the person responsible for creating the data to deliver that value.

Yeah. And I'll say it's a huge challenge, right? Because I always think to answer the question, right? If my CEO came to me and say, hey, what are you guys working on? I tell her and she said, what's the value? I don't know. I'm giving it to someone else for them to figure out. It just, it doesn't come across as a good answer, right? Do you know why you're doing what you're doing? Do you understand it? I want you to push back. So I think that's the challenge we have is that we have to understand and advocate. We can't just blindly trust that someone's doing something like quote unquote, and someone knows, cause I know a lot of times you work with different stakeholders, they give you a request, but it's like more like a theory. It's a, I don't know. So you get sent down this rabbit hole and you spend months working on a project that doesn't get used. It provides no value. And you just shot yourself in the foot, but you're like, well, it's not my fault. It sucks to be in that position, but that's the name of the game, right? If you're working in this field, we've all learned this the hard way. That's the name of the game. You have to also have ownership in the work and the potential value and ask those hard questions upfront. Because if you don't, then like you're starting to see on LinkedIn, a lot of these data teams, a lot of people, engineers, leaders, a lot of people are being laid off these companies because people like, I spent millions of dollars on this data team. I'm seeing no value. So your answer can't be, was because the finance or the HR department gave you a bunch of requests that are invalid. No, that doesn't apply. If you wanna work in this field and you want to, you know, keep a job, you have to really understand and be able to identify just what you're doing and why it's important to organization. Like I said, people's just jobs are on the line because it's just, it's, it's rough out there.

You used the word hybrid a while ago, and I think hybrid models are dangerous. They're by nature, a hybrid model is complete. If you think about an organization that runs a matrix model for its reporting, that's a form of hybrid and it becomes complex to understand about who reports to who and whatever. If we look at finance, if we look at a chief financial officer or CFO, what I will often see is they will give out the money. They go, here's your budget. This is what you said you're going to do. Here's the money to make it happen. But the person requesting the money is responsible for the value. You never see the CFO go, yeah, you're right. My finance team didn't deliver any value with the money we gave to build a new factory. They have a very clear boundary that what they are is a provider of a service, shared service. They provide that budget and they monitor that it was used, but they're not accountable for the value. Whereas often we sit in the middle, we behave like that finance team, but somehow we're expected to deliver the value as well. And I think part of that is because there's always an alternative for data. The alternative is Excel or gut feel. Whereas if you're in the finance team, there is no alternative. Alternative to getting money to do what you need to do as your part of the organization. So, I think that's one of the things we've got to realize is that we are still perceived in most organizations as being optional. It is a nice to have, not mandatory. There is always an alternative that the stakeholder can use that doesn't involve data or data from the data team.

Yeah, and I think it goes to the original question about the organization understanding the data team. I think, Data is still like a relatively new concept. Like finance has been around since humans were like, some type of finance. I think people understand the concept of money and finance group, the role of the CFO. I still think that organizations are still trying to figure out what data teams are, how to get value out of it, because it's just so different organization. Because think about me, the role of the CIO has been around, what, 20 to 30 years. If you think about data, then we're probably 10 to like in the past 20 years. So I think a lot of organizations are still trying to figure out just where the data team fits at, to your point, definitely is optional. It's okay. Let's say the data team goes away. The organization is still going to make products and services, market it, and they're going to sell it to their customers. Like all that's going to happen. So even if the data team's not around, I think they may not have as much visibility as FaaS, but I think that's the challenge is that unless you really embed your data team into the operational nature of it and say, yeah, we actually can't run without the data team, that's more like operational use cases. I think that's really the challenge that we're still proving our worth, so to speak, in many different organizations. We also don't do our are any favorites because all the names around. You have AI now, you had, you have data science, machine learning, you have data governance. We've created this huge web of all these analytics versus data and data products and business intelligence and predictive and data mining. Like, I think we've created this large web where it's very hard for companies to pigeonhole and say this is data, whereas finance is like they have accounting, they have GAAP measures, they have finance. Like, they've figured out their world, and I think we keep changing. Um, and lastly, and last point I'll make is just vendors, right? Vendors are a part of it because we're very much aligned to our vendors. So you talk about data, you're talking about Snowflake, Databricks, dbt, Azure, Azure Lakehouse Architecture, data warehouse. We're very much tied to architecture and vendors and technology, whereas some of these other things, those are just core concepts of like finance, like accounting numbers, like Or even HR, like payroll. Those are not vendor-specific. We really pulled ourselves tied to vendors. So I think is we haven't done ourselves any favors in the industry around how we probably make it a little bit complex. I agree.

And I'm not sure we can fix that complexity right now, but we can hide it. We love, we as data people, we love to argue semantics. What is the semantic layer? What is a data product? What is a data contract? We get intrigued by engineering the words and somehow we think exposing that to our stakeholders is a good idea. Argue amongst yourselves, but give them simplicity. Just give them a definition, even if it's not 100% correct and the team don't 100% agree. Give them simplicity.

At the end, I usually, whenever we get in these discussions, I'm like, at the end, I always say, guys, just remember the business doesn't care. We can all argue about this till the cats come in and we can argue, we can discuss it and talk about definitions and who's wrong. But the end is always, guys, the business doesn't care. Like they don't care about any of this stuff. They're just trying to sell products and services to their customers. That's what they ultimately are doing. That's how their performance gets judged.

And you're right about rate of change. If I look at organizations, they don't change their ERP, their financial system, every 5 years. They certainly don't change their payroll system every couple of years because there's a new shiny payroll system come out. Whereas in data, we love to do that. We're like, oh, Snowflake's too expensive, let's implement Databricks. And we don't sit back and go, yeah, okay, maybe it's cheaper to run as a compute, maybe, I'm not saying it is, maybe, but actually the cost of the team to do that migration, the cost of not delivering any value to the organization while we do that migration, and the complexity we're going to introduce when we run two systems for a while. Replatforming every couple of years because we think it's cool doesn't do us any favors if you're sitting outside the data team and saying, what value have they added to us this this year. Yeah, because rebuilding the kitchen is not seen as value by our stakeholders. They don't care.

I've been guilty of that myself in my career, is trying to argue for the replatform. Oh, our data warehouse is so outdated and we need to do this new lakehouse thing. So I just need 12 to 18 months and $3 to $5 million to replatform it. But at the end of that, I promise you, right at the end of the 18 months, I promise you'll get value. I think that's where a lot of us have gotten, where we do this 18-month transformation, and most likely by the end of that, your leader's leaving, your leader's gone, they go to a different company and new leader's in, they're gonna prime. So I feel like a lot of these organizations, to your point around, are probably just burnt by just this promise of, oh, once you get to this new technology or re-platform, you're gonna get this new value. It's gonna be faster. Okay. But what does faster mean? Oh, you get faster compute, faster this, faster that. But does that mean we get faster, like analytics? Do we get faster insights? What does that really deliver? I think. We haven't really answered that or solved for that. We just keep selling people on, we need this new thing called Hadoop. Oh, that's great. We need these, we need this new lake house. We need Snowflake. We need dbt. You know, this new thing called LLMs are out there. So we just keep promising, I'm gonna get better, I'm gonna do better, I'm gonna do better. But we just haven't done, I'm gonna say we haven't done anything, but we haven't justified all the millions and, and the consulting, right? It's just the millions of consulting firms and technology spend. It's just, that's the challenge with value is that We selling people hardware and architecture, not results and outcomes.

And the other thing is we often look at the time to serve. How long does it take us to add that value from the time we pick up the task and start working on it? But actually, from a stakeholder's point of view, the clock starts ticking at the time they asked us to do something. So they ask us to do something, and if it goes into a queue and it's backlogged and it's waiting for some form of prioritization, that timeframe, that prioritization process is time ticking in their minds because they've asked for it. Whereas data teams, we often start the clock ticking from when we pick the work up. We're like, oh yeah, it was great, picked the work up like crack, I smashed it. A couple of days and it was in their hands. Yet it's been sitting in that queue for 3 months.

They don't see it as value, right? I think they, to your point right there, because I just had this discussion a couple of weeks ago where you go to your customer and say, hey, look, we finally delivered this thing. They're like, that's great, but I asked for this like 6 months ago. So They don't see it. It's like you're getting like back to out of debt. Like you put yourself in this debt of, we talked about this a year ago and it took us a year. Oh, we finally got that done. They're like, okay, I, that's great, but it would've been nice to get this sooner. So it was like, how do you actually get ahead of it where they're actually excited about what you're delivering versus, all right, they're so slow. They're finally getting to this thing. We've been talking about this thing for years and they're finally getting to it. We see it as, hey, we got this done. Let's all cheer and celebrate. But no, they don't. To your point, they don't see it that, they don't see it that way at all.

And I think there's some simple patterns. Start measuring your cycle time from the day that request was made. From the day a stakeholder asks you for something to when you put it in their hands, how long is that? And try and figure out where in your process you need to optimize to reduce that timeframe. Potentially bring in theory constraints. Getting 500 requests into our queue from stakeholders where we know we can't actually deliver them is just dumb. So, bring in a constraints process where they don't even enter the queue because at least the stakeholder knows you're not working on it. Just make it very clear it's not happening. You're not picking it up until you can actually work on it. That's going to cause you a whole lot of other problems, but it's going to increase the perceived value of the data team because it's, they're busy and I can't get in there and get the stuff I need. Okay, how are we going to fix that? Because now you're telling me there's value in the work they've done because you're bitching and moaning about it. You're complaining it's not been done. I think the other thing that I often see is this idea of explaining the process the data team follows to the stakeholders so they understand. So we can do some very simple playbooks. We can take that nodes and links pattern from, from the data lineage and we can use it to map out how the team works at a very high level, not lots of swim lanes and complexity, because I don't care, but just simple steps. You ask us for this, the first thing we're going to do is look to see whether we've got the data or not. If we don't have the data, if we haven't collected it, that's a natural 2 weeks for us to do that piece of work, to bring that data in, to get that stock into the warehouse. We can explain some really simple concepts to them that they now understand how we work. And hell, they'll probably come back with some suggestions on how we can improve it, but at least we're sharing that language of the way we work, and that's valuable in our perceived value, I think.

Yeah, I think roadmaps are— in the past year, I think roadmap, along with the value thing, roadmaps have been very big to me right now, trying to figure out what's the best way to create and visualize roadmaps to show our business partners. I think To your point, like they just, we just have to be honest with about, hey, you're not gonna get this for a year. But I think a lot of us, we don't say that. We say, oh, we'll let you know when we can get to it. But then, okay. But then they say, if you're not working on this, what else are you working on? It's always the question. Okay. What are you guys working on? If you can't work on this, show me what you guys are doing. Help me understand why I can't get my thing. So that's where I've been looking at. And there's some pretty cool books I discovered around like how to build a roadmap and what should be there and what is not a roadmap and kind of what's the release plan. So. So that's something I've been playing around with too, is like how to build out that roadmap and how far into the future can we go, right? I talk with, with you about something today. It may not be 12 months until you can get that thing. So how do I visualize that and say, okay, here's what I'm working on over the next 12 months and here's why you should care and here's how you can get value out of it. I think that's also something that I think we're not comfortable or familiar with, like how to actually like market what we're doing and showing the value of, hey, over the next 12 months, Here's how we're gonna dig into this one metric and KPI to give you more visibility and show you how to use it. To your point about showing our process, that should be part of it where after the discussion, we're gonna figure out how to fit that into our roadmap and we'll come back to you and show you where this fits at. And then you can say, okay, I understand why you guys can't work on that because you're doing this other stuff that's much more important than this request. Or how do you shuffle and say, actually, this is gonna impact revenue, so we're gonna push out this and introduce them or bring them into the discussion. Don't just make it for them. But I would say absolutely, I think that transparency and visibility could go a long way.

I think when we talk roadmaps, a lot of people think project plan or timeline. They think they, they need to put timeframes on it. But the challenge is we know we have a whole world of uncertainty. So if I say we're going to go and build lifetime value for a customer, I haven't done the work to understand where the data sources are to bring in customer spend, customer churn, predictive models. So I don't know how long it's going to take. I can have a gut feel. I can t-shirt size it, maybe. But as soon as we put a timeframe on there, we put anything that looks like a calendar with dates, and we put a box that is next to a date, we're making a promise and a promise that we can't keep because we have a high level of uncertainty about the work to be done. But we have even more uncertainty around prioritization because again, if I say something's going to happen next year, sure as shit, something in the organization is going to change. There'll be a new AI tool coming out of China that completely changes the dynamics of the share market, that reprioritization is going to happen. And so what I tend to recommend people do is we look at the way product managers for software do road mapping. And what they tend to do is they tend to do time horizons. So they tend to say, we'll have a, a dot on the page and work that's closer to the dot is more likely to be done. And then maybe there's another time horizon and then stuff out there will probably get done at some stage and there's stuff outside that one, like a radius of a sun, it's never going to happen right until it gets closer to. So we're not, we're giving them an idea of time by location to the work we're doing to us, but we're not giving them any promises.

We're going to address lifetime value in the first half of the next fiscal year. I'm not telling you the month. I'm not telling you the week or the date. I'm just saying in the first quarter, we're going to talk about lifetime value. And open up, like, we're gonna at least have the discussion yet, but I can't commit to you anything more than like a discussion of it. To your point, there's under-commitment, there's over-commitment, right? Because sometimes we over-commit and say we're gonna have it done by this month and we just never, we never hit that. Under-commitment, we don't tell you anything. All right, we'll let you know. And then we go into this black box and it's like, where'd you guys— you told us one time, they never told me anything. So I think also we have a habit of doing under-commitment. I think that's not okay. If people ask you and say, when you guys, when can you look at that? You can't just say, I don't know, I don't know about that. I don't know. Well, then what do you know? That also causes frustration when you're just non-committal at all. So yeah, I think it's the happy middle— the happy middle ground of, okay, here's a time horizon where we think we can look at it. But like, to your point, as we get farther out, my level of certainty is going to decrease. As we get closer, I feel better about this, but at least I can give you a 6-month time horizon when we can look at it.

And also context. So. If that map shows the work that's in the queue before that piece of work, before that lifetime value, at least they understand what you're doing. And then they can look at it and go, actually, I don't think you should be doing that before you do lifetime value. And you go, great. Now what we need is the stakeholders that have those two sets of work to agree to swap. Because that's what we're doing is trading value. As we're saying, that one's more valuable next, so let's go do it, but it's between the owners of that value, the stakeholder who's asking for that work. So this idea of maps, of a roadmap, of a way of visualizing the work that potentially becomes done is really important. And the other thing we can do is we can use that in a slightly different way. So what we can do is we can wireframe out what we think we're going to build and then color it in as we build it. You know, you talked before about domains. What we can do is we can create a wireframe with boxes, which is the domains in our organization. And potentially, each of the boxes can be a different size based on the importance of that domain or the complexity of that domain. And then, as we build something and deliver that value, we can color it in or color a part of it in. And what we're doing is we're visually showing this map of the value we've added over the last couple of years because people forget. And back to your point, If I look at the retention of roles in an organization, CFOs, and I just, I don't know, I always come back to that one, but I do. Chief Financial Officer typically stays around for a while. You wouldn't typically see a CFO come in and out every year or two, or you'd really worry about the organization. Whereas the Chief Data Officer, wow, like you said, we're the CIOs of the old days where we have a 3-year window and then we're out, either we're going to find a better job or We've had to go find another job. And so that constant swapping of that leadership, I think, helps, hurts our ability to tell a story about the value we've added. So again, just coloring in that map, then the next person can pick it up and say, hey, here's what you've done, great, and reiterate the value that's already been added by adding to it as they turn up. What do you think about that?

Yeah, I definitely think that's part of the storytelling because there's also evolution of our work. Because in order to really fully understand metrics, you need to understand not just the number, but there's different level of granularity. So for example, the shirt I have on, right? So the style is I'm wearing, I have a Sherpa-lined shirt. That's one level. The next level is the color, right? So not only is it a Sherpa-lined coat, it's the color blue. That's another level of granularity. Then it's the size, right? So this is a size large. So I think coloring in the lines also shows you over time how we're evolving in our understanding of data. Because there may be 3 projects over the course of a year just to get you to the level of granularity you need. And you also need the context of, okay, which regions do I sell it in? Which domains? Which areas? Which customers? So there's an evolution of a year into understanding a very simple metric or KPI or business process. So you also need to show over time how you're evolving the organization into a better understanding of that. Because all the metrics have context and you can't really just deliver all in one setting. You have to build that over time. But also it shows you, okay, if I've been working on stuff for a year, what's the connectedness? Is everything random where this quarter I do this stuff with this group, next quarter I do a different group, but there's no connectedness stuff. Then it's a question of, I don't understand, there's no rhyme or reason to what you're working on. So I think really also trying to show, yeah, there's a bigger plan. We're trying to bring all these domains together to tell a complete story. Here's the story. That's something I'm also working on too, is showing the evolution and kind of the full story of once we build all these things together, now you're gonna have a car, right? So like I got a steering wheel, I got a radio thing, but once I pull all these pieces together, you have a car that now we can drive down the street and people will be interested in. So I think that's the other part of, to your point around like really trying to bring everything together to show the sizes, the complexity, the domains, but still there should be a comprehensive complete story. Not just a bunch of random skits that have no rhyme or reason.

Then what we've got is a complexity problem again, because we don't want to publish a data dictionary with every attribute coloring in, hey, we've done 3 of the attributes against product, because they probably don't care. So that storytelling, how do we take that complexity of those domains, those concepts, those details about concepts, and how do we tell a story that we're incrementally adding them in an automated way, which gives us value later? Which we still have to prove. We have to prove that having done that data work, we are faster to deliver the next piece. Pet hate, 5,000 DBT models, using the air quotes, doesn't make us faster if we don't pick up some of those core concepts and reuse them later. So that's a real trick, is taking that complexity and telling the story back to our stakeholders on the value we've added. But the other thing is we can think about ways of articulating the value quicker. That example you used. If we've basically, the first piece of work we've done is understand all the product SKUs, just a list of product SKUs. That is valuable in a way. Say that we now have a single list of all product SKUs, especially if they're held in different systems, has value. So let's talk about that. Let's not wait for a year until we've finished the actual information product. Let's talk about the value that list of SKUs has. And then when we start adding the attributes, when we start adding size and we start adding color. And we start adding all that other attributes about that product. Let's talk about those as well. They probably aren't as valuable as the final information product, but they have some value. And again, we can, that, that constant communication of the things we are doing and the potential value of each thing and giving that back to our stakeholders rather than waiting to the end to that final bowl of cereal.

Yeah, you need trust. That's a huge trust exercise. Like the house I'm in right now, so we had someone build this house about a year and a half ago. It was fall of 2023. During the process of building a house, they would come in and show you like, okay, when you just had the framing done, okay, here's where the things are going to go. Here's the framing of it. We didn't have to wait until it was all built because by then, if something's wrong, you really— that's a huge amount of trust you have to put into a builder to say, hey, from the plans into the house, I'm going to trust that you're going to build everything where I want the toilet here, all that. But they show you along the way to say, we're getting you towards the end result of having a house for you to move in. But let me show you how we put it here. This is where this goes. The windows go here. But yeah, you definitely want to show incrementally over time because you want to make sure that people feel comfortable. They're going to pay you all the different installments and you have a good experience at the end. Because that's— we do a lot of tours, say in a year from now we'll give you the thing. It's how do I know that it's going to be what I still want? How do I know that it's going to be what I asked for originally? And if I get to that, the pay for, what if I say I don't want to pay for that because that's not what I asked for? So Definitely like how do you provide incremental value along the way to build trust and make sure that the user has a good experience working with you.

And that agility, that ability to adapt to change is hard because it's a great analogy you've got about building a house because what they didn't do was build you a toilet with walls and a roof, an outhouse and go, there you go. Yeah, we've delivered an incremental piece of value. There's your toilet. Move in. Because you can't. So they have architected some framing. They have built the framework first and it took them a bunch of months, no doubt. And then they start adding some other stuff, but it's that constant feedback, that ability to be able to affect change. So if, for example, halfway through that, you find out you're about to have another child and you hadn't planned for an extra bedroom, potentially you can change the layout of the house to add another bedroom or reallocate a space to be that because that change has happened outside your control to a degree. And that's what happens with our stakeholders as well, is that we get this request and then we spend a year without any feedback. And we miss the fact that actually the organization has changed. Something's happened in that year that's outside their control. But if we're constantly interacting with them and showing what we're building and getting feedback, then the ability to make that change is slightly easier. You know, if we'd already framed the house, put the roof on, and we're about to put the final fixtures into the kitchen. Our ability to change by adding another room in the middle of the house is very low. It's a high cost change.

Especially when you have questors that are not fully confident what they're asking for, which happens a lot where you spend a year, you get to your testing phase, and you give them some data and say, oh, this is not what I wanted, or, oh, our business requirements completely changed. And you're like, this would have been nice to know a year ago. Fuck, I built my house and all of a sudden the laundry room's downstairs. So you have all the bedrooms are upstairs. Or actually, I didn't realize that the beds are upstairs. So I need you to put a laundry room upstairs. But now it's too late, or it's gonna take us another year cuz now we have to tear down everything, rebuild everything. So also I, I think if you're in the new relationship with a business stakeholder you never worked with before, or they're working with data, a lot of times we expect that our stakeholders know how to work with data and they know the data they're asking for. A lot of times they don't, they're just like, I need to see this information. It's better to give them something quickly to help refine the requirements and understand, make sure they know. Cause you also may cancel and say, you know what? They may see it and say, actually, this is not gonna benefit me at all. So let's just cancel this so I don't waste both of our time. But if you waited too long into the future, you would've wasted your time when they come into you and say, well, actually we don't need that anymore. Or, oh, this is way more complex. Or I just changed jobs, or we have a new person in here. So I think definitely doing it incrementally along the way, showing that value really helps everyone involved in the situation.

Again, it's about fluency. We talk about data literacy, but actually it is just language. Which is fluency. Going back to your housing analogy, because I love watching those retrofit reality TV house shows. There was one on the other day, they talked about a pot filler. And I was like, what the hell is a pot filler? And now if I had said to you, oh, a pot filler is an articulated pipe that elongates and extends itself to fill your pot, that's not going to tell you what a pot filler is. But if I showed you what a pot filler is, I showed you on the wall over the oven or the stovetop and the fact that it can pour water into the pot without you having to take the pot to a sink. If I show you that, you're going to become fluent to a degree in the language of a pot filler. You're going to see it and know what it is. And so that's part of our challenge as data people. How can we show them something in our domain that makes them more fluent? Or how can we use words that aren't confusing for them? How do we not talk about slowly dimensions type 2? How do we not talk about the bitemporal nature of data and business effectivity dates?

Right, how do we not talk to them about the star schema? We're going to build out this star schema. We're going to put this as your fact. This is going to be your dimension table, and here's your factless fact. They're like, I— like, you just— it helps to commonize the language. Say, okay, here's a spreadsheet information we pulled. Here's the fields you were asking about. Your process creates this information. Did you know that? Well, if you didn't, here's what it looks like when you click that workflow button that clicks next, next, next, and submit. Like, this is what the, it looks like from a data perspective.

We can do light work early. We can mock up a dashboard with dummy data or bad data and put it in front of them and say, if this is what I delivered to you, is this what you wanted? Have a play with it. Tell, tell me what you want to change now. We've gotta be a little bit careful because when we say it's dummy data or we haven't done anything to the data and it's all bad quality, we know that we will fix that. Some people will dive in the data and go, oh, that's wrong. So we have to be very clear about where we are in that process. But by showing them something early, we increase their fluency as much as anything else. And we get feedback and we get the ability to change before we've gone and build all the pipelines to feed that dashboard or whatever the way we deliver that product.

What we're talking through is it demonstrates how challenging it is. You're talking about value. It's a lot of these in-depth conversations that have to happen. I think a lot of times teams don't have the staff or the resources to have these conversations. You may have a manager. Bunch of developers. So who on your team is responsible for some of that? Who's gonna show the stakeholders the data? Who's gonna walk 'em through the data export? Who's gonna explain it to them? Who's gonna verify the requirements? That's where I think you really need kind of those roles that can have these in-depth conversations because it's never simple. It's never simple to say what's business value or are you providing values? There's a whole bunch of conversations and you really have to lead down these back and forth question and answer sessions over many iterations to get to the crux and say, yes, this was valuable for these reasons. but it's not as simple as, I see them using or not using it, so I didn't provide them any value. It's like, no, like it's a lot more discussions that has to happen and someone has to do this. And it can't necessarily just be the leader. It can't be the engineers or the testers. You've got to figure out the operating model of how your team can do this to really dig in and answer that question.

One of the key takeaways for me is this idea of a storyteller. We're starting to see data storytelling becoming a thing where instead of just giving them back a list of data. We're starting to tell them a story about that data in business context. So, if I see this and I see this, then I think this is happening, but this looks like this is happening, therefore maybe we should do this. That storytelling kind of pattern is becoming more and more prevalent as a way of adding value to the data and solving problems, not just giving back an answer to a data request. And I hadn't thought about turning that into how does the data team tell the story to the stakeholders of the value they've added? Not the story about the data, but the story about the work they're doing. And so actually, that would be a really good question. If you sat back and thought about your data team in an organization, who is telling the story to the stakeholders about the value your team's delivered? Is it the data leader? Is it the team itself? Is it nobody? Because I'm going to assume a lot of the time it's nobody. And then What are simple things you can do to tell that story about the value you're adding or added and just keep going?

That's where you're seeing a lot of the data product managers, right? You're hearing much more about that role coming out because you realize that that's the, I don't know, it's the data storyteller plus a storyteller plus your product manager who can tell you about it, but they can also figure out if anybody's using it, requirements. I think that's where you're starting to see these roles get created because you realize there's just a gap between these pure engineering coding teams and more like a business analyst team. Like it's, you need someone who can help translate that. So you're starting to see these roles emerge because people realize they want to keep their job, but they realize I'm a leader. I'm also, I have to manage like a, I have to do HR, I gotta manage the team day to day. I have to do coding reviews. I have to work about data strategies. So even I can't full-time do the stuff that we're talking about when it comes to demonstrating value. I still need another person. I think that's why you see these conversations necessitate something else, a new person to be created, figure out what's the right title and expectations for that person.

The business analyst used to do that a lot in, in back in the Business Objects days, we used to see the BA role do a lot of that storytelling.

Yeah.

They were the product manager. So I think bringing those skills and potentially that role back into the data team's great, cause I think it's got divorced, it's got siloed out. The other thing though is I think it's the whole team's job because what happens if we're not consistently telling the story of the value we've added as a team? When there is a downturn in the market, things get done to us and maybe the leaders lost their job at the same time, but maybe not. So I don't think we can rely on the boss, using air quotes, being the only person that tells that story because sometimes impact happens to the rest of us and not to that that leader. So we actually do need to tell some of those stories ourselves. And again, it shouldn't be onerous. It shouldn't be seen as sleazy sales. All it is is constant communication. It's, hey, we went and grabbed a bunch of product SKUs out of SAP. Wow, that was a bit of a challenge because there were all these recursive hierarchies in SAP based on the way you set up the product catalog. And we had to resolve that. Hey, have a quick look at this data in Excel.

Completely different understanding of our role, right? I think, like I mentioned earlier, I realized that sales is a natural part of our jobs in our life, right? If I lose my job, my new job is I have to go sell myself to a new company to show my resume, to interview well, and I, I have to sell myself. So I think we have to realize that sales is a part of— when I met my wife, I had to sell myself to my potential wife for her to want to date me and marry me. I have sell myself to keep her around, and I have to do certain things, right? I have friends I want to keep around, right? So I think sales is a natural part of our world. To your point, I think there is some, some sleaze and unease to it when it feels forced, or you're trying to sell people something that they don't want. But if it's something that people will find value in— I think that's— we have to flip it to, if it's something that people find valuable, I'm actually doing it as a service. I'm trying to help people, not just trying to take their money and run away like a, you know, a snake oil salesman. So I think that's where I've realized too is I used to shy away from, but now I realize just how important it is just for my career and just trying to, you know, continue my own longevity is saying it's just something that we have as part of our role.

And I think that's a really good point is from a product point of view, we talk about retaining a customer and making them happy is a lot cheaper than going out and trying to find a new customer and bringing them in as a new customer. Actually think about it in the same way as a data team. Describing the value we've added to the organization we work in and keeping adding that value and therefore keeping our jobs is much easier and cheaper than losing our job and having to go into a recruitment round where we have to sell the value we could offer rather than the value we have delivered. So think about it that way, just constant communication on the value we added will save us a whole lot of sales in the future when we have to go out and sell ourselves. So that's a great lens to look at it, one that I hadn't thought about. Excellent. All right. Just looking at time, is there anything else you want to cover around data teams, their perception of value, ways they can increase that perception or actually prove the value that they offer into an organization?

No, this has been a great discussion. And to be honest, as a, I'm a practitioner, I work in this stuff day in, day out. So these are the thoughts that I have a lot. So it's good to just talk through this and kind of flesh out these ideas, because these are the conversations I'm having within my team and my leadership, just how do we better display what we're doing, what we're working on, and why the organization should matter and why we should care about it. And some of this translates to things that I write on LinkedIn as well. So no, I think it's a very good kind of discussion. I think these are conversations we probably need to have more versus like now it's all the, the DeepSeek and all these different AI models the past week. So I, I, I think those are great things, but I think we have a lot bigger fish to fry than like LLMs and some of these AI models. This is the real stuff that our companies care about and like really want us to focus on and figure out.

Takeaway for me is often I'll see a team only focus on the data working they're doing, what data they're collecting, what data they're transforming, what data they're surfacing, how they're surfacing that as a product. And then good teams will focus on the way they're working. They'll look at the way they're working, the way they're flowing that data, the things they're doing, and they will iterate that. They'll say, hey, there's a bottleneck in our way of working over here? How can we unblock that? How can we make that more efficient? I think I'm probably going to add one more layer into that now, which is how are data teams experimenting and iterating with describing the value they've added, that feedback loop to their stakeholders? What did they try in the last month to help explain the value they've offered or delivered to the organization? And what are they going to try next month? So bring it in as a conscious task. What are you going to do next month to experiment with articulating the value you add to your organization? Because it has to be conscious. You can't just expect it to happen because it won't. So you need to consciously go and do that work. So treat it as just another data task. What are you or the team going to do?

Yeah, feedback loop. That's also something I'm working with my team on is doing retros to say, okay, 3 months ago in last quarter, we worked on this thing. And no one used it, or everyone used it, so why did they or didn't they then not use it? And that should be an input into the future work to say, okay, last time they asked us for this, no one used it, and we don't repeat that. So either we need to, to your point, do things in much more smaller iterations next time around to make sure we understand requirements, or we really need a strong business case because we were burned last time, so we don't need to. So I think the value also helps us with the road mapping and fleshing out our priorities because history can easily repeat itself if we don't change anything. So to expect something different in the future is foolish unless we've changed something and we've learned from the past that predictive models, it's all about training, training on data in the past to predict the future. So that's the other good part about value is just the feedback loop that it provides into future requests as well to help flesh that out.

Yeah, I think you're right. It's, let's use our, our own tools on ourselves. And don't expect by doing the same thing next month, something will change because it won't. Yeah. Let's, let's use our engineering skills to engineer the value conversations that we're having with our organization. That's a good takeaway.

Excellent.

All right. So if people want to get ahold of you, what's the best way of finding you and finding the excellent stuff that you're writing?

I would say LinkedIn. So I would say find me on LinkedIn. I'm usually writing a couple of articles, a couple of posts a week that I put on LinkedIn. Also still kicking around a new newsletter. So if you look at my LinkedIn profile, you'll see a link to that. So if you find me there, I talk about a lot of this stuff all the time. So yeah, that's how you can, outside of my normal day-to-day stuff, that's also how I'm trying to contribute to the community.

Excellent. And as I always say, sharing is caring. So thank you for caring. I know how hard it is to write good quality content, think about it, write it up in your spare time while you're helping an organization use data valuably. And obviously in the last 12 months or previous to that, actually getting a house built at the same time. It's a bit of a challenge to juggle all that and actually put out good quality content. So thank you for doing that. And I hope everybody has a simply magical day. And that, data magicians, was another Agile Data Podcast episode. If you want to learn new patterns that you can apply to craft your own Agile Data way of working, head over to agiledata.io.