Building Effective Data Teams

Welcome to the webinar. This is Richie. Now, at this point, I'm sure you're aware that basically every organization has a data team. The problem is that not every data team is a great one. And so the impact of each data team varies wildly from business to business. And data teams are important enough that this. Whether you've got a rubbish data team or a great data team that can dramatically change the fortunes of your organization, you can't just hire some data scientists and expect magic to happen. So today, we're going to get some tips, tricks and heuristics for building and managing the kind of data team that your organization deserves. Our first guest is Pamela Zappoli, the Director of data quality and Integrity at Warner Brothers Discovery. She's got over 15 years of experience in building and managing many data teams with function spanning from data engineering to business intelligence. She's mentored dozens of data practitioners, transformed processes and workflows, and led her team to business success. Before Warner Brothers Discovery, she was in for sorry. Before her current role, she was the Director of Business Intelligence at One Brothers Discovery, and she's also a board member of women of WBD. Our second guest is Tarush Agarwal, the CEO at the full stack data platform 5X. He's built, managed and scaled many data engineering, data analysis, and machine learning teams. He's also a columnist for the Data Scientist magazine and an advisor for the International Institute for Analytics. Previously, he was the head of platform for china technology at WeWork. He was the head of data and analytics at Wing, and he was an early data expert engineer at Salesforce. So, two esteemed guests here today. Welcome, Pamela, and welcome to Rouge.

All right, thanks, Richie. Excited to be here?

Yeah.

This is going to be a lot of fun, I think. So just to begin with, I want to know where we're trying to get to. So I'd like to know how you measure the success of a data team. Pamela, do you want to go first?

Sure. So basically what we'll do is we'll begin with what are our goals as an organization? Like, what is the business strategy at hand for this particular year? And then what we'll do is we'll work with our stakeholders to understand the specifics of where we're driving to, like, what data products are we going to need? Like, for an example, with our company, we have recently launched globally, so there will be additional data products that will be needed to support the business to provide those data insights. So how do we measure those goals? We'll work with our stakeholders. We'll set up an initiative around the launch and then we'll also circle back with them to get feedback. And one other way to ensure that we're meeting our goals is to see is the data product usable and we can use our own data driven answers from the activity of the teams that are using the data products.

Okay, so I like that you starting from goals and then trying to figure out how do you actually measure the success compared to those goals. Tarush, have you got anything to add to that? How do you think you should measure the success of a data team?

I think there's obviously a ton out there and there's a lot of debate out there. I think to simplify everything, I really look at success as this concept of data ready. Data readiness historically has really powered bi, has powered analytics, has powered what we call reverse ETL or data activation. But all of a sudden we have a new sort of stakeholder, stakeholder in the room and that's AI. And you know, everyone might have heard that you can't have an AI strategy unless you have a data strategy. And if you don't understand your data, and if you don't understand your data, neither is AI going to understand it. So I think data readiness has single handedly become the most important as you think of effectiveness of data teams. And really what data readiness really involves is your average mid sized business has got 50 different data sources. So how do we sort of centralize these data sources? How do we clean and structured model this data in a usable format and then this really powers data readiness. And that is as I mentioned, the sort of foundations of BI analytics as well as AI. Does that make sense?

Okay, so that's interesting that before you start thinking about how do I have a successful or effective data team, you've got to make sure that the data is in the right format and governed. And this is close to your idea of data readiness. Okay, so that actually begs another question, is like where do you get started? So yeah. So what's step one then in getting data ready, getting to data readiness? Tarush.

Yeah, so you know, we're living in a time where your average business today has got over 50 different sources of data. This is everything from your backend databases, this is your CRMs, help test software, sort of marketing platforms, a ton of Google sheets, webhooks, sort of custom different sort of this is includes custom data sources. So we have this data in all of these different places. The first step really of all of this is to be able to centralize this data. So we Want to centralize this data, it's flowing into a data lake or a data warehouse, whichever is the flavor of the day. Once you have data over there, this is typically built in a way for that particular application. It's built for Facebook ads, it's built for your backend database, it's built for your sales teams inside Salesforce. It isn't built in a way to holistically answer questions. So building on top of raw data is really not advisable because everyone who builds on top of raw data is exposed to the bad data quality issues which go along with it. So probably one of the most important steps as we think about data readiness is this concept to clean structure, sort of model your data and get it ready for consumption. And that really is the second half of data readiness and really probably one of the most important pieces.

Okay, interesting. I like the idea that you've got to just make sure that all the foundations of data infrastructure are in place first before you can start thinking about being successful. Pamela, do you have a take on what you need to do first to make sure that your data team is set up first?

Success, Sure. I think I'll add to what Tarush was saying about the data quality. Right. Because that was kind of my bread and butter in this last year and a half that we were fortunate enough to also set up a data quality team because I think it's paramount that the data be pristine. Right. It's going to be utilized across the organization. So we took a shift left approach to that so that when you are actually building that centralized data platform, when that data lands, when you know you've initially processed it, you are looking at the quality of the data such that when after you build the more of the aggregated layer or the semantic layer that the teams will be utilizing, even your internal stakeholders. Right. You'll have, we'll have a centralized data team analytics team that is building out some of these products. But then we also want to make it self serve. And in that instance we want to ensure, we want to create a relationship of trust with the stakeholders who are making business decisions from it. So I think it is very important to ensure the quality of data. And as we move to building and utilizing AI more, it is imperative that the quality of the data is sustained.

Okay. Yeah, certainly data quality is one of those like ongoing issues, I think in every single organization. Yeah, it's one of those problems that's probably never going to be solved completely. But I like that you mentioned self service analytics because that's like as being a sort of end goal. Because ideally what you want for a successful data team is the data team doesn't have to do work everyone else can do, do the work for them. They can do it by themselves. Okay, I'd like to take a step back to the beginning. So suppose building out your data dream team from scratch, who is your first data hire? What sort of role, what sort of profile you're looking for? Pamela, you go first this time.

Sure. Since you, you have a core initial team. Right. So your first person, tough on them, but they're going to need to have a lot of skills across. So I like to call it that they need to have analysis skills and analytical engineering skills because they're going to be building that first set of data product. So they need to understand how they would build a data product. What do they need to do to sort of wrangle that data, you know, the raw data into a data product. That makes sense. So they need to have the SQL skills, Python skills, and also besides the technical skills, because as we know, as we move forward, they can be learned. It is very important for them to have the soft skills, being able to work with the business and to understand the requirements and be able to communicate what's next, what's going to ask the right questions. I think to be data curious is also an important soft skill.

Okay, so we got analytic skills, engineering skills, or data engineering skills. We got understanding the business side of things and curiosity. That's a lot of skills. I'm not sure whether you cheated because you want everything, but it sounds like you would, you would start with like a very senior profile as your first hire. Is that correct?

Yes, yes. Okay, that's correct.

All right, Tarush, who's your like dream first data hire?

I think it's a really interesting question. Right. Historically, it's been more a sort of pyramid structure. Right. You first need to bring in data platform engineers and they're the ones who build your platform after that, probably data engineers who are building your pipelines and modeling your data. Step number three, you would bring in your analysts and BI engineers who are building your dashboards and doing your analysis. Now, I think that's kind of the legacy world of how to sort of get stuff done. The sort of reality today is, you know, building a platform is no longer very complicated. You have all in one platforms. You know, a lot of your sort of building your pipelines are now automated with automated ingestion tools. So I think we've entering this world where, you know, I think the new sort of personality you're looking for is what I call this sort of data, is what I call the data jet, the data generalist. They have a combination of these few skills. You don't have to build platforms anymore, you don't have to build pipelines. So sort of data modeling becomes sort of very, very key. And I'm now looking for someone who's got end to end skills who understands a broad set of what does infrastructure, what does modeling, what does bi look like and can kind of go be very, very effective in the first sort of week or two and start building, you know, your first outputs, your first sort of dashboards, which sort of typically is taking organizations, especially larger ones, you know, between, between sort of between sort of three to six months to action. Does that make sense?

It does, yeah. So it's interesting that like traditionally you start like really low level infrastructure. You have to gradually build up the layers till you get to the business insight type stuff. But you're saying that infrastructure is getting easier so you can sort of almost, not, maybe not quite skip that bit, but you don't need too many dedicated professionals at the start and build things step by step. Okay, all right, so that's this, that's the sort of starting point. I'm curious as to what the end point is. Like what does your data team or department look like? Like what's the mix of roles at the end and yeah, how do you split things up? I suppose it's me quite different answers.

I know.

Tarushe, you're working at startup, Pamela, you're working at Warner Brothers. Discovery is a very large organization, so I'm guessing there's going to be some differences here. So. Yeah. Tarush, what's the end stage for your data team?

I think when we look at what do data teams really evolve into? They are, you basically, you basically start to have this concept of centralized as well as decentralized teams. Right. So you have a central team which is really responsible for the core data models across the company. So these are metrics which multiple teams use. This could be things like users and financial and sort of core marketing sort of metrics and they're sort of really responsible for these sort of, these sort of core sort of dashboards and sort of metrics across the company. Now at the same time as you become larger, you also want to have decentralized teams. This is typically embedded inside functions like finance, marketing, sales. This is also at the product level where different product teams have their own sort of data engineers, their own data analysts and they're responsible for really the sort of data models which fit into the regional or the sort of localized model. And so it's sort of important to have both. You want to have centralized teams to ensure you have consistency across the company. Although anything going to the central team is going to be a lot slower because by nature they're building stuff for the entire organization. They want to have more validation. They want to be sort of very, very careful about backward sort of compatibility. At the same time, in order to sort of prevent change from becoming too slow, you need to have some level of decentralization to allow smaller teams to basically move quickly on their own sort of data models. So, you know, it becomes less about, you know, what's the breakup of data scientists and data engineers. You know, all of that is more driven by, you know, what's sort of needed at that organization and where in the data majority curve it is and more so sort of team structure as to how do you effectively sort of deliver these teams at enterprise scale.

Okay, that's interesting that the team structure and where you put the people is maybe more important than the precise role. So you mentioned like some, you want a central data team for organization wide stuff, I guess maybe like the lower level, like closer to infrastructure engineering things and then you want some people embedded in the other product teams or whatever. Okay, Pamela, what's your take on this? How do you. Do you prefer centralized team or decentralized? Who's in it?

Right. So I've been in the data space for a long time, so I've been in this pendulum consistently where it's centralized, decentralized. And I can say, I think I agree with Tarush that today it's a little bit of both. I think you spoke more about the, a larger enterprise than rather a startup. Right. Is that you'll have that central team that does build out the data product that feeds say 80% of the organization throughout, like marketing, you know, finance, product, et cetera. And then you'll have some core roles within these organizations that you could say that are quasi decentralized because they have sort of suite initiatives where they have to build niche data products. Right. They may have to build on top of what is decentralized. So I see this as working quite well. I see this we're doing this today at WBD and we've gone back and forth throughout many of the ebbs and flows within the data space. So I definitely see this working well. Where predominantly a lot of your engineering is within the centralized team and then more of that analytics or even analytics engineers that they have some savvy with SQL, et cetera, are in more of those, let's say, decentralized or specific niche teams that are answering specific or writing specific models to support your business initiatives.

Okay, yeah, I can certainly say it's like a common management trait to keep changing mind, go, oh, well, if we just centralize this a bit more, then this is going to be better and you forget the downsides and then you go, okay, well that didn't work. Let's try decentralizing now. And you go backwards and forwards. But yeah, I can certainly see how you don't want every single, like department to be having their own data pipelines and things and different technologies. That's going to get chaos. But actually, once you get closer to the business side of things and like trying to get insights from the data, they do need to be. Maybe you don't want a central team for that because they don't understand the business as well. All right, so let's talk about the skills you're looking for when you hire. So maybe we'll start with technical skills. Pamela, are there any particular technical skills that you think are important when you're like, what do you look for when you're hiring data practitioners?

Sure. I mean, it depends on the specific area. But if we were to look at a lot of the data engineers, they have many years of experience in building pipelines and they have experience in SQL, Python, then if you're looking at from a perspective or like Spark, Kafka, because they're building how the data lands and then that aggregated layer, which today we call more of a semantic layer, that will feed a larger group of people utilizing the data from our data platform. And then also in addition to that, they do need to have some business skills to understand why the, you know, why they're building that pipeline this way. Because then they can be inquisitive to the stakeholder to, you know, build more aggregated layers that will feed a larger group of people. So that's what we're looking at doing today, trying to think if there was anything else that. I think that another key point is having the experience to deal with complex stakeholders, you know, folks that maybe don't know exactly what they want. So, you know, working hand in hand to ensure to think a little broader, you bring in their experience to suggest and question, you know, why, why are we going to look at the data in this way? Perhaps we should model it this way.

I, like you use the phrase complex stakeholders for someone who's just like asking you annoying questions and saying, please do this, but I don't really know what I want. Very diplomatic. All right, so what we got there? So we got a mix of. Yes, there's the Python, SQL stuff, working data pipelines, bit of business knowledge. Okay, Tarush, is there anything else there? Like what technical skills do you look for?

I think no, I, you know, I kind of fully agree with, with, with, with, with Pamela. I think for better or for worse, sort of SQL is the, the de facto language of, you know, the, of the data world. You know, even when I look at kind of the rise of the data generalist, right? Like, you know, sort of core SQL, core Python, that's the language of data. That's how we sort of communicate with it. And then the soft skills layer, which is, you know, sort of, as Pam mentioned, in terms of communication, you know, extremely important in sort of dealing with stakeholders. You can have all the technical skills in the world, but if you can't, you know, go sort of convey a room and it's, you know, I would kind of go one level further. I think data, I think data storytelling has become sort of very, very critical. And then, you know, I think again, like in a world Today, there are two types of companies, right? Companies which are actively building AI and then companies which are leveraging AI. And I think we're going to have like 95% of the world actually going and leveraging, you know, AI models and sort of leveraging Gen A, not actually building it themselves. So things like pricing optimization and supply chain and inventory and, you know, sort of recommendations are all, you know, consuming these algorithms and sort of actually mapping your data into this stuff. So I think, you know, on, you know, kind of understanding the broad sort of ecosystem and the tools around data science, I would argue that like, for majority of companies, you probably don't need like PhDs and like stats or like ML to actually go build these algorithms because chances are somebody has built a really good version of them. Does that answer your question?

Yeah, that's interesting that you maybe don't need that kind of PhD or stats because, you know, probably there's some code out there you can create balls, some work you can borrow just to get you started. Okay, so you mentioned soft skills there and the idea that communication and data storytelling is incredibly important. Are there any other soft skills that you think are useful in this area? Like what do you need? Data professional. Was there anything you missed?

Just being fun to work with and most undervalued skill in life. Just like, just have, like, be, like, fun to work with.

That is actually, I don't hear the answer very often, but I asked this question. That's a really good answer, actually. I heard a few years ago, there was some company where during the job interview, they would make you tell a joke, and that was, like, a requirement. You had to be able to tell a joke to go and work at the company, which seems a bit extreme, but also kind of cool. All right, Pamela, are there any other soft skills that you think are important?

Yeah, I have a few. I would say being data curious. So always, like, asking questions about it, because sometimes people don't feel comfortable and asking questions, and you learn so much more from that. And also, though, being a great listener because you learn from each other. Right. And then the other one, I would say, is to be creative because you can come up with solutions. That may not be the norm. So I definitely embrace creativity. And it's funny that you said that, Tarush, because I always have this thing is like, bring joy. So. Because when people are having fun, things happen. You know, you. You get creative. You. You're working together. And, hey, let's face it, we all. It's a long day, and we really like to enjoy what we're doing. You know, we spend more time together in the workplace than we do with our family and friends. So I definitely encourage my teams to bring joy, to bring some levity. Levity, you know, as we're working together.

Excellent. I suppose if you're a manager, then bringing joy is going to be part of your responsibility. So do you have any tips or tricks to bring joy to your team? How do you encourage that sense of levity? Yeah. Pamela, do you want to go first, since this was. Since it was your idea.

Yeah, yeah, yeah, no, sure. I think it's how you show up. Right? Like, so for me, as a manager, how do I show up? How do I enter the meeting that we're. Or the project that we're going to do? Like, to make it be fun. Right. So to be creative, even something. As you know, we just started this initiative around data advocacy, and so we were trying to come up with a great name, because one of the things we're doing is, you know, bringing all the data producers, the data consumers together to learn together. And so we wanted to have, like, this weekly session, so we came up with the name Datapalooza. So just saying the name seems like it could be fun, right? So really being creative in that space. And then I think also we start the day with Our standups, you know, especially during the, you know, after we've had a long weekend or whatever, where folks sharing about, you know, what did they do do on the weekend, you know, what happened? And it kind of adds that personalization to the team. We're getting to know each other because I feel that building those relationships are a positive force and actually, you know, achieving results.

Okay. I like these sort of little details, like, just asking your colleagues, like, what. What they did over the weekend. Just showing interest in their lives goes a long way to having a good, happy data team. And yeah, Tarush, since you first mentioned the idea of being fun at work, more fun. Oh, he's gone. I hope I've been okay. Can't answer that question. We'll give Tarush a moment to try and come back. Oh, there we go. Hey. Thought you left us. It's a bad question. Yeah, you were about to tell us how. How you can make work life more fun.

I mean, I think it's like. I think data as a function is a decision support function. Right. Like, it's. And that's in some ways, like, a little bit tricky because it's hard to quantify sort of value of data because for the most part, it, like, facilitates decision support. And I think, like, in my experience, what we've seen is that not getting too caught up in, like, you know, this has to be by, you know, numbers and data. It's one of the avenues on how businesses make decisions. And I think, you know, when we. When I love the idea of, like, bringing joy and really what that means in some ways, like, not taking a. Is not taking yourself too seriously because the numbers can say something. But there is this thing called intuition, and intuition has valid spot in the workplace. So to actually treat people more as sort of colleagues and not as hierarchies, especially because very often data teams are supporting business leaders and product managers and sort of executives. And really it's a sort of dialogue. And as.

As.

As a dialogue, it's a story. And, you know, when you. When you look at it from the perspective of you're playing a video game and this is really, you know, you have a challenge and, like, this is the story which you come out of it. Number one, you become more relatable because people relate with stories. And number two, like, you know, whichever direction you sort of choose to go, this is just a new kind of obstacle inside the sort of video game. I think, like, people who just have this ability to, like, make it fun and make it light in general end up Being the one, the people who experiment more and the ones who ultimately actually do come up with the needle in the haystack discoveries. Does that make sense?

Yeah. So basically, don't be this data robot that just talks numbers all the time. I do like the idea of if there's a problem, you treat it like a video game obstacle and it's just like it's a challenge to be solved. And that attitude can definitely go a long way to making things much more positive. Very cool. All right, so we talked about fun. We should probably talk about the serious stuff now, which is how you increase the productivity of your team as well. That's what a lot of people certainly like. The higher up you go in management, the more important this is. So, yeah. Tarush, do you want to talk me through tips for improving productivity in data teams?

I mean, I think, you know, from.

Experience.

Data teams, there a lot of vanity metrics which teams have because they're the right thing to do. Like, I remember every quarter we would have metrics on like data dictionary and sort of sort of lineage graphs and things like this and all of that. Like, is sort of very sort of fundamentally important. But I think in general, a lot of these projects as standalone projects don't have, like, high chances of success because it'll give you an example of something like sort of data dictionary, right? Like, you know, a company needs a data. Like some executive complains at some point you have this massive project and building a sort of dictionary, and something comes up in a few months later that that sort of dictionary is sort of not up to date anymore. So I find it harder to essentially do projects which don't directly sort of are not directly in the path of sort of sort of off consumption. You know, I think a data dictionary is way more effective when it's built inside the BI tool. So when you're building a dashboard by default, you know, whether it's the sort of hover overs or things like that, where it's actually embedded directly into the application of the product. So I think one thing which we've done in the past is remove every project which is not directly sort of related to a sort of output function. You can't say really roi, because from my experience, sort of data teams really struggle because they're one of the hardest departments to measure roi. But if it's not directly correlated to like, sort of decision support in general, removing it and finding a way to link something back to sort of decision support, something I've found is one of a really good way to increase productivity. Does that make sense?

Yeah, certainly. You want to make sure that every single project the data team's working on, you've got at least a sense of how it's going to benefit some business metric in some way. Otherwise no point in doing it.

Remove everything which is, which doesn't have a direct sort of link with like the business because no one really like if it doesn't affect the business, chances are it might be forgotten a few months from now.

Yeah, certainly as a data scientist, I've definitely had that experience sometimes where I'm like this data is kind of interesting. Let me just have a play around with it. And you can just go down rabbit hole and not necessarily be impacting the business. You just like looking at stuff because it's interesting. But yeah, you want to like try and tie things back to business impact and make sure you're focusing on those areas. All right, Pamela, tips and tricks for improving productivity.

Sure. So I'll add on to what you just mentioned. So for me it's first you need to share the goals, make sure that everyone understands, you know, what we're committed to and then, and also have each of your team members understand how it aligns to our specific organization goals because then they have buy in, they know that they're contributing to the larger initiatives. And then what we've done with our team is really provide the training and the tools. We've also developed mentorship programs so that maybe somebody who's more junior can quickly get up to speed and work along with a peer so that they're, you know, they're driving, they're building out their skills, but then also they're completing the work that is needed quicker. Right. Because they're, they're building out their skills. And then also other things that we've been focusing on is automation. What are we doing today that could be automated? Then also what could be reused? If we look at a data product, sometimes the data product is built for a specific niche, but rather if we added three more pieces to it, it could be reused, thus improving the productivity for the data team. Because then they can train the team that's going to use that data product. Like if it's surfaced in a bi tool that they could train that stakeholder on to be self serve to use that data product themselves. That's how we have seen increasing performance and productivity across our data teams.

Okay, so training people to increase their skills, trying to automate stuff. What was the other one? Oh, reusing stuff from project to project. I like that. 1. And then there was a fourth one.

Mentorship.

Oh, mentorship. Okay, nice.

All right.

And so I'm wondering, is there a difference between, like, the productivity and the impact then? So I think Teresa answer is more focused on how do you impact the business? And Pamela, your answer is more focused on, like, how do you get people to do more things? Are these things you need to worry about separately, or do you worry about them at the same time? Sorry, it's a bit of a thinker, that one. Do you want to take a stab at that?

I think when you want to measure impact, really kind of going back to one of the first things I said, which is this concept of data readiness. What I really want to make sure is that for any business initiative, we have a data readiness metric, as in, do we have clean, structured model data to answer 90% of the questions which pertain to what the success of that business project look like? And, you know, once we have a data readiness metric, we know where, you know, we have bi. We know we can do analytics, we know we can basically implement AI. So from a. I think using the higher goals of the business, as Pamela mentioned at the beginning, but really mapping that back to data readiness, because at that point, you have a really good foundation of being able to actually go measure. And even as the business metrics change, you basically have everything you need because you have this data readiness foundation, which you can then leverage to basically answer all of these questions.

Okay, all right. So right at the start of any project, you're going to try and figure out what is the impact going to be. And so that's the point of the project where you're worrying about impact. And then maybe once you get started into implementation, then you're worrying about, like, how productive can I be, how fast can I be? So that's a sort of later stage thing, I think.

I think metrics always change, right? Like if you have a success metric on the project, fundamentally what data does, like when you see a metric, it's like that makes you actually come up with a new question. And information basically means you ask better questions. And with better questions, you evolve your understanding of the business. And with evolving your understanding of the business, you want to have different metrics. So it's harder to say that these are my initial questions. Go sort of model this out, because that's always going to change. And every time you sort of change your definition of a question and you have to remodel your data, it's a losing battle, because then data is always going to be Playing catch up. And that's what happens with sort of 99% of teams is data is playing catching up. Now, I think what the concept of data readiness is sort of saying is like, hey, you know, the actual definition of something, the semantics of something changes. But I want to have some core models in place. Right. If I'm a business with supply and demand, you know, you want to basically have, you know, some core, sort of some core modeling to basically go talk about your demand set and to go basically go talk about your supply side. These are two sort of data models which, you know, any business with sort of supply and demand would basically have a consumer and basically, you know, inventory. And once you basically have these models in place now, business definitions can change all the time. You don't have to go back all the way to raw data to go back this out. You already have a foundational layer which you build on top of, and that really sets you up to basically iterate very quickly and to also, you know, support and not play sort of constant catch up. Does that make sense?

Yeah, I think that's right. That quite often in most projects, like, the state of the data is always behind where you want it to be. And so you do end up playing catch up. And, yeah, you probably have to figure that out earlier. Excuse me. Sooner rather than later, otherwise you not have that productive team that you want. All right, we need some happy stories. I want you both to share your data success stories, like, anytime you've seen something very cool happen in a data project. Pamela, do you want to take this one first?

Sure. I'll share the story of how I became the director of Data Quality and integrity and the success that our team has had. It's really been amazing. So we had the support of our leadership to support the launch of Max Streaming to ensure we wanted to have, let's say, a startup team that would support the building out quality data. Right. Because ultimately, I think Theresa said it, if you go back to the beginning, your data needs to be pure. So the success that our team had is that we had a very lean team and we worked with the folks who are building the app and the folks who are using it, so our data producers and our data consumers to understand historically. Sorry about that. What was going on. And we found that there was a disconnect. So we built a bridge, what we call the Data Quality Forum, to connect the dots, to connect the two teams to understand. Okay, well, we are going to. We will be using these data attributes downstream to do analytics on them. And so we need them to all be aligned. So let's work with the client engineers to ensure that everyone is aligned on what the data attributes need to be. Really, it was a beautiful thing to watch as the relationships were formed and the quality improved and such that our team built a way to use the data from analyzing where we want, what the bar was for that data and then ultimately putting that using a BI tool and putting in a dashboard to provide a metrics, a scorecard on the data that then all the way back up to the client engineers could use that scorecard to see shift left before we were in a production state. So it's really been a wonderful story that I love sharing. So that's my success story.

That's very cool. And I like that you start off with a small team and then it was about like stakeholder management. It sounds like a lot of this is just getting other teams aligned on like, what con, what constitutes good day, good quality data in order to make sure that, you know, you got something good after it at the end. Yeah. Chatting to other teams, always tricky stuff. But so yeah, that's as not insubstantial win there. I think so. Nice. And Tarush, how about yourself? Have you got any success stories you can talk about?

First of all, that's an awesome story. Thanks for sharing. Yeah, you know, I'm very proud answering the question a slightly different way. I'm very proud of kind of what we're doing in 5X. So, you know, what we've seen over the last few years is that there are like 500 vendors in the data world and like you have 30 different categories. And in some ways all of these vendors are sort of essentially selling car parts. And the analogy is if you walked into a Honda and instead of selling you a Civic, if they sold you an engine and you had to build your own car, that's pretty much like what it means today to go build a platform. And, you know, I'm kind of very excited about the work we've been doing over the last few years on essentially going and stitching together all of these vendors. And, you know, we're now able to basically go to a company and, you know, help them get started with data. In just a matter of, you know, a few days, they're able to actually have, you know, the first versions of sort of these sort of data models and data dashboards built out something which historically would take them, you know, three, four, five, six months. So kind of very proud of the direction which we're going and kind of enabling data teams to become faster, more cost effective and build higher quality stuff off the bat. Does that make sense?

Yeah, I like that. So, yeah, just making other companies data teams more productive by.

Yeah.

Saving them the hassle of building software themselves, I suppose. Yeah. With your car analogy, building kit cars is a very fun but slightly niche hobby and some people just want to buy a car rather than building it themselves. Okay, cool. So we talked about the happy stories we have to the flip side now is like disaster stories. So what do you wish you knew when you started management? Like what, what's your experience been? If you can share any juicy like disaster details, then yeah, please do. If not, just tell us what you wish you knew. Yeah. Tarush, do you want to go first?

I mean this is, I've kind of hinted at this before to some extent, but it's incredibly difficult to go measure ROI as a sort of data team. And I think today, you know, real talk, the data teams are under more pressure than ever before. There's, you know, it's not 2021 where you know, companies have unlimited money and companies are becoming more sort of, more sort of budget conscious on like what are we spending money on? And I think data teams are particularly hit because they're unable to kind of go directly attribute roi. And so I think, you know, one of the things which I don't think we're speaking about enough and you know, kind of I was alluding to with this concept of rise of data generalists of, you know, we don't, you know, need to have four or five sort of different functions inside data. You know, we want to have leaner teams which are more sort of, which are more, you know, equipped to do a lot of cross functional stuff. I think this is one of the, this isn't sort of spoken about as much as it needs to, but I think it's a very, very real concern issue we face in as sort of data leaders today. Does that answer your question?

Yeah. So definitely measuring ROI is incredibly tricky. Like sometimes it's like, okay, you're doing something very close to like the business, like you're helping out a commercial team. You're probably going to be able to notice the effect on revenue or costs or whatever. But if you're doing something like closer to infrastructure, very, very difficult to like tie it to a business metric. So yeah, I can see how that's, that's difficult to measure. Okay, Pamela, what do you wish you knew when you started managing?

Sure. So I think as a young manager there's two aspects that now, you know, in looking back, I would say learning how to delegate well, you know, not take everything on myself to trust in the team that you have. That. That was an area that I definitely needed to do. And then also I learned about building conversation, like building relationships. A lot of times data teams are in specific silos and, you know, like the example I gave of the success story, I think I brought that bridge because of the experience I had when I was a young manager of working more in a silo and not understanding, like, what the right hand or the left hand was doing. So now as a manager, I lead with conversation, like building relationships across data teams so that we can learn from each other. Then another thing that I have been doing more as an experienced manager is providing the leadership, providing the mentorship, but then allowing the people to work independently because you have at least. I have great team members, great colleagues that have a lot of things to bring to the table, and so let them use their creativity to provide the solutions.

Okay, yeah, certainly trusting your team, that's a very important thing. I think certainly this is something every new manager faces. You go from being an individual contributor to managing a team, and you're like, I have to be the best at everything and better than all my teammates to do so. And that's like, you'll just burn out in months and that's it. So, yeah, trusting your team is incredibly important. All right, so we've got a ton of audience questions. I've got one last question for you both, which is what trends are you seeing in the world of data that you're most excited about? Like, what should data managers be looking at? And you're not both allowed to say generative AI. Go on, Tarush. What are you interested in?

I think there are a few. Right. We kind of spoke about, I think, the rise of more lean teams, I think the rise of fully managed platforms which give you everything out of the box. I think if I had to kind of pick one area, which I think is really, really interesting and still probably very, very untapped. So this is not the answer is not. Jenny. I. But it is kind of a variation of that. I call it conversational bi. Where, you know, I think building dashboards is going to become a thing of the past. And if you have this sort of concept of data readiness and if you have this clean, structured model data, then you're probably going to be able to ask, you know, sort of have a conversation and ask questions of, you know, how's business going? What's going up? What's going down. Why is this going down? What do you predict this number is going to be next month from now? And I think, you know, being able to chat, whether it's like Siri or you know, whatever these AI on your phones are called and really just have a conversation or it's on Slack or it's on text message, then, you know, get deep insights into your business. I think that's a super, super cool world. It doesn't work on like, you know, the gen AI way of like taking all the information and compressing it and answering from that. It actually works on very well understood sort of data models. So it's kind of in some ways gen AI technology, but not gen AI mass or data dumps. And I think that is like, I think one of the coolest things which I think we're like you know, six to 18 months away from really, really seeing in production and I think that's going to have massive impacts. You're going to have smaller data teams as a result because you don't need as many BI developers to go build dashboards. And you're also going to have like stakeholders really care because they'll be able to speak with data in whatever language they like speaking. And I don't mean English, French, Latin. I mean, you know, are they more technical? Do they want more of a story? They do, they want predictions? Do they want to actually go look at a table? Whichever way, whichever format you want, you can basically go get a very personalized answer.

Okay, so that first answer, what Lean data teams? That sounds like a whole separate follow up webinar. I'm going to add that, add that to my to do list. But yeah, conversational bi is very cool because you think, well, if I know exactly what I want to see, then maybe a report's best and if I need to interact with it. And traditionally you've used a dashboard and you sort of point and click interface, but actually maybe chatting with the data gives you a bit more freedom. It's a bit more natural for a lot of people. So yeah, I can certainly see how conversational be asking me very important. All right then, before we go to audience questions, Pamela, what trends are you most excited about?

Well, I mean you said not to speak about AI, but I think we went down that path with yeah, we did conversational or Gen I. So I mean I would just tag along with Tarush that the, the resources, let's, let's put it this way for us data professionals is at our fingertips because of all these conversational Tools that weren't there before. Right. And I think that people can learn at an increase speed because of the tools that are there also, like the prompting the, you know, if you're in any tool and you're writing code, it's helping you, hey, you wrote the wrong, you know, the wrong keyword. It's providing that keyword. So I think from a perspective of an individual in the data world, in the data space, be excited, don't be scared, because what it is is that there'll be tools to help you do your job better and more efficiently. And from the perspective of lean teams, hey, we're all there. But there will always be something else that's needed. So maybe it isn't that you need five analytics engineers to build out the data product, but there will be someone else who will, will be needed to provide details on the insights of that data product. So exciting time.

Definitely. Yeah. The level of tooling for data stuff has just been, it's gone through the roof in the last few years. So yeah, life is getting easier. It's good news. So that's a happy note. To end this first portion of the webinar, before we go to audience Q and A, I just want to say we've got some great, great sessions coming up soon. So the next two sessions are both Euro 2024 related. So for soccer fans, we've got a Power BI session on Friday and then a SQL session next Tuesday. Then next Thursday I am doing a webinar on creating GPT AI assistants using the function calling API. So that's going to be a lot of fun. Please do use the QR code to register for those. All right, so with that, let's go to some audience questions. All right, we might run over a little bit because you got so many great questions. Well done, audience. All right, so Nilabja asks, can you tell me about your daily responsibilities as Director of Data Quality and integrity? What do you actually do? This one's for you, Pamela.

Okay, great. It's a great question. So every day we have data streaming in. So we have built pipelines and are utilizing different tools to ensure that the quality of data is a high bar. So we work with our stakeholders. We have scorecards, right? Because, well, we have a product, we release that product, we can have regression on the data. An engineer makes a change that then impacts something else in the product. The data quality tooling that we have built will help unearth these issues. Then the team will work with the engineers to remediate. We actually started this. I Call. You know, you hear smart in the industry, but I created my own kind of smart. And what our team is doing is trying to simplify, monitor, automate, remediate and be transparent around data. So that's what our data quality integrity team does on a day to day basis.

Okay, so not just. Yeah, not just fixing issues. It's like making sure people understand them as well. I like that. All right, next question comes from Tobias saying, what tech stack do you use in your companies? Tarush, do you want to go first on that?

I mean, we are a data platform company, so we run, you know, we work on top of Snowflake as a warehouse for our ingestion product. We use our own. That's 5x ingestion. We use our own modeling and orchestration tool which is built on top of DBT and Daxter. We have our own BI tool which is built on top of of Superset. So, you know, we're maybe a little bit biased, but we're using a lot of. We're sort of dog fooding our own. Sort of. We are dog fooding our own products at 5x.

Okay, that makes sense that you use 5x at 5x. I like that. Be slightly worrying if you didn't, I suppose. All right, Pamela, what's the tech stack at wbd?

Yeah, so we're using all the major data vendors, as Tarush said, Snowflake databricks and a number of BI tools. We're a large organization and there's many data teams across the organization. We are working on streamlining some of that, but yeah, those are the tools and tech stack we use.

Okay. So yeah, I suppose this seems to be a common thing that as organizations get bigger, you get different teams using different technology and at some point you end up basically using everything. All right, next question from Danielle. Is the organization changed over time? How do you ensure that your team keeps up those changes? Okay, change management, another big topic. All right, we're definitely running over a few minutes if we cover this. Yeah. Pamela, do you want to go first? How do you do change management for data teams?

Oh, yeah, sure. I mean, this is a constant issue across the entire organization. Right. So first of all, we go back to the goals. Right. So if our business strategy changes, ultimately we need to look at what's in our line for the next quarter, what work we've already set, and then we may need to revamp our work products of what we're going to do for the next quarter based on our business strategy, and then we meet together as a Larger data organization to ensure that each individual team like data quality, the data platform team, the infrastructure team, the analytics pillars are all focused on this specific next quarter. So we definitely revamp consistently. You know, as soon as we make a change, like say we're not going to, we're going to launch in a new country that we didn't plan on launching until next year, but now we're launching it. So everyone across the data space works to revamp the specific goals within their teams.

Okay. All right, I think we'll just ask questions to one of you from now on, just so we don't run too far over. But yeah, I like the idea of just changing. I was so hoping the answer is going to be train your whole team using data camp and then they'll be awesome to date with their skills. All right, next question from Mikey. Are professional data certifications relevant and useful in industry? Do you use certifications at all when you're hiring data people? Either of you?

Yeah, Pamela.

Pamela, you still left. Yeah. Do you make use of any certifications or qualifications when you trying to hire people? How important are those?

I mean, I could go, they're nice to have. But when we're hiring people, you know, we do go through tech vetting, you know, with the tech, with our engineering team. So generally through the conversation and the code reviews, we'll find out if that person actually has that specific. Because you can have a certification from some time ago and you know, and not have that hands on experience that's really needed for the role that you're interviewing for. Yeah.

So certifications are more useful earlier in the hiring process for like, is this person worth that first conversation?

Exactly.

Then you need to demonstrate your skills during the hiring process. So less useful later on in the hiring stage. Okay, let's go for this one from Ivan. Okay, so for software development GA, there's a common ratio of developers to testers, like 3 to 1. Is there an equivalent ratio of data engineers to data analysts to data scientists? Yeah. How does the split go? I think this is going to be company specific, but do you want to talk me through it, either of you? Do you have an opinion on ratios of different roles?

I think initially when you're just getting started, fours to twos to one. So four data engineers for every two analysts for every one scientist. And at scale, at maturity, it's more like one is the one is to one. So initially you need a lot more data engineers, which makes sense because you're building more pipelines, you need to model your data. But Again, there's no point having a data scientist if your data is not clean, structured model. So you need a lot more of those. And again, as you mature, it's always going to be one is to one is to one, because you'll always need data engineers to model new data to update your models. So it basically sort of starts to even out as you mature. Again, with the world moving towards more data generalists. You know, I think data engineers, data analysts, data scientists, that role is in general sort of blending. So the answer is one.

Wonderful. Okay, so I like the idea that you have a lot of data engineers at the start and then it gradually shifts more towards the analytics side of things at the end. All right, so one last question before we wrap up. This comes from Rita. So in a data team, do you need all those different skills you mentioned, or is it better to have specialists within the team? So do you want to have lots of generalists or lots of specialists with different areas of expertise? Do you have a preference of one over the other? Either of you?

Yeah, I would say that there's a need for the data person to have a large set of skills, really. It's not that they can only have soft skills. They really need to have. Especially in this day and age, I could say, you know, years ago you had specific specialists that maybe were only doing the coding or building the, you know, sort of back end data model or the, you know, the model in the data tool. But today, really the need is, is for them to have a vast set of skills so that they can work independently and, you know, solve a solution faster.

So, yeah, all right, super. I like that you do need a few, quite a few, just sort of general skills. But yeah, really the focus is on making sure that people can solve things quickly. All right, you know, we're well over time now, so we have to wrap up, so I'd like to say thank you so much to Roots. Thank you. So, Pablo, really, really good discussion there. I very much enjoyed it. All right. And yeah, thank you to Rhys for moderating. Thank you to everyone who asked questions. Sorry we didn't get to them all, but yeah, lots of great questions there. Thank you to everyone who showed up today.