The Data Stack Show - Shop Talk With Eric and Kostas: Data Politicians

Episode Date: September 26, 2022

In this bonus episode, Eric and Kostas talk about data politicians in this new special show format.

Welcome to the Data Stack Show Shop Talk. This is a new format where we just go off the cuff and talk about a topic that is of particular interest to either Costas or me. We plan to have guests, so this will be a lot more informal. And to that end, I picked the topic for this Shop Talk episode, our very first one, and Costas doesn't even know what it is. So this is his first time sharing about it, which I'm really excited about. So Brooks can obviously figure out the title that this is my thought and what I wanted to get your take on past this. And it relates to data engineers or data professionals

also needing to be politicians within their company. And I will give a very concrete example of what I mean by that. Okay. So recently at RunnerSack, we implemented this new tool, okay? That is like a, whatever, some sort of engagement tool on the marketing side. It's always the marketers, right? Always. Always the marketers.

And it's a really cool tool and, you know, whatever, to help drive conversion and blah, blah, blah, right? And so there's a big appetite in the company to like roll this thing out fairly quickly and try it and sort of prove it out, like whether it works. And so as part of that process, to optimize for velocity, which you have to do in startups, you forego like some data tracking, right?

Like let's get this thing rolled out. And now we have a tracking plan and we have like absolutely very sophisticated, like very clean, like nice data set, right? And then of course, the thing starts to work really well. And so marketers and other people start to ask questions like, oh, that's interesting, Why am I blah, right?

But like you sort of, you sidestep the tracking process in order to optimize for velocity. Then you have to go back and pay technical debt in order to, you know, track everything and like join a practitioner or blah, blah, blah. Kind of a tale of the little sign in terms of companies. But what really made, like, that process got me thinking, like, this is just an inevitable part, especially in startups of, like, rolling out tools and trying to wrangle data or whatever.

But the more I thought about it, the more I realized that that dynamic is, it sounds funny, but it's sort of inherently political, right? Like, you have to navigate, it sounds funny, but it's sort of inherently political, right? You have to navigate, someone who wants to do comprehensive data tracking or whatever, you actually have to navigate a lot of different

parts of the organization in order to build consensus around the discipline of that, if that makes sense. So, anyways, that topic's been on my mind and I'm interested in your opinion of like, what, that's inevitable. Like, what is that?

What's your experience that inside of organizations? Like, is it even the responsibility of the data team to sort of, let's say like do police and politics, if that makes sense, around like that dynamic, right? And of course, as organizations grow, like the problems can become more severe with link-for-data sets and all that sort of stuff. So. I mean, I don't think that what you're describing is something that applies

only to data engineers, to be honest. I think it applies like to pretty much like everyone in the company. And I think it has a lot to do with the difference between like a company that is a startup and the company that is transitioning into becoming like a real company and I'm pretty sure that like if you, if you pay attention, like you will see like similar behaviors and like similar questions or like grimace, like also like in marketing or like in sales or like how, like it's always like this kind of like trade off between like velocity and process and how like you compensate for the

lack or like the difficulty of communicating and that's, I think like it's a continuous struggle, like with organizations in general, right? Like I don't think that it ever like goes away. Now, David Pérez- well, I'm going to back on you just a little bit. Like, so I agree with you. I agree with you in that that same dynamics happens within different organizations.

But the reason I was thinking about it so much was that for the data team, generally, their purview over data also impacts those downstreams, right? So like the, like I have a reason that that dynamic happens, you know, whatever that happens in sales or like that happens within marketing or whatever, right? That if you have a company that's at least trying to be data-driven, the doubts, the impact of the data team, like not having pervy over that stuff

actually impacts multiple. The impact of the data team, like not having pervy over that stuff actually impacts multiple. So my, my position is that the, it's a different problem than that happening in a siloed sense within like a particular organization like marketing. Henry Suryawirawanacik, Yeah. But like, okay. How many companies of the stage or like the majority of Threadrack have like a data team? David Pérez- Not very many. I mean, technically we don't.

It's like an entire team. David Pérez- Yeah. I think it's the fact that like the team at Threadrack like cares about that stuff or like has the luxury to care about that stuff is because of the nature of the company itself and the product itself, right? the team at Traderstack cares about that stuff or has the luxury to care about that stuff is because of the nature of the company itself and the product itself. You're building a product that is solving or is part of the problem that you are discussing. So you face it and you start thinking of it much, much earlier than other companies.

Like what companies at that stage probably don't even have like a data engineer. Like it's... David Pérez- It's up to you think that this, I agree with you, but like, this is a problem that I've seen happen at companies of like much larger sizes. Alexi Vandenbroek- Mm-hmm. Oh yeah, of course. Of course. I think that's where you start like seeing these problems, like larger sizes. Stas Moukaisaoukakis- Mm-hmm. Oh yeah, of course, of course. I think that's where you start seeing these problems, like larger companies.

And the question, I mean, let me ask you a question. What is the responsibility of the data engineering team in, let's say, a big company, let's say, I don't know, like a public company that is B2C and it has like a ton of data and they are very like data driven or they even have like products around data, like they do email and like whatever. So what did you think is like the responsibility of the data engineering, not the rest, because data teams can be like many different things, right? Like, but we're talking about data engineers. Yeah. Well, that's, that makes me want to return to my original, the original

question I asked, because I think my intention was probably more to figure brain on like the person was like responsible for all of that. But in that context, actually, I don't think the data engineering team, that's a good question. I mean, I don't think the data engineering team would necessarily be involved in that decision-making process. Right. Around like the implementation of that.

Does that make sense? Yeah. I don't think so either. I think the data engineering team has an infrastructure that they need to take care of. And they need to make sure that whatever pipelines run there,

they run. And the data that, for whatever reasons, they revert through these pipelines is correct. Okay? But I don't think that the data engineering team can go much farther than that in terms of responsibility. Right? That's where you start getting into who is, who is at the end the consumer of the data and who's going to benefit from this data.

So let's say it's like the marketing manager, like the product manager, like these are the people at the end who will be like, okay, why we don't have this data while we need it and how we can get it and why we didn't. Let's say do that that like from the, from the beginning, right? And when we started like designing the service or this product or whatever. David Pérez- Well, so let's, so let's dig a step deeper in the context that you're talking about. Cause I think that gets closer to the tension behind the question, which is the, especially in a larger organization, like one team does something in order to optimize towards whatever their goal is, right?

Let's just say, because I'm in marketing, we'll name steps. Your smile is Francis. So, SAIL does something or implements something with good intent because they're trying to optimize their role. But what they do

creates a byproduct of that as a data problem for marketing, say, right? It's just like, okay, well, now marketing's data set is complete because they don't have whatever new data, right? That the sales team is producing.

It ends up, which again, is an inevitable problem. And I need your point is really well-meaning. Like probably that description of RutterSack, RutterSack probably over-indexes for like maturity because of the nature of what we do and like the team we are or whatever. So the question is not like,

what do you do in that situation? Or I mean, that's inevitable, right? And like, there are ways to solve that. But I guess part of the question was, do you think that there is someone in a data-focused role who should be the arbiter of all of that centrally in the organization? I understand you're worried about data engineering. But I think part of the problem is that if sales is optimizing towards what they need to do, they shouldn't be thinking about the larger data layer and infrastructure. But because of that, they can't know that they're going to blow stuff up downstream.

And just because of the nature, I mean, I don't know, there's the duality of the answer, right? This, if you think about it, like there's not like a pull request for implementing a new sales thing that creates data, right? Like in the context of software, like they'll just do it or plug it into Salesforce or something. Yeah. Yeah. I think, I mean, at the end, I think it's like more of like a product

problem, what you're describing. And I don't think that costs you necessarily like with data roles. And I'll tell you what I mean. Like someone who's like dealing with data, let's say, let's take an analyst. Let's say you as a, like a marketing leader, you have an analyst that works with you to make sure that you have all the insights that you need. Yeah. And like a lot of times analysts are like, it can be a centralized function, right? Yeah.

But let's assume that like you as Eric, you have, I don't know, like someone there, like a data minion that's... They just like, they feel very informed. You are very informed. But like, I mean, the minion exists to answer all the questions that you have, right? With the assumption that these questions can be answered using data, okay? Now, I don't think that like this person can beforehand, right? Know what, first of all, what questions you have or you might have, and what data is going to be needed for that.

And that's why I'm saying that this is more of a product problem. Because think of whatever function, whatever you're trying to build as marketing or as sales as a product, right? Like at the end, why do you need data? Because the reason that you need data is to figure out the success of what you have implemented, right? Like that's why you need analytics there. And the impact that whatever you build has in the business.

So it's your responsibility as the stakeholder, like as the customer, okay, to sit down with whoever is going to build that and figure out how you can measure the success of whatever you are doing. And from there, figure out what data is needed and build the infrastructure for that. But this is not something that, let's say, the data role can do for you in a vacuum, right? Yeah. Yeah.

I think you're asking too much. Like, it's... Like, what do you expect from your minion? Like, the minion cannot, like, like a genie come out and just answer, like... Well, part of the reason... Part of the reason... This is why I, like... No, no, no, no, no, no, no.

You know what you're doing right now? You do exactly what sales do to marketing. When something goes wrong, sales will be, where are my leads? Right? And then you go to the data person and you're like, where are my insights? So I thought I was the one who was supposed to get insights from the deep. That's what I'm saying. Like you kind of like, we just, the problem always starts from sales.

These are the bad guys always. Right. No, I mean, that is a valid point. Maybe it is... Number one, I think it's really helpful to think about the various teams as producing products, right? Like, that's really, really online data as a key input to that. And maybe it's idealistic, but why can't there be someone who has a team agnostic? Like it doesn't have to be data engineering or analyst or whatever.

But, and I think to some extent, like ops roles can do this type of thing, even though those also tend to be segregated, right? Like, you know, revenue ops generally tend to like support the sales organization heavily, marketing as like marketing engineers, marketing. But it's compelling to me, the idea of like an individual or a team that has purview over those things to avoid the pain of like having to go back and pay technical debt in the product that you're delivering on marketing because of the decision that sales made because they don't know that what they're doing creates input problem for the products that market is doing am i just an idealistic person, Kostas? No, sorry, but my instinctive reaction is like,

you're not idealistic, you probably have daddy issues. Because you're looking for a daddy who's going to solve the problems for you. No, you don't need someone who's going to do that. You have to be aware of how you can succeed in what you're doing and make sure that like you you know that like data can help you with that so you can create the requirements that then this data folks can execute for you right like nobody knows the context or the problem or like what is at stake better than you. Right? And here, like, and that's the difference like between a customer and like building products for like real customers and for internal stakeholders.

Right? stakeholder, you should be much more engaged and you should be much more proactive in like giving the rights, how to say that, like the right information for the people who are going to execute to build the infrastructure and everything that is needed around that to help you succeed at the end, right? It's for your best interest. And like, you should try that. That's the difference between going to an arbitrary, building a product, like to go and sell it, right?

Yeah. Okay. I'm going to turn this back. I'm going to turn this back on you again to try to return to my

original. Sorry. When you have data issues, this is the type of thing you do. This is why our relationship is

difficult. So you're saying that it's not a centralized data professional that needs to be the politician. It's actually the person in the downstream team who has a vested interest in delivering their product that needs to be the politician and have politics with all the other functional elites. Yeah. You have to be an adult and not need to borrow it to take care of you. Like that's, yeah. Politician are two different categories, but I like how you're putting a sharp point on it.

Yeah. I mean, at the end, like... Ain't politicking inside the order. That's right. I mean, jokes aside, at the end, like, you can't build, let's say, any strategy around data without, like, the stakeholders truly believing that like this data are going to help. I mean, whatever they are doing, right? I have my like marketing campaign, it might be sales campaign, it can be a product. If me as, let's say, a product manager do not believe that like having data is going to help me succeed, like you cannot, I mean, you cannot force like

the implementation of that stuff right so that's what I'm trying to say that you can't have just someone who's going to let's say enforce a company to be data driven you need like every individual who's like responsible of creating initiatives to believe

that using data to optimize and build these initiatives is like a good thing. And it's not always a good thing, right? Like it's not always that data cannot solve everything. Yeah. Yeah. Would you describe that as maybe like a human data mesh?

I mean, I think that data mesh is an organizational thing, not a technology thing, that's what the evangelists of data mesh say, right? So yeah, I mean, I guess so. I think it, again, it has to do a lot like with the problem you're trying to solve and the, like how, like solve and educating the people in the value of using data to solve their problems. And again, not always data can help, right? But that's something that I think we all very standard example of this is you're a B2B company. You start having your first signups and you're like, oh yeah, like I'm doing three instruments like the signup page, because this is going to do my crazy

insights and you get like three signups a day and like, okay, yeah, sure. I mean, and by the way, two of them are like Gmail accounts, so they don't even like matter, right? So yeah, you're not like, you just don't have enough data, like to go like build your product that way. So yeah, that's like, I don't, I don't, I don't believe that like someone should have like the full responsibility of like, let's say enforcing at the end, a data strategy in the company.

I think it's, it's something that's part of the culture of the company itself. I love it. All right. Brexit selling as it's time to end part of the culture of the company itself. I love it. All right. Brooks is telling us it's time to end and I need to go call my dad. Yes.

Little therapist. I don't know. I mean, I think you're old enough to call a therapist instead of a dad do. It's a bit in a tall. All right. Thanks for joining us

on Dataset Show at ShopTalk. We'll catch you on the next one. We'll have some guests coming up for this format. And also, we'd love your feedback. Did you like what we talked about?

And do you want to talk about it? Give us questions. Shoot me an email, eric.datasetshow.com. And we'll catch you on the next one.