DataFramed
DataFramed

Episode · 6 months ago

#97 How Salesforce Created a High-Impact Data Science Organization

ABOUT THIS EPISODE

Anjali Samani, Director of Data Science & Data Intelligence at Salesforce, joins the show to discuss what it takes to become a mature data organization and how to build an impactful, diverse data team. As a data leader with over 15 years of experience, Anjali is an expert at assessing and deriving maximum value out of data, implementing long-term and short-term strategies that directly enable positive business outcomes, and how you can do the same.

You will learn the hallmarks of a mature data organization, how to measure ROI on data initiatives, how Salesforce implements its data science function, and how you can utilize strong relationships to develop trust with internal stakeholders and your data team.

You're listening to data framed, a podcast by data camp. In this show, you'll hear all the latest trends and insights in data science. Whether you're just getting started in your data career or you're a data leader looking to scale data driven decisions in your organization. Join us for in depth discussions with data and analytics leaders at the forefront of the data revolution. Let's dive right in. Hello everyone, this is a dull data science educator and evangelists a data camp. One of the things we always think about on the podcast is how to make a data team impactful, where data teams go beyond hype and promises they can all keep, but become an actual strategic asset that accelerates the organization's ability to provide value. To do this, data teams need to balance rigger business, impact, relationship and more, and this is why I'm so excited to have a jelly some money on today's podcast. And Jelly is the director of data science and data intelligence at salesforce. She's a senior data science leader with over fifteen years of experience and multinational corporations, startups and public sector organizations in the US and the UK. She's led her fair share of impactful data teams, and she brought it in spades in today's episode. Throughout our chat we talk about how she defines an impactful data team, how to align data science projects with business value, balancing rigor with speed as a data scientist, the importance of data culture, how to manage stakeholders and much, much more. If you enjoyed this episode, make sure to rate, comment and subscribe, but only if you liked it. Now on to today's episode. Angeli, it's great to have you on the show. Thank you for having me that. It's great to be here. I'm really excited to speak with you about your experience leading data teams, how you define a mature data science organization and how to build an impactful, diverse team. But beforehand, can you give us a bit of a run about yourself and what got you into the data space? Sure, so. I work at salesforce on a team called data science applications, which is part of a broader organization called data intelligence. Data intelligence is a very diverse team comprising of four sub teams, one of which is data science applications team. So there's strategy and growth team, which helps the general managers of our product lines think through product strategy, figure out what kinds of metrics they should be using, how to build out framework to drive strategy for their individual business units. Then there's data science engineering. They take care of our data platforms and pipelines so that data scientists can actually do their work. Then we have a visualization and enablement team who build out a lot of our interfaces for our data science products and help our users and stakeholders interact. With the applications team, so that team builds out applications centered on AI and machine learning. We develop APPS for internal stakeholders at salesforce to help them make better decisions. Comprises of product managers, data scientists and data engineers. So within that data science applications team, I lead the US a data science team, which comprises of data scientists and senior data scientists. That's really great and an awesome aspect of hosting this podcast is that I get to talk to data leaders such as yourself, who have been really leading the way when it comes to making data science impactful within the organizations. You know, you've worked the organizations with really maature data teams, and this is especially true it selfforce in your current role. I'd love it if you can break down what you think is the hallmarks of a mature data science organization. Yeah, sure, so. I think if I had to summarize it in one sentence, I would say that a mature data organization is one that can both consistently and efficiently or sustainably derive value out of its data. So when you break that...

...down, you know why we think about consistencies, that a lot of organizations are very good at spinning up one of initiatives to derive value from their data. But that doesn't define maturity if you're able to do it very consistently and in a way that is both efficient and sustainable. So what do we mean by that? Efficiency to me, is about driving the costs down over time. A lot of the times when teams first start out in data science, you know they're not really fully set up, they're still trying to find their feet and if you work out the cost of generating those insights, it can sometimes be quite high because there's a lot of investment that's going into acquiring the data, setting up the text stack, hiring the people. But over time, as the organization matures, then the costs should be going down and the value that they derive out of data should be going up. And then by sustainability t I mean how is the team extracting that value right? Is it always a fire drill or do you have good processes and technology in place so that it's running like a well wild machine? So when I break that down, it typically comes down to people, processes and technology, and by technology I mean both data and the actual text stag. So a mature data science organization or Mature Data Organization is one where data is a first class citizen. It's not an afterthought or by product of everything else. The leadership is intentional about data. Data is a strategic asset and it is treated as such. So there's there's a lot of thinking and intentionality that goes behind what data is collected, how it's collected, how it's processed, why is collected, because that also impacts downstream pusses. Depending on the purpose that a data set is being collected for, it may naturally introduce certain biases or certain nuances within that data, and if you don't understand why you're doing it and communicate that clearly to the data scientists, then you may end up with misleading insights or outcomes. So they have all these strategies in place. There is the text tack in place and the technology investments are also very intentional. Right, the data needs to be connected with the business objectives and the strategy, which is owned by the CEO s office, but the investments in the data and technology also needs to trickle down from the top. That's a sort of the technology side of things. Right. So there's the data and how you collected. A lot of times when organizations for a start out, they'll start with I have all this data, I have lots of big data. What can I do with it? And that's a great place to start, but it's also a hallmark of a very sort of night young organization when when you think about it in data maturity terms, then there's the text act. So with that there's, you know, all the technology that goes into collecting, organizing and persisting that data. There is also technology that enables the people who are using the data, and that could be your expert users like your data scientists and engineers, and they could also be some of the downstream consumers of those data products. So what kinds of dashboarding tool psting in? How are your users able to interact with your data products? How are you enabling your data scientists to access the data and deploy models into production? So that's the technology and data side of things. Then there's the people's side of things, which is always the most complicated and the most difficult one. This is about the whole culture of the organization as well, and that sort of starts at the top with the leadership, with the exact leadership, but at more localized level it's about...

...good hiring processes. It's about knowing what the organization means and what good looks like within each of those roles. And those roles will also vary depending on where in its growth stage of businesses, where it's at in its maturity levels. As an example, when the organization is still very early on in its journey, they may require a lot of generalists, so you know they can hire a few people who can do a whole bunch of different things and they can really get the systems up and running very fast. They don't necessarily specialists. But as the organization matures, then you know, you start to see the need for folks who specialized in engineering or in data science or even specific areas within data science, so there's understanding of what roles are needed and how to look for the right people. Then, once you have those people, it's about supporting them in the right way, providing them a clear career path, providing them with the right mentorship so that they continue to grow and develop. A lot of organizations today offer education stipends, which is a really great idea, because the data science is a field that's evolving at such a pace that you you have to constantly be learning and keeping yourself updated. Within that people bucket, it's all about the data literacy and you know, having an organization where there are high levels of data literacy, not just the data scientists and engineers or the data specialists who are highly data literate. Data informs decisions and there is this culture of challenging assumptions, of views and beliefs if they're not supported by data. People are not so attached to views and assumptions that, you know, if data challenges it, they struggle to change their mind and this is a really hard thing to accomplish because it's such a big cultural shift. This is what keeps everything running like a well oil machine. All three of these data processes and people are intricately connected with people at the center of all of these things. If you don't have good processes, then you may not be able to derive the value that you need out of your data science investments. You may have a fantastic team of data scientists who are constantly innovating and coming up with new products and new insights, but if you don't have the processes to take the innovation from the lab to production in a way that it impacts the bottom line and gives you that competitive advantage without burning out your team, then you've really failed at deriving value out of those investments. So the processes are around adopting a lot of the best practices within data science, within engineering, within product development. It's about having that culture of experimentation, even at the enterprise level, setting up the incentives correctly so that it's okay to fail as long as it's not catastrophically. You're not incentivized to always look successful to come up with the positive kinds of insights. So the processes are about putting the right things in place, starting with the leadership and then trickling all the way down to your individual data scientists. So this is how I think about maturity within a data science or core data or that's such a great holistic answer and there's definitely a lot to unpack here. So I want to really focus in on the people component throughout the remainder of the episode. And you mentioned there's the data literacy aspect for the broader organization, is also the specialists within the organization, the data science teams. So let's start with the data science team. One thing I've seen you break down really well is the importance of always connecting the data science teams priorities to the solutions they developed with the business objectives, and this has multiple dimensions. Something that you typle is the three hours of data science. Do you mind sharing your thinking or framework on the considerations data teams should make and designing data systems that have business...

...impact? Yeah, I mean, in an ideal world, everything you will should have a business impact, right, because otherwise what's the point of doing it? But of course that's not realistic, especially in the data science world, where so much of it is is very experimental, it's very iterative, it can be very time consuming and there's always more you can do. You can spend forever working on a problem. So then what it comes down to is how is this thing going to be used and what impact is it going to have on the business, because that really determines where you land on what I call the risk versus time to ship curve. So if you imagine a pair of axes where you have on the x axis you have the time to ship and on the Y axis you have the risk that the product carries, then it's an upward sloping line going from left to right, and in the bottom left corner you have things that are very low risk and take very little time, and then in the top right corner is high risk analyzes or data science investments that also take a long time to develop, and then you have everything in between. If you're in the bottom left corner, then it's analyzes or data science work that is low cost, that is low risk, but typically low impact as well. So this could be things like engagement initiatives right where it's all about volume. You're producing a new sound bite every other day. So even if you get a few things wrong, it's not very rigorous, then the impact of that is pretty low. It may upset a few people, it may cause a bit of an uproar on the one day, but tomorrow when you release the new thing, people are going to forget about it. Then they will be talking about something else. There is very little brigger that you may want to inject. I mean, in an ideal world you want to be rigorous about all the work that you do right all your analyzes. You want to make them reproducible at the very least. But if this is something that time and cost considerations don't allow, then in that bottom left corner you don't have to worry too much about it. Then you might move a little bit further along to the right and that's where you may have your insights that you might might produce on a on some kind of a regular cadence. These take a little bit longer to produce because you need to think about the business context a little bit more, you need to do some deeper level analyzes and you may need to reproduce them every so often because you may want to check whether those insights still hold. So there you may want to definitely think about the rigor a little bit more and the reproducibility side of things. But if it's not something that you're expecting to run on run very frequently, then maybe repeatability and replicability are not big considerations. You move a little bit further along the curve and then you have activities that are more medium risk medium impact. They're more mature products, dashboards, reports that are being generated on a regular basis and their reproducibility and repeatability become very important, because it's all about efficiency. If it's something that you're doing every month, it's not requiring any new thinking and the people who are working on it are not necessarily learning and growing from those activities. But these are important because they keep the lights on. So with those things you want to automate it, you want to make sure that it's very efficient. It's it takes very little time to run those, so that's where you need to make a little bit more investments. So you're moving to the right on that time to ship curve and you're moving a little bit higher in terms of the risk. You move a little bit further along and you have a lot of mission critical activities where you know if if you get things wrong, there could be huge implications in terms of maybe there's legal risk, maybe there's regulatory risk, maybe there's a huge reputation risk and brand risk that's associated with getting those things wrong. There you want to act a lot more rigor and leadership needs to understand that these are some...

...pretty big risks and pushing the team to ship very quickly when it may not be possible is maybe not the right thing to do. And then when you go at the very top, you have very low volume activities and it could be those one of amazing products, you know, once in a wild kind of products that change the way things have done in a particular industry, that changed the thinking in a particular industry, and there the risks are super high. Right those could be catastrophic risks where it could lead to loss of life or it could lead to certain other major implications. That's how I think about it. Your level of sophistication increases as you go up the curve and so you need to make a lot more investments. You need to think about you know how rigorous your analyses are. You know how your sting these things. If there's likely to be some regulatory or audits that are going to be conducted, how are you persisting your data, your models, your analyzes, all of these things. I really think about it in those terms. And then there's also the timing aspect of it right. So there are times when something might take a long time and if you need to extend that deadline by a week or two weeks or whatever it is, it may just mean that the launch of the product is delayed or shipping is delayed and it's costly, but it's not an existential risk. Almost there are other situations where it's very binary, where if you don't release by a certain date because there is a deadline, then you've missed that boat and then you have to again kind of balance this need for rigor and the time to ship very finely. So it's always a balancing act and it's about taking calculated risks. It's about thinking what are the risks, how likely is this to occur or what is the impact? Are there any mitigations that I can I can put in place? So that's really how I think about it. I think about it in terms of the risk and the impact versus the time and the cost of all of those things. That's really great. And following up here on the rigor and how do you approach prioritization? You know, as a data leader, how do you ensure that you're baking in rigor and why, describing here with the team's process, while also maintaining business priorities and making sure that you'll be able to move fast and that you're able to ship features fast. In my view, there's a certain level of rigor that I think should be injected in all activities. A lot of it comes down to process. So to my mind, if you don't have rigor in your work and analyzes, then at best you may not get enough value out of your data science initiatives. At worst, you could make an incorrect decision, which can potentially be catastrophic. It may put the organization out of business. So my opinion is that Riggor is very important to actually derive that value out of data science initiatives, and it's important to think about it again in terms of risks. Right. So, all else being equal, you want both rigor and speed, because the business always needs speed. They need everything yesterday, because time is money and the clock is always ticking. If you have the right processes in place, then it becomes very easy. So it's a little bit like when you're learning to code. Initially it's really hard because you have all these things to follow and you have to think differently, but once it becomes a habit to always make sure that your your code is well tested, making sure that are reviewed. There's a tech review, there's a code review, you have these feedback loops in place, there are checks and balances along the way. Then Riggor is just a very natural part of how data science is done. I think unless you're on the very left of that curve that I just described, where Riggor isn't that...

...portant, then taking a very scientific approach is, to my mind, always the right answer, and I think a lot of organizations forget that. There is a really strong bias towards speed, which is understandable, but it can come at the cost of making the right decision and I have seen organizations spend millions upon millions pursuing things that were actually based on incorrect initial analyzes and it was because nobody reviewed it, because there weren't the right processes in place and nobody asked the right questions. And so there's always this tension between balancing the business priorities and needs with the need for rigor, and I think a lot of it comes down to asking the right questions. You need to ask things like if I don't inject the level of rigor, the right level of rigor, into this analysis. What are the risk right so that whole risk, probability of the risk, what is the impact and how can I mitigate it? And I think helping the business leaders or stakeholders see that kind of analysis to say hey, I understand the need for speed, but here is what can go wrong if we don't do this right. I think that's usually a really critical piece of building those relationships, keeping those lines of communication open and also, you know, as a data scientists, sort of knowing when it's time to go really deep and when it's time to come up for air and kind of say, okay, this isn't the right place to stop given the risks and given the time sensitivities of these things. So it's there's no short or easy answer to how you do these things. It's always a little bit of an art. It's a bit of a fine balancing act. I love that answer and especially showcase saying the risk here to business stakeholders. We really value speed, but the costs of cutting corners because of speed can be so massive here when not applying rigor. One of the really important things in this aspect is also setting up right incentives for data scientists, because if there is always this bias towards speed and biased towards producing what I call positive insights, rather than being able to say hey, this big hypothesis that we have or this big data set that we've just invested a lot of money and actually there's very little value coming out of it. But that takes a lot of come from, a lot of courage, a lot of integrity to go and say that to senior leadership and I think often the incentives are set up in such a way that people don't do that. With data scientists will sacrifice rigor for speed, because there is this culture in some organizations where you know somebody who can get the insights very quickly, they're always recognized and rewarded, rather than somebody who's who's done a mouth or analysis and actually comes back and says, Hey, I don't think that there's enough value in this. Something that's a positive insight is always far more exciting for the leadership. There's there's a little bit of educating that needs to happen on the leadership side as well to set up the right culture and incentives. You could agree more so we'll expand on that and the day literacy section. Maybe something mature data teams often time do really well is the ability to be able to measure the Arrow I of the data team's outputs. How do you go about measuring the value and R I for a specific data science initiative and how does this go into your prioritization process? Yeah, that's a really great question. It's it's something that's very close to my heart. So I think that data science exists within a business and like any other investment that a business might make, you need to do that analysis. Is this investment giving me enough return? So it's it's one of the most important considerations in my mind, when you're thinking about whether or not to invest both time and data science and technology resources into any kind of data science initiative. And this isn't just a new initiative that you might be starting...

...from scratch. It could be something like, oh, model x has, I don't know, eighty percent accuracy. Stakeholders are asking for you to increase the accuracy from eighty to or because that would really help them to increase the sales or in some other cost savings. And in principle that sounds like a great idea because of course this is going to help us to improve the bottom line. Why should we not do it? But going from that accuracy might actually take you an entire team of data scientists and it may take six months to to get there, because it might be a very complex problem space. When you calculate the cost of even something as simple as model improvement on an existing initiative, which people often don't do, you may realize that actually the improvement in sales or revenue that that model improvement will give doesn't actually offset the investment that's required, or it may offset it over a much longer period than what you're expecting. Measuring that R I is super important. So how do you do that? Right? So there's the cost of the initiative and then there's the value you get from it. The cost pieces is relatively easy, because compute costs are really easy to get. The cost of human resources is again very easy to get. How many people are working on it, how much time is being spent on it and what is the salary of those people? Right? So that's a very simple calculation. The value piece is much harder and that's why a lot of organizations don't really do it. They really shy away from quantifying the value that they're getting out of a data science investment. It's always possible to start with how the product is going to be used and tying it back to some kind of quantifiable metric or benefit. The obvious ones are increase in sales and revenue and cost saved or how much time is being saved or some kind of other operational metric. Now, these things aren't always easy to measure. A lot of the processes, day to day processes and even decision making processes. So much of it is very subtle and a lot of it is muscle memory and it's a lot of mental models, getting people to stop and think about how long is it taking the versus how long it took me before I had this product, or how long would it take me if suddenly somebody switched the lights off on this product? These are really hard things to get people to do and that's one of the reasons why, you know, a success of data science investments really depends on that culture of the organization and these things have to come drop down data scientists who's developing these things may not be able to go to a senior decision maker and say hey, can you keep a track of how long it takes you to do certain things? You can build your your tools in a way that it may track the journey of the user through the product or how much time they're spending navigating through your product. But again, this requires a lot of thoughtfulness ahead of time and this is often done for external products but not for internal products. So internally it's always very difficult to to measure that value. But you know, even if you can track things like the number of decisions that are powered by this product or this inside or what kind of decision it is, then that, to my mind, is is very valuable, and more so than just sending out a survey and getting that qualitative feedback. That's very important, don't get me wrong, but it doesn't necessarily help you get to that R O I. A lot of it is about asking the right questions and really pushing the stakeholders on that. So an example might be, okay, this tool helps me to make a better estimates of how much I'm going to sell...

...this quarter. Okay, why is that important? Oh, because it may help me to understand where I need to focus. Okay, why is that important? Or what happens if you don't have that information. What is the cost of focusing on the wrong areas? You have to really keep digging a lot, and this isn't always easy, or it's not always welcome either, because people don't often have time. So it's a tricky one to navigate, but it's definitely possible to do it and it should be done. And then coming to the prioritization part of it, oftentimes there is this kind of bias towards making things very sensational. Right, so insights can be very interesting, they can be mind blowing and you can really sensationalize them, but if there's no actionability coming out of it, then to my mind it's just a fun fact and should not be prioritized over something that is maybe less sensational but more impact for but again, this is a cultural thing and it requires a lot of push from the leadership to focus on the right things. In reality, a lot of other things come into play. WHO's making the request? Is it coming from the CEO or is it coming from someone much further down the chain? What is the likely adoption of this product? You know, who else in the company is it going to impact? Are Those people the people you want to get in front of and you want to get your product in front of. So there's all these other you know, sort of the human side of things that go into the prioritization decision. But if you take that out, then to my mind it's always about the impact and how much it's helping the business to achieve its goals and objectives. That's really great and I love that last point on sensationalizing. Certain insights kind of mirrors how we think about data science and AI in the public as well, like, for example, breathtaking research results that are really important, you know, such as, you know, an AI plane go right, I would argue like a customer churn model is much more useful for an organization, for example, then something that as sophisticated, right, yeah, and that's whole culture of sensationalization. Also incentivizes people in the wrong way. Like I was saying earlier, people may want to not follow all the best practices when it comes to how you're training your model, so how you're even selecting the data for your training or validation or testing. And at one level it can lead the organization to make suboptimal decisions, but at another level it also sets the wrong expectations of what data science or ai or machine learning can do, and not just within the organization but also more broadly among the general public. And that can go two ways. Right, that can cause a lot of excitement, but it can also cause a lot of fear and I think as a community may often do ourselves to service by sensationalizing the wrong things. M You see it a lot, especially today in the a G. I talk with gupt three, Dolly two, etcetera. Like you are highly great models right, but at the same time we need to have temperate expectations, to a curning ex down where the field is headed and how we think about ai in the future. And of course, having a high impact data science team also means scaling data teams and organizing them. I'd love to Segue in. What you've seen is a great way to organize data teams for impact. Some organizations have a centralized data team, other organizations have more of an embedded model. Which model did you find most effective for building high impact data teams? It really depends on where your organization is at in terms of maturity and and its means. There's no kind of one size fits all kind of a solution. So small organizations startups. They often start and if the organization is small, then stay with very centralized teams that do everything. So they touch all products, all systems, they do end to end development, they're very close to the front end, the back end, the customers, and in terms of the skill set, you're looking very much for the bread rather than necessarily the depth, because often...

...they're not required to, they don't really have the time to go into a lot of in depth work. As the organization grows and matures, then the centralized team tends to start splitting into squads or sub teams that focus on a very particular product or area of the business. So they begin to specialize and at that point that they become embedded within a business function, and that embedded model makes a lot more sense. So most medium to large organizations that engage in meaningful data science of work will tend more towards this model. Personally, I believe that after a certain point a hybrid model works really well, and so you want a combination of both a central data team and then a number of embedded teams. So the central data science team would own all things related to the actual data, so the data catalogings to ship some level of logging the metadata and analyzing some of that. They would own a lot of the data quality and observe ability of initiatives, documentation and data lineage tracking and all of those things. They also do very different kind of data science work, so they might look at things like entity resolution, because they've got a lot of different data sets coming from all over the place, internally and externally. They may be engaged in building knowledge graphs which then these more functional teams can leverage to draw insights. They may be working on things like a normally detection to understand what kinds of data cleaning might need to be applied, what is the right kind of transformation to apply and what's the right level of aggregation and things like that. And they need to be able to do all of these things at scale because they look after the entire organization's data. They maintain that inventory. They also own things like when is it trying to deprecate a certain data set, or what's going to replace it, or how do you persist some of these things. Then you have these more embedded teams and they do very different kinds of data science work. They leverage or build on what these centralized teams are doing. So you know, they would specialize in specific areas of the business or support different business areas. It could be something like sales or marketing or finance, it could be in customer success. So for these teams, you know, they don't really need to know how their particular subset of data connects maybe to everything else in the organization. They have a narrow focus and the business context and the specific problem that they're trying to solve might be a lot more important. So a lot of their work may be a little bit more tactical rather than strategic, which is owned by this more centralized team. which model works well for the organization again depends on the size, depends on the resources and also if there is enough drive from the leadership to create this more centralized organization, because that is a huge investment in terms of data, in terms of people, in terms of technology, and if you're not already moving towards that model then there's a lot of political and people related matters that also need to be considered. But personally I think that, beyond a certain size of an organization, that is a model that that works best that's really great and I completely agree with the hybrid model approach. We've seen a lot as well and like really mature data teams across the spectrum. So we talked a lot throughout the episode about the data team itself, from the People Component. I want to expand it to outside of the data team and I want to start off with the interaction between the data team and the rest of the organization. Collaboration with business teams is super important because ultimately, data science teams serve the business teams themselves. What are ways you've been able to develop trust from your business partners with the data team? It's all about relationships. Right whenever there's people will involved, it's all about the relationships. You...

...may build the most amazing, cool data science product, but if you're if you don't have the right relationships, if you're not speaking to the right people, it may never get adopted and it may never see the light of day. So it's really about the relationships you build. It's about having that empathy for your users, understanding what their pain points are and solving for those rather than doing it the other way around, which I also see a lot of teams and organizations do where they will go and build this amazing product and then try and sell it to the customers and say hey, you know, you should really do this, and they're like, we don't need it. You know, what we have works absolutely fine. We don't need this very cool product that is very complex to understand, will take us a long time to onboard and there's a lot of friction there. Really understanding what your users need, what pain points are, is is super important. It's also about how responsive you are to their needs. Now, by that I don't mean that you give them everything you want, you know, because they may go away and read about this very sensational cool thing that somebody has done and they say, Oh, I want one of those, but that's not what they need. It's going to be a huge burden on the data scientists and it's going to drive very little or no value. Potentially. It's about understanding what it is that they're trying to accomplish by getting that really cool thing. What is the actual job to be done, the problem to be solved, and addressing those needs, and it's enabling your users to get the most value out of what you're giving them. A lot of trust also comes from educating your stakeholders, speaking their language and not really trying to drown them and all the data science jargon and all the very technical language and complexities of your models and analyzes. If they're interested in that thing and if they're technically very capable, sure go down that road, but if they're not, then be mindful of that. Speak Their language, show them how it's going to improve their processes or how it's going to make their lives better. It's about setting and managing the expectations as well. You know, don't promise them that you can solve all their problems or get a very high accuracy on your predictions if you're not going to be able to do that because you don't have the right data or you don't have enough data. So, you know, really being very transparent about these things and saying hey, but here's what is possible and here's what isn't. This is what you will be able to do and here's what you won't be able to do, but we can give you some of these other things that can make your life better. It may not be a cool AI solution, but a dashboard might be all you need. It's about having those open and honest conversations. It's about a lot of transparency as well, you know, really helping them to understand where some of these numbers are coming from. So, you know, a lot of explainability within within your models and outputs. Say Hey, I think this is what the forecast is going to be this month or this is how much I forecast the sales are going to be this month and these are the main drivers behind it, so that they know what's driving those numbers, but also what they can do to change them. If you know what the drivers are, if you know what levers you can pull, then that drives a lot more actionability and when they see those results and when they see how the product is actually impacting the business, then I think that can help you to earn a lot of that trust. That's really great. And speaking here on the communication between both stakeholders, how important do you find data culture or data literacy when enabling business stakeholders to become more effective partners for the data team? And should the data team invest in the data culture of the remainder of the organization and data culture? Is Everything right? It's you know, if there isn't enough data culture or literacy, then you're talking to different languages and no matter how well intentioned, things may not land...

...in the way that that you hope. If you have a data literate stakeholder, then you know they will be a far more engaged informed partner versus somebody was very passive or overwhelmed by what you're giving them because they're not accustomed to working in that way, they're not accustomed to making their decisions in that way. And then at the sort of other end of the spectrum is a very kind of disengage uninterested stakeholder. They won't say no, this is really terrible, I don't like it, I don't want it. They will also not say yeah, this is wonderful, I'm going to use it and all that. They'll just be like yeah, sure, whatever, and then you know, it goes into this black hole never to see the light of day. That's what the difference is between having a very engaged and educated or a data literate but stakeholder versus not. When you have a data literate business partner, you can actually co create. They will come to you with problems. It creates interesting work for the data scientists and it also addresses their pain points and there is this really great feedback loop. There is a really great virtuals circle where business is getting value, data scientists are engaged, they're doing amazing work and those synergies are super important with with keeping everyone engaged and interested. That burden shouldn't be on the data scientists alone. They cannot change by themselves the culture of the organization. There needs to be a lot of executive sponsorship. A lot of these things need to start at the top. The data scientists definitely need to invest that time in building that data science brand, in engaging with their stakeholders and helping to educate them, but it cannot be the responsibility of those data scientists alone. It has to come from the leadership. I couldn't agree more. Finally, as we close out, actually, do you have any final call to actions before we wrap up to day? Yes, so, if you are a non data professional, definitely become data and it teach your kids how to be data literate and ask important questions of the data and the world around them. Back in the day you could say seeing is believing. You can no longer say that. There's deep wakes, there's all kinds of stuff and if you're not if you're not aware of these things and if you're not asking the right questions of the data and of what you're being fed by the media, it could be something that's oversensationalized. Then you're really doing yourself and the future generations a disservice. And if you are a data professional, if you are a data scientist, then make sure that you are picking up all the right skills, and by that I don't mean the latest and greatest deep learning models and everything you know. Sure, do those things, but if your fundamentals are not in place, you're going to struggle to add value and get your basics right. Pick up emily skills, because those are super important, particularly if you want to go into roles that are not r and d kind of roles that have business impact, because if you're if you don't have the right engineering skills, you're not going to take your ideas and models into production and drive that value. So learn what the best practices are from Software Engineering, from product development, from data science, and really build those skills as well in addition to your technical skills. Those would be my two action that's awesome. Thank you so much, Angelie, for coming on data friend. Of course. Thank you so much for having me that it's been a lot of fun. You've been listening to data framed, a podcast by data camp. Keep connected with us by subscribing to the show in your favorite podcast player. Please give us a rating, leave a comment and share episodes you love. That helps us keep delivering insights into all things data. Thanks for listening. Until next time,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (121)