The Data Stack Show - 219: The First 90 Days of Data Leadership: What the LinkedIn Posts Don't Tell You with Matt Kelliher-Gibson, The Cynical Data Guy

Episode Date: December 11, 2024

Highlights from this week’s conversation include:Lightning Round Setup (1:15)Scenarios for New Data Leaders (2:33)Optimism vs. Reality (3:14)Cynical Perspective on Data Roles (5:32)Monitoring Systems Discussion (9:31)Executive Alignment Challenges (12:54)Understanding Team Dynamics (17:32)Head of Data vs. Head of Product (20:13)Product Development Steps (22:14)Consequences of Product Decisions (24:14)Challenges in Data Team Dynamics (26:03)Attribution Reporting Complexity (28:24)Long-Term Vision for Data Teams (29:22)AI Summaries Discussion (30:19)Closing Thoughts on AI Nuance (32:02)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Hi, I'm Eric Dotz. And I'm John Wessel. Welcome to the Data Stack Show. The Data Stack Show is a podcast where we talk about the technical, business, and human challenges involved in data work. Join our casual conversations with innovators and data professionals to learn about new data technologies and how data teams are run at top companies. Welcome back to the Data Sack Show. And today we are returning to our monthly installment of the cynical data guy, our special monthly guest,

Matt Kelleher Gibson, who is jaded over decades in corporate data, and he shares that cynicism with us and adds a dash of wit for fun. As always, welcome back to the show, Matt. Welcome. My time to reign over you all has come again. Okay. Reign on, all of us? Reign on our parade?

Yeah, I'm also just going to roll with an iron fist. Yes. The fist of Deva. Okay, I only have two items for the lightning round, and then we're going to read some funny AI stuff, if that sounds good. I actually do have a question. We'll kind of turn the third one into a lightning round.

Perfect. Okay, round one, I'll preface it slightly. There have been a number of posts on LinkedIn where there's a significant amount of, let's call it sort of armchair quarterbacking, you know, what you would do if you were head of data, right? Or like you take over data in a company. So we're not going to, you know, we're not going to read any because there are so many. I'll read a couple of samples that I pulled. Yeah, I'll just read a couple of samples that I pulled, but we won't mention any names. Okay, so you join a company as a head of data. You got to schedule meetings with everyone in the C-suite. You got to

ask the IT team for a full list of business applications. You got to create a spreadsheet from the top initiatives from each executive, et cetera. Let me grab another one here. You're often pressured to deliver quickly, sometimes feeling as if you aren't given the proper amount of time to consider data. Okay, so let's start there. John, when you see these come in on your LinkedIn feed, how does it make you feel? Especially since you've been ahead of data. Yeah. Remember, I'm the cynical one.

Remember. I'm going to try really hard on this one. I think there's a couple scenarios. I've been in a manager team lead role for a data team, been in an executive role with a data team, and a director role. I've been at a couple different levels all having data teams report to me.

Some of them have been formal, like this is a client-facing data team that we do data things, and others have been not even necessarily a clear boundary of who's on the data team and others have been like not even like necessarily like a clear boundary like who's on the data team and who does other stuff so i think there's like three practical scenarios of like hey you start as a new data leader one somebody got fired two they're like starting like they felt some need for a data team they're creating in that new

team and the third one i think is a variation of the net new team. Is they're like, oh, we kind of have some data people. We're going to reorg and create a team. And I think the unfortunate result of any of those scenarios is it's typically either one full of just a ton of optimism of all this value they're going to quickly create and save millions of dollars or generate millions of dollars in revenue. a ton of optimism of like all this value they're like going to like quickly create and, you know,

save millions of dollars or generate millions of dollars in revenue or B, the other scenario is something disastrous happened. Like, but like reporting the financials, like erroneously for the last like five years, like price, you know, like we priced all of our clients wrong by hundreds of thousands of

dollars i don't know something disastrous happened somebody got fired competition is eating your lunch right now yeah it could be so that i don't know that's my initial take because there are a couple different scenarios and as far as how the post make me feel i haven't really seen any that like actually dove into what i think is a practical scenario which is either like almost like hysterical optimism or like a at least year-long recovery route of like stabilizing like teams and infrastructure and like finding errors getting and getting the you know punched in the gut like multiple times a. Oh, how can this also be broken or wrong? Do you think it's, as you read them, do you feel like, when I say them,

these posts about, you know, if I were head of data, here's what I'd do in the first 90 days. Do you feel like you can tell, like at a gut level, who has actually been a head of data and who has not? Not necessarily.

But I think I can tell that a lot of people are posting seem to be in them either haven't done it or they're just in the minority where because i left out the fourth scenario which is technically possible is like there is a vacancy because like maybe somebody retired and the data team was great and well taken care of and everything was perfect and you're just stepping into a rock star's shoes that had everything organized and wonderful it's like i mean like a really nice sunset for a supreme court judge yeah they just they had a really long run and like you know right or maybe not retired maybe they went off like you know they were an absolute rock star killed it and they had to go start their own company that was the best thing for them

I'm sure there's some scenarios out there like that and maybe one or two of those people have been in that situation have you actually met anyone in that scenario? No definitely not I do not know them maybe my life could be different if I did you know okay cynical data

guy that was a very thoughtful nuanced if I did, you know? Okay. Cynical data guy. That was a very thoughtful, nuanced, well, well, what's the word for it? Just a very, you know, kind take, I will say. I have no room for that. So I need you to hold my beer for me. Okay. So you ask, what do I think when I see these posts? Yeah.

I typically roll my eyes because they make no sense to me. First of all, because they're always talking about, and it's a good thing. Got to meet with executives. You got to do this. Cool. That's all fine. You know, they never talk about any of these. The team you're inheriting.

They act as though you are coming in and it's a blank slate. We're just going to go figure out all the wonderful things we're going to do. Your actual first weeks, that's what you want it to be. Then the first week of you being there, you're like, I'm really going to just sit and learn until that Tuesday on day two

when something breaks and now everyone's yelling at you to fix this thing that you didn't even know existed until five minutes ago. And also just, you know, you have a team. Who knows how good the team actually is? If it's a smaller company, you probably only have a few people. You need to know, like, what are they good at? What do we actually need?

Things like that. They also just always have this feeling of, well, I'm going to go to IT and they're going to tell me where everything is. IT never knows this. IT doesn't want to spend their time telling you this or trying to figure it out. So true. They don't want to do that. So it's like, how am I supposed to figure this out? You got to just go do the work? Like, that's what it is. They all assume this is like a startup and it's not it's almost always a turnaround or the worst one is it's not really it's not technically a turnaround because nobody will admit that it's actually a turnaround so part of your job is convincing everyone who's like you

came in and they told you about all the wonderful things they're doing they show you this slide with their tech stack on it they talk about how great the team is and then you step in there and you go this is all chewing gum and like toothpicks and half the team doesn't even know what they should be doing and now you have to try to communicate that to people who are like no we've been doing great we've been doing great well We've been doing great. Well, when, you know, when Mike was here, everything ran fine. It's like Mike was just making up data and lying to you about it. That's such a good one. It's like when Mike was here, everything ran fine. And it's like, yeah, like, how do I tell you that you've been looking at things that are just, like, patently false? So when you ask the question, like, can you tell who's done it before? I'm like, yeah, I can tell.

Because a lot of times, this isn't everybody, but I've looked on a couple of these posts and gone, wait a minute, who is this person? And you see CEO in the title, and you're like, okay, they have obviously done something. Until you go to their experience and you find out they were like a developer or an analyst for like 6 to 18 months and then they started a company they have no idea what it's actually like doing this and they wouldn't it's not like their fault that they don't know but it just comes off as very well let

me tell you how this would work okay huh sure that sounds wonderful the then the things that are one of the hilarious things to me are two one one thing that i haven't ever seen that that is yeah i i would say that i think a majority of people probably haven't done it that are posting about this because the thing I haven't seen that I would always start with was some sort of monitoring of things breaking. I never see people say that as the first step in these posts. We need to implement a way to know if things are working or not working.

Never see that as step one. And I'll point out with that, the other thing is your mean time between horrifying discovery is going to be about five minutes you can't change anything when you're like all right what are you you do what okay wait we gotta fix that wait a minute wait you guys pull data how is that on a google sheet if that guy doesn't work here anymore it's on his account like you can't change the account when you're in the middle of that yeah appreciate just happens real stories i've been there for that it does yeah it totally does and it's like

you can't change stuff when you're in the middle of that you have to kind of almost like stow it away like have a notebook where you write it. And then once that meantime between horrifying discovery gets bigger, you can start to prioritize some of these things. So, okay, I have a follow-up question to round one. Great takes, by the way. I actually thought John's agreeable take was delivered very diplomatically as a chief data officer would deliver it to, you know, a variety of stakeholders. But upon further analysis, actually so fairly cynical. That was pretty cynical.

Actually, I'll tell you the cynical part was you. The best part was when you just slightly change your tone of voice and you're like, maybe someone retired. I was like, man, John. Maybe. Okay, even just if we think about the last three or four months of the show, we've had different people who've had head of data positions. And one of the interesting things about those discussions is they vary really widely, right? So as opposed to

my first 90 days as a, you know, CFO, my first 90 days as a CRO, right? You know, I mean, of course, there can be variations in some of those roles, right? But the chief data officers that we've talked to on the show and the discussions we've had, the role can look drastically different company to company. And so I think another reason that it's funny to see these posts is I think in many ways the role at an executive level is still being defined, right? And my sense is that there's a lot more

variation for an executive data role than there would be for something like you know a chief revenue officer or something there's also a lot of companies that aren't hiring executive data roles their job description is super tech with you know and do the budget or something but really just make them do stuff right so that i can get my report faster right yeah and i don't and i think a lot of companies don't necessarily need they they for sure don't need a cio c, and a CTA officer at a 250-person company. I think that's the problem. There's a group of technical roles, and you probably need one technical executive

at a certain size. Another size, maybe you need more than one. But when you pick, I'm actually optimistic on CTO becoming more common as a technical executive as people use more SaaS tools and there's less infrastructure. Because that's why I like CTO or more technical executives. Oh, interesting. It's because of infrastructure. They had to put somebody in charge.

Right. So, okay. So, you're bundling your stack and paying SaaS vendors to manage it for you. And so the footprint of the technical problem becomes about integration, data integration and sort of fascinating. Yeah. Fascinating. So I think that's a reason why you could say, hey, we have a CDO and not a CTO or CIO. Where in the past, like, of course you have a CTO or CIO.

And then maybe you had a CDO as an add-on if you needed that for your business. Yeah, I mean, one interesting thing on that I was talking with someone who was actually in product at a really large e-commerce company and they do a bunch of consulting on the product side of things for e-commerce companies. And one big trend is as platforms like

Shopify have become robust enough to serve really large companies, which wasn't, I mean, that's actually relatively new. You have these engineering teams where it's like, we have 20 people managing this intense e-commerce

application, and now they're migrating that over and you know cutting the team by 60 70 percent you know yeah what i do hope we see with some of that in your scenario is we're still mostly pulling cdos and vps of data from the infrastructure side former engineers from architects things like that and i think that is something that hampers your ability when you want to move from hey we just need to keep things running to we want this to be a value add we need people who have experience closer to it the analyst the scientist side of it and right now that's just not the profile that people are hiring for. Yeah. Interesting.

To give you one last idea on what it feels like, I remember when I went into a senior director role, and I had lunch with a friend of mine who was the president of another company. And the first thing he asked me at lunch, it was my week two I was on the job, was, so have you figured out who you need to fire yet? What was your answer? No, we did not fire anyone in that one.

I managed a few people out of positions, but we didn't end up firing anyone. Yeah, that is a really, yeah. I think that's, I mean, that's the rough part of it, coming in and taking over a position. But I think in many ways, you have to go in with that lens, right? Like depending on, you know.

And I haven't seen a single influencer post to include that as part of the striping over. Shocking, I know. Yeah, I mean, yeah, I've talked, one of my friends has held, you know, sort of marketing and product marketing roles and then a bunch of executive roles for a bunch of Silicon Valley companies.

And when he was interviewing, I mean, he would essentially sort of build a map if he was inheriting a team before he even took a job of like, I'm on a pretty good sense of like, who needs to be fired, like, you know, et cetera. I think another take on the executive thing that all of them mentioned,

like you need to align with the executives on things. I think that is really glossed over in a lot of these posts. True. And that like, I'm sorry, and having been in this position, when's the last time you met with an executive that had a clear idea of what they want to do with data?

Like, never. Or, or... That was... This show is really taking a cynical turn here. Here's the other version of that. Because I've led an internal consulting group at a company where our job was to basically help you do everything better. And they made a big announcement about it. It was a center of excellence, all that type of stuff.

And the reaction from most of the departments was essentially from the VPs was, that sounds great. I'm sure other people need it because I know how to do my job. Yep. One other thing I would say that I haven't seen articulated super clearly, you know, talk with executives and understand priorities, but I would actually say another big one is understanding trust and credibility. And you really need a map of that because it actually doesn't matter. Even if you figure out what other executive priorities are, if you don't understand

how much they trust you, then it doesn't matter. And all of those kind of informal power structures. Yes. I mean, the farther up I've gone, and John, I'd be interested in your opinion on this,

I feel like there's a whole kind of map and knowledge of what you need to do at once you get above a certain level but that it's like secret knowledge no one talks about it they always give these very positive glossed over answers and it's only if you can get to know one of these people and really talk to them that they'll get into the details of like oh yeah we'll see you got to go in there and you've got to be able to fire these people and you've got to make these decisions and you got to structure how you're doing your work this way but like no one wants to talk about that yeah which comes back to the trust thing so i think a lot of these posts get into like you need to align with the data priorities of your executive like is where it starts it's like no you need to a understand all the executives perceptions of the problems b you need to go

figure out what the actual problems are c you need to figure out alignment between the perception of the problems the actual problems and then come up with a plan to like how data can help with the actual problems and then align that with the perception of actual problems which never matches yep that's the hard part you also need to figure out which executives do i need to be willing to do favors for that are things i don't want to do versus the ones that they're going to always ask for this i'm never going to get anything out of it so i'm not going to do this for them because you will get stuck in that you know know, it's like the 80-20 rule. They're the people that will spend

80% of your time. They will completely block you up and you will get nothing for it versus the people that you should be like, hey, I know if I give a favor and if I do this

for this guy over here, he's part of this informal power structure that will give me leverage to go do other things. I also love that we just... Art of war over here. We just called on everyone who's been making these posts, and then we just said, like,

here's, you know, so guilty as charged. I think I might have to make a post now. Yeah, you probably will. Okay, that was a great lightning round. Insightful, healthy amounts of cynicism from both the cynical data guy and the agreeable data guy. That agreeable data guy. That was a good one. I'm proud of that pick. Okay, that's a new standard for me. All right, lightning round number two, and then we'll go to AI fun. I'm going to read this one out. Okay,

this is interesting. I'll read the whole thing. And this is Sebastian Hewing. We'll give you a call out, Sebastian. Reach out to us on the show. We'd love to have you on if you would like to join. Very thought-provoking post. There's no difference between head of data and head of product. Both must build products that make the company money. The operating model doesn't differ between a head of data and a head of product, and this is a list. Talk to users all the time. Identify user problems and hidden desires. Understand users' jobs to be done, figure out which problems are really painful, build MVPs to address these problems, measure user adoption using qualitative and quantitative feedback,

iterate the solution until it reaches product market fit, start again from the beginning. It took me years to figure this out, but once seen, it's impossible to unsee. Data teams that struggle are usually ones who haven't seen it or don't want to see it. It being, you know, no difference between head of data and head of product. All right. Cynical data guy. I don't know enough to be able to say if it's the exact same as a head of product, but I definitely think having a product mindset will help you. Definitely. That is one that I

think one of the things that had helped me in my career was I embraced more of that idea. This is a product. You got to think about it. It doesn't matter what I think is best. I got to go talk to the people who are going to use this and figure out what it's going to do. sites I had on that was looking at it and saying there's kind of two ways you can build stuff for people one is the we built this thing it's amazing and it's fantastic and if you would just do it the way we tell you to yeah it'll work great the other one is hey you do this thing it is painful for you I built it into your flow, right? And that makes a big difference on just, will it get adopted or not? But I mean, I will defer to the actual head of product in the room. Oh, yeah.

Let's get Eric's take on it. Oh, wait. So am I going next, not you? Yeah. Okay. You're the head of product. I think it's a really valid, I think it's valid.

And I think I would reiterate what Matt said in that it's really about having that mindset on building anything, right? that the list that he writes out for, okay, how do you build a product? It's pretty long. And that's really important because if you miss any of those steps, it can create severe problems, right? But the reality is that in a lot of product organizations and data organizations, whatever,

you'll skip a couple of those steps, right? Right. And I think that can be really problematic. I think where I would disagree on some level is, I mean, probably, I guess, if I met Sebastian, we'd probably be very aligned. The first sentence in the post, I think, is just overstated, but that's LinkedIn. There's no difference. I don't agree with that.

And one of the big things, there are a number of things, but I'll tell you one of the biggest things that came to mind immediately when I read the post was, and we've talked about this before. Actually, we talked about it recently where we talked about it's okay to build something, build a data product for two months,

and then if you get 80% of the answer, you just throw everything away. That's okay. You should afford for the exploratory nature of data. The ability to store immense amounts of data forever has just never been easier or cheaper. Of course, technical debt exists, but it is way harder to kill a product

that end customers are paying you for that is deeply tied into your software platform. That is hard for a number of reasons. And you cannot deprecate things. You just can't deprecate things as easy. I think that you should be willing to do that if something's not working. Like, of course, you know, those are sort of core principles there. I don't want to describe that as saying, like, the stakes are different

because I think that, you know, it's just that the consequences for making certain decisions when you roll a feature out to production and people start paying you for it. That's a different dynamic, at least in my opinion. John? I actually know Sebastian. He's great. Runs Data Action Mentor. And I agree with the philosophy for sure.

The product philosophy here. I think the trouble is some data teams aren't set up to be able to do that some also don't want to that's true that's true but if i were to give it like let's go back to the head of data thing if i were to give advice to a head of data thing it would be absolutely to have this mindset and then the practical application of this mindset is exactly how you ended, Eric. Number one, you associate your data team with some revenue generating activity or at least with some forward client facing activity.

So where it's like, A, are you producing analytics that clients see? That's good. Even better than that, are you producing some that clients see? That's good. Even better than that, are you producing some sort of data analytics that somehow impact revenue? Because if you're just stuck and we only produce accounting and operational things,

that is an easy target for like, oh, we need to lay off some people. It's an easy target. Yeah. The only caution I would give to that is I have worked with people target for like oh we need to lay off some people yeah like it's an easy target yeah look only caution i would give to that is i have worked with people where if you don't understand the situation of like they don't want you to be a product person it can get you in trouble sure i mean i worked with a guy who was in charge of bi and he came in with this idea of building like a platform,

like an internal platform for people to use. Self-service? Oh, you know self-service. And he viewed it in a way which was like we were building a product. So he primarily brought in like BI developers. And when we got into it and when he, you know,

and by the end of his tenure there, um, what became really obvious through it was, I didn't want a platform. Yeah. I didn't want any of that. He wanted reports is really what they wanted. And so he had,

and I don't blame him for doing this. Like he, he had been sold a certain vision and was going on it, and it was only when he got six, eight, 12 months down the road that it became super obvious. Yep. Because as I said, they lied to you about this stuff. Right.

I mean, he built a team that was completely wrong for what the need was. Yep. I think the parallel math that you drew with both of you, getting close to the problem, I actually think one of the interesting things that I would add on to Sebastian's post

is thinking about your data, like the individuals on your data team, are they actual product managers? Someone who is just, I have raw skill as an analyst, isn't a product manager in the sense of like a product team necessarily. It can be, and the best ones often are, but I would say that's like a great, that would be a huge way to actually achieve running

a data team like a product team. The hard part is finding people who can do both of those. Very difficult. Because especially if you're someone who came up with that mindset, because I did this, you overestimate that people want that mindset and that they can develop it quickly. I'll give you one example of understanding building in some downstream problem is attribution. Attribution reporting is something a lot of companies struggle to build.

And it's one of the reasons is that because running the advanced digital marketing is extremely complicated, and understanding how the platforms deliver ads and the way that data is captured, it's pretty, you know, you have to have a pretty good knowledge of that, how to use it, you know, all that sort of stuff. Right. And so, which is incredibly important for understanding, you know, how to shape attribution. Okay.

We are one other quick, quick thought as far as I guess I'm full of advice today on the data team thing. I think the other thing to think about where like Matt was talking about this too, is it's, it's so easy to get stuck on like the current, like what is like what the data team was doing. And it is really hard to break out of that. And then to come in with a vision of like,

we're going to change everything. We're going to change the culture. We're going to change all the people. We're going to be doing something completely different. Like that is very hard. And I think sets most people up for failure and i think a more reasonable approach like your friend that like did the platform thing self-service would be to come in and like go for things like stability and trustworthy data and accuracy and then like build off of that into something versus like coming in like yeah we're going to change the world

and change everything. And the hard part with that is that you have to be thinking in years. You have to be thinking in years, and the average CDO tenure is two years. So it's a little bit like being a football coach in that sense. You've got to set up the right foundation

and the right culture to be successful on the long front. But also, if you don't win the next two years, you're going to be fired. Okay, we are really close to the buzzer here. So super quickly, have you seen the AI summaries that Apple is delivering? So there's a great CNET article. There's probably a bunch of these. This is from the article.

The other day, I received several text messages about how bad a hike was and how that person felt dead, tired, along with some other sparse details. And Apple Intelligence summarized those messages for me. Hike extremely difficult, almost fatal. Another one, this is a text I got about how a trainer killed my friend

with a particularly tough workout. Apple AI summary. Trainer allegedly killed needs to go to hospital. Okay, here's my hot take, but I want y'all's quick hot takes on this. This is funny, but I also think that it makes it hard to appreciate the actual value of AI sometimes.

Or to control perceptions around the technology. I hope it's not damaging. I hope it's not damaging, right? Well, I mean, the early days of Siri had some similar stuff and there's a whole bunch of people who just never used it, never wanted it, because it messed up early on. So, I mean, it messed up early on. So I mean, it's a tough one. Yeah. Yeah. I mean, it's an interesting take actually from a company that's

very cautious about releasing things early. Totally. So that's the fascinating part to me. I had another one on here. This is one from Reddit from Nick. For anyone who's wondered what an Apple intelligence summary of a breakup text looks like, no longer in a relationship wants belongings from the apartment. And he basically goes on to say like, yeah, this was a good summary. But there's that tone thing and that like nuance thing that clearly like they haven't quite mastered yet.

Yeah. I mean, you see see it on Slack AI too for their stuff. I was just reading one today where it said that John Smith made funny comment. That's a weird summary and I clicked on it and it was literally a post that said funny comment and a link.

The person didn't make the funny comment. Whatever. But I mean, like you said, it's getting it right in some ways. And this is, you know, still impressive

for a computer to be doing that. Yeah, totally. Tone and understanding. Yeah, yeah. Sarcasm. Not there. Never.

Metaphors, not there. Not there completely. Yeah, yeah. The many facets of AI. All right. We got to close it down. If you have any funny AI summaries, send them our way.

You can go to the website, fill out a form or send us an email and we'll talk about them on the next show. Ooh, yeah. Yeah. Love that. Stay cynical. We'll catch you on the next one. See ya. The Data Stack Show is brought to you by Rudderstack, the warehouse native customer data platform. Rudderstack is purpose-built to help data teams turn customer data into competitive advantage. Learn more at ruddersack.com.