Increasing the perceived value of your data team with Aaron Wilkerson

Join Shane Gibson as he chats with Aaron Wilkerson on ways data teams can increase the perception of the value they add to their organisation.

Read along you will

Shane: Welcome to the Agile Data Podcast. I’m Shane Gibson. 

Aaron: I’m Aaron Wilkerson. 

Shane: 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? 

Aaron: Sure. So I’m Aaron Wilkerson. I’m the director of Data Strategy and products at Carhartt over in the, the US based out of Michigan, just outside the Detroit metropolitan area. So I’ve been working in data just over 17 years.

Um, 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 outta school and got my degrees working in data whole time, which doesn’t happen a lot. Know a lot of people fall into data from different areas, but. I happened to have a job outta school with data, and I learned about it and just kept going and just built my career, worked in 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 individual contributor, I was very limited and what my opportunities were and the conversations I could be in.

So then I say, I wanna 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, a team lead. I’ve been a manager, senior manager now in a director role, so have done many different parts of, 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 come fun career I would say.

Now I’m really looking into. Now along with the day job also going, what you call it, thought leadership. So I’m very heavily on LinkedIn and 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 a 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.

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, because I realize that it’s a pretty small world. So like we’re talking, Shane, you’re on 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, um, on social media. 

Shane: 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 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 ’cause New Zealand’s got 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, uh, until I saw, uh, a whole lot of comments around clothing and who’s wearing what. It’s amazing how disconnected you can be. And you know, back in the business Object days we’re 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 six week delay before we actually got access to new compute. Whereas now with cloud, we click a button and increase the size of our, our database or create a new service in, in a heartbeat. So given everything we do seems to be able to be done faster. Yeah. 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, a large perception in organizations that data teams aren’t helping the organization deliver value?

Aaron: Yeah, I would say the perception and narrative is there. I would say that they do recognize the efforts of the team, but I, I, I think it’s always, we should be able to do more. It should go faster. Why is this taken so long? And, and I think the reason I, 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 around for a long time and Carhart’s been around for I think 130 something. Um, so you have a lot of these like legacy businesses. They fell into data. They didn’t really know what they want data to do. So they started with, usually it’s like a database, right?

You have a bunch of software developers, you give ’em a database and they started 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 of operational, right? Hey, we need to move data from one place to the next one, and we need our own application database. They just threw it all on 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 started to build out reporting, for example, like you mentioned, we mentioned business objects, Cognos, SSRS, 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.

Because know some of ’em, 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 higher 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 the, 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, or what is your team being asked to do?

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, 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 to start with just what is the expectations or are there any expectations, and are you meeting those or are you expected as leaders to bring that to the table and say, this is what we can do.

Shane: I, I think that point about show us is, 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, 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. Yeah. 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, 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 spend a bit of their time. For understanding the organization’s strategy. Like where’s it going? What is its goals? Yeah. 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, 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, to do good shit. Like actually you help try and help the business rather than just wait for a ticket. But also that 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? 

Aaron: 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, 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 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 day leaders are just like former programmers themselves.

So they’re the best programmer and they were promoted to be a manager and then they’re like, I, 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 our detriment. So if you don’t naturally get that or that doesn’t come to you naturally. 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, three 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 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, I don’t think it’s a natural thing be, but that’s because of our background. Like a lot of us, we went to school for math, so it’s okay.

You have less side of the equation, right side of the equation. You have to be equals We have a very logical thing when you work in like sales and marketing, there is no right answer. The only right answer is did someone buy the product? Does someone purchase it? Did you make a sale? So how to 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 what we call 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.

Shane: I think also as technologists, as engineers, as data people, we probably have a a negative view of salespeople. We’re used to the vendors coming in trying to sell us the magic beams 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, you know, 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, I ideate how you could solve it with data. Discover which options 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 gotta go back to, to product management and pick up the patterns of understanding the problem. Getting into the early, 

Aaron: you 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 on know popcorn, whatever, it’s not enough to put all that stuff on the shelves. The expectation is that someone’s going to buy that. Someone’s gonna 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 say on the shelf.

You don’t see products out there. That just sit there for years and no one ever buys it. The, the store will stop letting you get that shelf and the company go outta business. And 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, so we have to go end to end in what we do. 

Shane: Our, 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 gonna come shopping in the catalog. Whereas actually data catalogs are only designed for data.

People. You, 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. Too complicated 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 five serials? Um, and then. We never really kill any of our products. We push out these data sets. Yeah, 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.

But I just want to go back to one of the, the core fundamentals for me, which is, you said you, you worked for a company that’s been around for a hundred plus years. And so I’m assuming in the early days there might have been a paper ledger, maybe with some information or it was just run by a line of sight.

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 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 one organization where we experimented with running a, 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, 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?

Aaron: 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 the 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 that the challenge is, is the next level of the four steps of analytics around, 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 can we do things better? You have these corporate metrics. How do we go from. Let’s 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 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 for raining? I don’t think there’s as understanding of just how data can also be used for that, for also helping to guide the business, not just telling you what’s going on. 

Shane: I’m not sure how, how it worked back in the business object 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.

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, I think we’re gonna 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 team siloed to a degree? Does that cause you a problem or do, 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? 

Aaron: Yes. 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, 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, uh, business counterparts to say, okay, what are you guys working on?

What data can you use for different processes? We do have a couple, 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 kinda analytics team because they don’t have individual analysts that can do that.

But even when you have business analyst 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 is 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 do they plan to use it? Or if we built these things the past couple years, so how do we go back and figure out, did you, 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 the ERP systems, where a lot of departments don’t really 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 a CM, 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.

It’s 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 ’em, 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. It’s just this magic where I click a button and issues payroll, but I don’t know how the issues 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. Business. I run two steps and I get an output. 

Shane: Actually, I think part of it, like you said, is that business users are disconnected from everything.

So technology has 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, uh, a leader in that organization spend between 30 and 50% of their time walking the manufacturing floor, right?

’cause that’s how they see the flow. These 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.

But the data team came. 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, 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 so they can serve that up as a shopping list rather than, uh, 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 note and that that understanding the organization flow with data is something that we are good at. Um, but it’s not something we talk about or not something that we use to solve business problems.

Aaron: Yeah. To your point, data lineage is, is 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, ’cause a lot of the logic is wrapped in sql, like it’s wrapped in SQL Logic, word 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, like 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 over tooled and overcomplicated a a lot of the work that we do. And it was very difficult for us to give the business simple answers to question and say, oh, it’s your revenue is come from your sales minus discounts. And that’s where how, 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’re 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 tweak that language to show people like, yeah, we can, we can help you out here.

Shane: And that complexity is not our fault. We’ve gotta live with it, we’ve gotta solve it. But 

Aaron: yeah, 

Shane: if you think about it, if I’ve got SAP, heaven forbid and big complex beast of a 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. ’cause the CUS 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 wanna 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. Um, 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 the stakeholders are asking us to us, 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 are held accountable for the value of that data, not the stakeholder who’s trying to make that business change.

And, 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 J, you ask for some data, or you create a Jira ticket and it just goes into the 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 a anti-patent 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.

Aaron: Yeah, and I’ll say it’s a huge challenge, right? Because. I always think the answer, the question, right? If my CEO came to me and said, 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 off cross 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 advocate. We can’t just blindly trust that someone’s doing something like quote unquote, and someone know. Because 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 with a 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 of these companies because people are like, I spent millions of dollars on this data team.

I’m seeing no value. So your answer can be what’s, because the finance or the HR department gave you a bunch of requests that are invalid. No, that just doesn’t apply. If you wanna work in this field and you want to no, 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. 

Shane: You, 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, of hybrid, and it becomes complex to understand about who reports to who and whatever.

If we look at finance, if we look at the Chief financial officer, A CFO, what I will often see is they will give out the money. They go Here, here’s your budget. This is what you said you’re gonna do. Here’s the money to make it happen. But the person requesting the money is responsible for the value. You, 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 as a provider of a service, shared service, they provide that budget, uh, and they monitor that it was used, but they’re not accountable for the value. I. 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 field. Whereas if you’re in the finance team, there is no alternative to getting money to do what you need to do as you are part of the organization. So I think that’s one of the things we’ve gotta realize is that we are still perceived and most organizations as being optional.

It, it is a nice to have. Yeah. Not mandatory. There is always an alternative that the stakeholder can use that doesn’t involve data or data from the data team. 

Aaron: Yeah, and, and I think it goes to the original question about the organization, understand the data team, because I think data is still like a relatively new concept.

Like finance has been around since he was like October 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, it’s just so different organization.

’cause 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, 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 gonna happen. So even if the data team’s not around, I think they may not have as much visibility as fast. But I think that’s the challenge is that unless you really embed your data team into the operational nature of it, and so yeah, we actually can’t run without the data team.

That’s more like operation use cases. I, 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 any favor ’cause all the names around. You have ai, now you have, you have data science machine learning, you have data governance.

We’ve created this huge web of all, 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 finances, like they have accounting, they have gap measures, they have finance, like they’ve figured out their world and I think we keep.

Changing. Um, and lastly, and last one 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 in talking about Snowflake, Databricks, DBT, Azure, a, a 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 vendors specific. We really pulled ourselves the type to vendors. So I think is, we haven’t done ourselves any favors in the industry around how we probably can make it a little bit 

Shane: 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, we get intrigued by engineering the, the words and somehow we think exposing that to our stakeholders is a good idea.

It’s argue amongst yourselves, but give them simplicity. Just give them a definition. Even if it’s not a hundred percent correct and the team don’t a hundred percent agree. Give them simplicity 

Aaron: at the end. I usually, whenever we get in discussions, I’m like, end. I always say, just remember the business doesn’t care.

We.

Argue, we could discuss it and talk about definitions and who’s wrong, but at the end it’s 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.

Shane: And you’re right about rate of change. If I look at organizations, they don’t change their ERP, their financial system every five 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 some implement Databricks and, 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, the complexity we’re gonna introduce when we run two systems for a while, replatforming every couple years, ’cause we think it’s cool, doesn’t do us any favors.

If you are sitting outside the data team and saying, what value have they added to us this, this year? You know, because rebuilding the kitchen is not seen as value by our stakeholders. They, oh yeah. Like you said, they don’t, that’s, 

Aaron: 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 three 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. But I think that’s where a lot of us have gotten, where we do this 18 month transformation. Most likely by the end of that, your leader’s leaving.

Your leader’s gone. They go to a different company and new leaders and they’re gonna promise. 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 replatform, 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, we get faster insights. What does, 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 this. We need New Lake House. We need Snowflake. We need DBT. Or 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 don’t say we haven’t done anything, but what we haven’t justified all the millions and and consulting, right?

It’s just the millions of consulting firms and technology spend. It’s just, that’s the challenge to the value is that. We sell in people hardware and architecture, not results and outcomes. 

Shane: 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 ask 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. Oh yeah. It was great. Picked the work up like cra, I smashed it a couple of days and it was in their hands. Yet it’s been sitting in that queue for three months. 

Aaron: They don’t see it as value. Right. I think they, to your point right there, because I just had this discussion a couple weeks ago where you go to your cub and say, Hey look, we finally delivered this thing.

They’re like, that’s great, but I asked for this like six months ago. So they don’t see you’re getting like back to outta 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 nice to get this sooner.

So it’s like, how do you actually get ahead of it where they’re actually excited about what you’re delivering versus alright, they’re so slow, they’re finally getting to this and 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. They don’t see it that way at all. 

Shane: And I think there’s some simple patterns. Start measuring your cycle time from the day that request was made. From the day A, 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 e 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. ’cause at least the stakeholder knows you are 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 gonna cause you a whole lot of other problems. But it’s gonna 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 gonna fix that? Because now you’re telling me there’s value in the work they’ve done. ’cause you’re pitching and moaning about it.

You are 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 ’cause I don’t care, but just simple steps. You ask us for this, the first thing we’re gonna 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 two 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 are sharing that language of the way we work and that’s valuable in, in our perceived value.

I think. 

Aaron: 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 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? That’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 this. Some pretty cool books I discover 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 that’s something I’ve been playing around with is like how to build out that roadmap and how into can.

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’re gonna get value out of it. I think that’s also something that I think we’re not comfortable 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 you can say, okay, I understand why you guys can work with that ’cause 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. Introduce them or bring them into the discussion. Don’t just make it for them.

But I say absolutely. I think that transparency and visibility could go a long way. 

Shane: 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 lot of uncertainty. So if I say we are gonna 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, and predictive models.

Yeah. So I don’t know how long it’s gonna 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 are 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. ’cause again, if I say something’s gonna happen next year, sure as shit, something in the organization’s gonna change. There’ll be a new AI tool coming outta China that. Completely changes the dynamics of the share market that Reprioritization is gonna 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. 

Aaron: So they 

Shane: tend to say, we’ll have a a dot on the page and work that’s closer to the.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 the sun. It’s never gonna happen Right. Until it gets closer too. So we’re not, we’re giving them a, an idea of time by location to the work we’re doing to us, but we’re not giving them any promises. 

Aaron: We’re gonna 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 of the date. I’m just saying in the first quarter we’re gonna 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 has over commit it, right?

Because sometimes we overcom commit and say we’re gonna have it done by this month. And we just never, we never hit that under commit. We don’t tell you anything. All right, we’ll let you know. And we go into this black box and it’s like, where’d you guys tell 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 what, then what do you know? That also causes frustration when you’re just, uh, noncommittal at all. So yeah, I think it’s the happy media, the happy middle ground of, okay, here’s a time horizon, what we think.

We can look at it, but. 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 six month time horizon when we can look at it 

Shane: 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 are.

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, 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 become 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 wire frame out what we think we’re gonna 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 wire frame 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 are visually showing this map of the value we’ve added over the last couple years. ’cause people forget. And back to your point, if I look at the retention of roles in an organization. CFOs and I, I just, I dunno, 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-A-C-F-O 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, with the CIOs of the old days where we have a three year window and then we’re out, either we’re gonna 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. Yeah. 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? 

Aaron: Yeah, I I, I definitely think that’s part of the storytelling because there’s also an evolution of our work because in order to really fully understand metrics, you need to understand. Not just the number, but there’s a different level of granularity. So for example, the shirt I have on, right?

So the style is I’m wearing, I have a Sheerline shirt. That’s one level. The next level is the color, right? So not only is it a sheerline coat, it’s the color blue. That’s another level of gran granularity. Then it’s the size, right? So this is the size large. So I think coloring the lines also shows you over time how we’re evolving in our understanding of data.

Because there may be three projects over the course of a year just to get you to level granularity 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 it 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, 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 this story. That’s something I’m also working on too, is showing. 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 the 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 domain, but still.

Comprehensive, a complete story, not just a bunch of random skits have no rhyme or reason. 

Shane: And 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 three of the attributes against product ’cause 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.

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, is understand all the product SKUs. Just a, 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 are finished the actual information product. Let’s talk about the value that list of SKUs has. And then when we start adding the attributes, 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, because you need trust. 

Aaron: 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 have the framing done, okay, here’s where the things are gonna 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, 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 gonna trust you’re gonna 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 lemme show you how we put it here. This is where this goes. That’s the windows. Go here. But yeah, you definitely wanna show incrementally over time because you want to make sure that people feel comfortable that this is gonna pay you all the different installments and you have a good experience at the end.

Because that’s, we do a lot of that tour. Say, in a year from now, we’ll give you the thing. It’s how do I know that it’s gonna be what I, what I still want? How do I know that it’s gonna be what I asked for originally? And if I get to that to pay for, what if I say I don’t wanna pay for that, because that’s not what I asked for.

So definitely like how do you provide incremental value along the way to go trust and make sure that the user has a good experience working with you. 

Shane: 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 there. 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 there 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’s 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, is very low. It’s a high cost change, especially, 

Aaron: especially when you have questers 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.

Then our business requirements completely change. And you’re like, this would’ve nice to know a year ago if I put my house and all of a sudden the laundry room’s down. So you have all the bedrooms are upstairs for, actually, I didn’t realize that the bedrooms are upstairs, so I need to put a laundry room upstairs because now it’s too late or it’s gonna take us another year because 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, because 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 make sure they know, because 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 it so I don’t waste both of our time.

But if you waited too long into the future, you would’ve waste 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.

Shane: Again, it’s about fluency. We’re talking about data literacy, but actually it is just language. It’s fluency. It’s going back to your, your housing analogy. ’cause I, I love watching those Retrofit reality tv, our 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 have said to you, oh, a pot filler is a articulated pipe that elongates and extends itself to fill your pot, that that’s not gonna tell you what a pot filler is. Yeah. But if I showed you what a pot filler is, showed you on the wall over the oven or the the stove top. And the fact that it can pour water into the pot without you having to take the pot to a sink.

But if I show you that you’re gonna become fluent to a degree in the language of a pot, you’re gonna see it and, and know what it’s, and so that’s part of our challenges 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 slide dimensions? Type two, how do we not talk about byt temporal nature of data and business effectivity dates, 

Aaron: right? How do we talk to them about the star schema? We’re gonna build out the star schema. We’re gonna put this as your fact. This is gonna be your dimension table, and here’s your factless fact.

They’re like, like you just, yeah, it, it helps to commonize the language to 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 looks like from a data perspective. 

Shane: 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, 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. 

Aaron: What we’re talking through is it demonstrates how challenging it is when 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, a bunch of developers.

So who on your team is responsible for talking about 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 conversation because it’s never simple.

It’s never simple to say What’s business value are, are you providing values? There’s a whole bunch of conversations and you really have to lead down these back and forth question, answer sessions or 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 it or not using it.

So I didn’t provide them any values. They know like it. 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 gotta figure out the operating model of how your team can do this to really dig and answer that question.

Shane: One of the key takeaways for me is this idea of a storyteller. We are starting to see data storytelling becoming a thing where instead of just giving them back a, a list of data, we’re starting to tell ’em a story about that data, uh, 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, uh, 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, 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 gonna 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 are adding or added and just, yeah, and get good. That’s 

Aaron: 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 dunno.

It’s the data storyteller plus, uh, storyteller, plus your product manager who can tell you about it, but they can also figure out if anybody’s using it requirements as I think that’s where you’re starting to see these roles. 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 help translate that. So you’re starting to see these roles emerge because people realize they wanna keep their job, but they realize I’m leader. I’m also, I, 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.

Shane: The business analysts used to do that a lot and, and back in the business object 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 roll back into the data team’s great. Because I think it’s got divorce, 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 the 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, to tell some of those stories ourselves. And again, it shouldn’t be onerous, it shouldn’t be, uh, seen as sleazy sales. All it 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’ve set up the product catalog.

And we had to resolve that, Hey, have a quick look at this data in Excel. 

Aaron: Completely different understanding of our role. Right? I think, like I mentioned earlier, I realized that sales is the natural part. Of our jobs and 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. And I have to 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. And to your point, I think there is some, some sleeves and unease to it when it just feels forced or you’re trying to sell people something that they don’t want. But if it’s something that people find value, and 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 I, you know, a stakeholder 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.

Shane: And I think that’s a really good point, is from a, 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 and one that I hadn’t thought about. Excellent. Alright, 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. 

Aaron: 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 is a very good kind of discussion. I think these are. Conversation, we probably need to have more versus like now it’s all the, the deep seek and all these different AI models, the, the past week.

So I, 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 really stuff that our companies care about and like really want us to. To focus on and figure out. 

Shane: Takeaway for me is often I’ll see a team only focus on the data working they’re doing, what data they 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 flown, that data, the 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 gonna 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 gonna try next month?

So bring it in as a a conscious task. What are you gonna do next month, next 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. Yeah. So you need to consciously go and do that work. So treat it as just another data task.

You know, what are you all the team gonna do? Yeah. Feedback 

Aaron: loop. That’s also something I’m working my team on, is doing retros to say, okay, three months ago in last quarter we worked on this thing and no one used it or everyone used it, so why did they, or did 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 the requirements. Or we really need a strong business case because we, we were burned last time, so we don’t need to. So I think the value also helps us with the road mapping and flushing 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 values is just the, the feedback loop that it provides in the future requests as well to help flush that out.

Shane: 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. ’cause 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, yeah. Good takeaway.

Excellent. Alright, so if people want to get a hold of you, what’s the best way of finding you and finding the excellent stuff that you’re writing? 

Aaron: Yeah, I would say LinkedIn. So I would say find me on LinkedIn. I’m usually writing a couple articles, a couple 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 all somehow how I’m trying to contribute to the community. 

Shane: Excellent. And as I always say, sharing is caring, so thank you for caring.

You know how hard it is to write good quality content to think about it, write it up in your spare time while you helping an organization. I 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 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.