#48 Managing Data Science Teams

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com.

In this episode of Data Framed, a Data Camp podcast, I'm speaking with Angela Basa about managing data science teams. Angela is Director of Data Science at iRobot, where she leads the team through development of machine learning algorithms, sentiment analysis and anomaly detection processes. IRobot are the makers of consumer robots that we all know and love, like the Roomba and the Brava, which are respectively, a robotic vacuum cleaner and a robotic mop. Angela will talk about how to get into data science management, the most important strategies to ensure that your data science team delivers value to the organization, how to hire data scientists and key points to consider as your data science team grows over time, in addition to the types of trade offs you need to make as a data science manager and how you make the right ones. Along the way, we'll see why a former marine biologist has the skills and ways of thinking to be a super data scientist at a company like iRobot and will also see the importance of throwing data analysis parties. I'm Hugo Baun Anderson, a Data Scientist at DataCamp and this is Data Framed. Welcome to Data Framed, a weekly Data Camp podcast exploring what data science looks like on the ground for working data scientists and what problems it can solve. I'm your host, Hugo Bown Anderson. You can follow me on Twitter Hugo Bown and Data Camp at datacamp. You can find all our episodes and show notes@datacamp.com community podcast before we get started, I just wanted to let you all know that we have something new for our podcast listeners this week. A trial of Data Camp for Business. Now, what is Data Camp for Business? That's basically all the content you get as an individual subscriber, plus tons of amazing tools for you and your colleagues to learn data science skills together. All you need to do is email salesatacamp.com with the subject podcast and you can redeem A free two week trial of datacamp for you and up to 25 of your colleagues. That's salesatacamp.com with the subject podcast and you can Redeem A free two week trial of datacamp for you and up to 25 of your colleagues. We look forward to hearing from you. Hi there, Angela, and welcome to Data Framed.

Thanks.

Thanks for having me.

It's a great pleasure to have you on the show and I'm really excited to be talking about managing data science teams today and your work at iRobot. But before we get into this conversation, I'd love to find out a bit about you. I thought maybe you could start by telling us what you're known for in the data community.

Sure. So I've been involved in data science under that moniker for, let's call it four or five years, and most of the contributions that I've made, you know, I don't have a package named after me or anything like that, but I've spoken a lot about how to do data science within a business context in terms of corporate data science, and also how to develop the skills to succeed as a data scientist within a larger organization. So I'd like to think that folks who care about what I have to say probably care about that.

Absolutely. I think that's really important, particularly at this stage in the way data science is developing, to consider what's happening in a business context. Because a lot of people, I think, talk about the kind of state of the art techniques and a lot of the buzz terms we hear, but we do need to remember that data science within an organization is there in order to be one set of inputs into the decision making process, Right?

Yeah, exactly. And there are lots of companies that have their product be data scientific or algorithmic, But a large portion of data science performed within a business context is actually done in service of the business rather than packaged as its own product. And so really understanding how that fits within the larger organization strategically really matters in terms of being successful.

Yeah, and that's a point we're going to get to in this conversation. Before we get there though, I'd like to know a bit about your trajectory in terms of how you got into data science.

Initially, the short answer is I was really lucky. I can't claim to have gone to school with the ultimate goal of being a data science professional, even though I'm really, really glad that that's how things turned out. So I went to undergrad and, you know, I went to an engineering school. So obviously what you do in an engineering school is you don't do engineering. So I did my undergrad in math, and they recruit really heavily on Wall street for math professionals. It was either that or academia. And I didn't really want to join the academic environment. So off to Wall Street I went. I hated was such a bad personality fit, but I did get to work with data. That was my role, was to do data analysis and monitor data activity in the market. So that part I really liked. And nothing against the financial world. I still have friends there. It just wasn't for me.

And when was that?

Oh, my gosh, that was about 15 years ago.

Okay.

And so after I left, I started doing strategy consulting, because that's the other thing that you do if you don't do investment banking, you usually do strategy consulting. And that's when I really started getting my hands dirty with data and modeling in particular, rather than just monitoring. I did a lot of pharmaceutical strategies. So there's a lot of statistics that go into how do you set up a controlled experiment, a randomized controlled trial so that you can test the efficacy of different treatments. And so we did a lot of that kind of consulting for large pharmaceutical companies and biotechs and med techs. And after I did that for about eight years. And so I left that industry and joined a large marketing services organization. And that's where I got introduced to big data, truly big data. I mean, that's when we went from things that could run on a single machine. I mean, the machine might hang a little, but it would definitely all run within ram, to computations that you really needed to understand how to run the computation as much as you needed to understand what the computation was. And while that was exciting, the stakes were really low. I mean, if you mess up, somebody doesn't get a coupon, right? And so I actually, here in the Boston area, where I'm located, participating in the community and meetups and whatnot, I ended up meeting some folks from a company that used to exist called Enernoc. They've since been acquired. And that's where the great outcome really came, where I was doing data science under that name, and the stakes were high enough so if you messed up, you could lead to a brownout or a blackout or something like that. And folks really depended on our analyses to be able to save money to save electricity. And so I really enjoyed working in that. But then after a while, the great folks at iRobot reached out to me, and as a nerd, the opportunity to do this thing that I love, data science, but also work with robots.

That's pretty cool.

Yeah, it was hard to pass. It was really hard to Pass.

And so what do you do at iRobot now?

So I am the director of Data Science at iRobot, and I think there are sort of two sides to what I do. One side is managing the team, a team of data scientists and analysts and interns and contractors who help us achieve our objectives. And the other part of that is setting those objectives and understanding how we can do the most. The most good for the company.

Great.

And can you just tell us a bit about what iRobot does?

Sure.

So iRobot is the number one consumer robotics company in the US for sure. I'm pretty sure it's the world as well. And we are the makers of consumer robots that you may know and love, like the Roomba and the Braava. And those are a robotic vacuum cleaner and a robotic mop, respectively. And, you know, I think it's really fantastic because robotics is hard. And so this is a company that has figured out how to operate in this really difficult environment, making robots that are affordable and that are able to help folks who have these tools sort of do more with their day. And so it's really exciting.

So now I want to kind of delve into a bit about data science management. And as we know, there are a lot of roads that lead to data science, and I'm sure there are a lot of roads that lead into becoming a data science manager as well. So maybe you could tell us how you actually got into this position or into data science management in general.

Yeah, I think a lot of folks who get into management for technical fields have a similar background, which is that you usually excel as an individual contributor and then get sort of promoted into this completely different discipline. And it's funny, because a lot of the heuristics that make you a really good individual contributor don't necessarily translate when you go into management. And as an individual contributor, you are answering questions and posing questions. Really as a manager, you're scaling humans. And so it is a completely different discipline in and of itself, and it takes time and effort to get really good at it. And I think the first step is understanding that it's a different job, and.

A job that you're not necessarily will have ever been trained to do in terms of being a successful individual contributor in your field of expertise. Right?

Yeah, exactly. So as an individual contributor, you may get your toes wet in terms of providing mentorship or working closely with interns and helping them derive the most benefit from those kinds of relationships, those internships, but going from being an individual contributor to being a manager you have to remember that your goal is not to answer the question, your goal is to empower folks to answer their questions.

And what has your journey been like?

So the way that I ended up in management, I think, well, it's funny, when I first was offered the opportunity to manage another person on a team, we interviewed several candidates and the person who ultimately got the job there was, I think, some miscommunication because I don't have a PhD. I just have my undergraduate math degree, which I think served really well for how I started, which was in as a data analyst back in the dark ages before, you know, Hadoop existed and the person that we hired had a PhD, he had just graduated. And so he starts day one, he finds out that he's working for me directly as opposed to with me, and he ended up quitting that day.

Oh, wow. So that was your first engagement, managing someone.

Yes, exactly. So that left a mark. So I didn't end up, I ended up. Every time that I was offered a similar opportunity, I found a way to not take that on.

And after first impressions last.

I know.

And then after a few years it sort of became evident that that was what needed to happen for the situation, the context that I was in. And so I was really cautious. And I also didn't want to give up the role of individual contributor, something that I had a lot of passion for, that I, if I may say so, I thought I was really good at and I enjoyed. And so I was worried that the path for professional growth lay in switching tracks and jumping into management. That isn't always the case, but it certainly seemed like the door that was open to me at the time. And so I was cautious and a little bit, it felt bittersweet. But after that, managing a single person and having that second iteration work much better, I think probably because I was more self aware and the person that I was managing had a much better temperament. And after that I ended up managing a whole engagement where the two of us worked. And then from there it just kept growing where I managed a small team and then ended up managing the function, the discipline of data science within an organization. So it's been an evolution.

Yeah. Interesting. So in terms of a data science team needing to deliver value for a business, we need to consider how data science is embedded in an organization. And I'm wondering to your mind, what different models exist for data science in orgs and which is your favorite or which do you have or which is working for you at the moment?

So I have personally worked in data Science under several different umbrellas. So for instance, I've had teams that were under the operations branch of the org chart, under finance and financial operations, under it under engineering, or under a dedicated R and D organization. And obviously that's a lot of organizational structure. So there were a couple of reorgs. So I've even been part of several reorganizations. And one thing that I noticed is that the data science team always changes hands, always changes branches of the org chart every time there's been a reorg that I've been a party of. And I think that speaks to the value that data science can bring to an organization. That it seems like different arms of a company all want to be able to leverage this really powerful discipline. And I think the key to ensure that the function is successful within an organization, independent of where it sits, whether it sits next to product management, usually when you're developing product features, or whether it sits within operations so that you are delivering value back to the enterprise. I think the important thing there is to really allow the function to mature. So usually in companies, especially companies where data science is not the product, because otherwise, you know, in those cases, data science is part of the founding, right? You need that in order to deliver on the business proposition. But in other cases, within a larger enterprise, within sort of legacy companies that are looking to employ the tool set, there's usually a couple of people who are delivering on that, and they really need time to mature as a discipline within the organization, to become experts in the strategy and the objective of that organization, to be able to become experts in the data and the artifacts and bring that back. So that's the one thing that I would say that everything else really doesn't matter in an organizational context. But what matters is the ability to let that team go through a couple of iterations so they get to a point where they're past the exploration.

I think this idea of allowing a team to become mature and evolve is incredibly important. Something we'll come back to, something you mentioned just then, is allowing the team also time to understand the data and become experts. And I think this is in the direction of facilitating and allowing the team to deliver as much value to the organization as possible. So I'm wondering just in general, what are the most important strategies as a manager to ensure that your team can deliver as much value as possible?

I think the metaphor that I like to imagine is, and you'll have to pardon me because I'm Brazilian. So I think in soccer, not football, but in American football, there is this concept of the linemen who create space so that the quarterback can make his play. And I think a lot of times we like to think of the manager as the quarterback, and I don't think that's right. I think the individual contributors for their particular projects, for their tasks are their own quarterbacks. And the role of the manager is to really create the pocket, create space so that they can think and create space so that they can see the whole field and they can see the opportunities and they can see the answer. And so that's sort of my mentality and what I coach my team to be able to do is to become experts in the data. I think if you get asked to perform an analysis or to answer a question, a lot of the times what happens is the person doing the asking doesn't necessarily have the imagination to envision what an answer might look like or what might be able. Right. They have this narrow view because they are experts in something else. They're incredibly smart, but they're smart in a different than the thing we are smart in. And so when they ask a question, sometimes the question is too low level or too high level. And part of the role of a data scientist is to be that therapist getting the question just so. So that you really get at what the person doing the asking wants. Sometimes they don't even know what they want, or they don't even know what's possible to get answers to. And so being the lineman to create that space so that the quarterbacks can do their thing and do the strategy and figure out how to answer the question is really how I think of enabling the team to deliver the most value.

There's so much in there. Two takeaways I was thinking of when listening was, you know, there's the aspect of managing expectations on both sides of what's possible, what's feasible. But also this act of translation and helping to turn business questions into data questions, and then the reverse act of translation, turning the data answers into business answers as well.

I think that's fundamentally the job of a data scientist because everybody, I mean, it's the 21st century, every discipline has data, everybody has information that they're using to inform their decision making. What makes data science unique is our ability to take a business question and formally formulate it, formally articulated in a way that we can use the tools of statistics and in software development to create a solution that is reproducible, that is replicable, that is interpretable, and that is fit for purpose, that answers the question. Because a lot of times what can happen is data scientists will become so enamored with a particular approach that they can try to use it for everything when it wouldn't be a great fit. Or they become enamored with a data set and they use it because they can, not because they should. And so that translational step from business to math to the technical components, back to the business, really is where the great data scientists make a difference.

We'll jump right back into our interview with Angela Basa after a short segment. Now it's time for a segment called Correcting Data Science Misconceptions. I'm here with Heather Nolis, a machine learning engineer at T Mobile. Hi, Heather.

Hey, Hugo.

So, Heather, something we hear time and time again is that if you want to do machine learning in production, you're going to want to write Python code and not R code. Is this true?

That is not true at all. Right now we have our models running in production AT T Mobile.

Before we delve into the work you've done, could you remind our listeners what it means to have a machine learning model deployed in production?

So the traditional data science workflow looks like you get some data, you do an analysis, you generate a static or maybe you show it on your local machine, maybe you export it and you show it to somebody, but it's always static and it's always kind of done by one person. When a model is in production, what that means is that it's continuously running. Anybody can use it at any time to make predictions on the fly.

Great. So now tell me about the business problem that you're trying to solve AT T Mobile.

So the team I work for AT T Mobile, it's called the Social Messaging Product Development team. And what we do is we are in charge of at building all of the software that allows for customers to talk to T Mobile Care agents through text. In this respect, we support a few channels. Anytime that you come in through Facebook, Twitter, text message, Apple Business Chat, we have in app messaging or on the web, anytime that you use one of those channels to talk to T Mobile customer care, that's something that my team has filled. And so every time that a customer enters one of these channels, it takes a while for the agent to really understand why they're coming in. So you say hello, and the agent says, oh, how are you doing? What can I help with you today? And it just takes some back and forth, this basic interview to really understand what the issue that a customer is coming in. And so what my team does is if a customer enters a channel and they Just say hi. We know that we have tons of information about them as their cellular provider. We know their bill status, we know if they dropped any calls. We know any previous conversations with care. We know if they just placed an order and it's about to ship. And so we should be able to tell with some certainty using these signals and their first message why they're entering a channel, which saves the representatives a ton of time. And it saves customers a ton of time because the last thing you want to do is explain your problem for the fifth time to a new agent. So that's kind of the problem that we look to solve.

And have you done this in R?

Yeah, we do it in R. So very basically we have a convolutional neural network and the input is that first text that we receive in any of the customer data that we want to look at and the output's the topic category. So what exactly is the customer coming in to discuss? The exploratory analysis of this required a lot of historic signals and analyzing and seeing what were actually strong features and identifiers that we should be pulling into our model. And then we had to train that model and we chose to do that using R Keras and tensorflow libraries. Then using the Plumber library in R, we went ahead and made an API. We containerized that with Docker and we deploy it like we do all of the other software that the social messaging product development team build. So we use Docker, Jenkins, Mesos and Marathon.

What are the main problems people associate with productionized machine learning models in R? And how did you get around them or why? Are they irrelevant or just plain wrong?

So whenever people scoff at us using R in production, they always cite one major problem, and that's that R is slow and bulky. And that's true. R is a single threaded language. It is really slow and it does take up a lot of space. But understanding the infrastructure of any major development pipeline lets you know that this isn't really a valued criticism. If you need quicker responses, you simply add more instance of your service. We've load tested our API at 50 times the T mobile care volume and it performed better than some of our Java services. So saying that R is slow, okay, yes, but you can scale up. We all live in modern society. The hardest problem for us was actually Python because TensorFlow uses Anaconda Python as the back end. It's a huge library and it's actually pretty slow and pretty bulky. And so for us, R was the easy part. But Python and getting Python incorporated into our system was actually the more difficult issue.

And are there strengths that come with using R for machine learning in production?

So our machine learning team came up through an agile development shop, and from an agile perspective, it doesn't make sense to do an exploratory analysis in one language and then rewrite production code for another language. That's double work, and you want to work as hard as possible to eliminate that. The best data scientists that we found were most comfortable in R. And so from a machine learning perspective, when we want to put our best models out into production in the quickest time possible, it only makes sense to support R if we're going to use R as an exploratory language. And that's what all the really excellent data scientists that we're finding favor.

Heather, thank you so much.

It was awesome to be here. Hugo, thank you.

After that interlude, it's time to jump back into our chat with Angela. So a recurring theme in this conversation so far is the maturing of a data science team and the evolution as a team. And as you said, you started off managing one person, and I'm wondering what are key aspects as a data science manager to think about as your team grows in size as a function of time?

I think one of the things that happens over time. So I was the first manager of data science at Enerno, the company that I was at before iRobot, and I was the first director of Data Science at iRobot. So these are two teams that I grew sort of from the ground up. And the thing that happens in the very beginning, there is so much potential, but there's also so much low hanging fruit. And so having a team that has the flexibility to deliver on a couple of, I wouldn't call them necessarily moonshots, but on a couple of high visibility, high sophistication answers to start illustrating what's possible, right? What are the amazing things that this new function can deliver on? But also that low hanging fruit, the quickest way to value is knocking those out, is taking the things that are easy and answering them better than anybody else can with an architecture that takes care of itself so that it requires minimal monitoring. And you just start adding things to that pipeline and solving problems that themselves are tiny, but that save an aggregate number of people seconds or minutes, and then those add up. And having that flexibility means that in the very beginning you have sort of undifferentiated talent, right? You have the quote, unquote, unicorns. I hate that word.

So data science generalists of some Sort.

Exactly, yeah. Folks that have the basic tool set and with a little bit of guidance, they can sort of play in all of those roles. But you know, there's something that folks in the biomedical sciences say is that I think is really relevant is that ontogeny recapitulates phylogeny. And what I think that phrase means is that the way that organisms develop from fertilization to gestation to hatching, mimic the stages of the evolution of the animal's remote ancestors. Right. So that's a pretty random analogy, but the way that I think it's relevant here is that the way a data science team develops also mimics the stages in the evolution of a company. Right. So much like a startup, a budding data science team has lots of undifferentiated but flexible talent. And the team goes through several, you know, quote unquote pivots that as they try to establish their value, who their champions are, and the ideal way to engage with the rest of their internal customers. So when they're just small teams, they're rudimentary, right. And they're, and they're pluripotent, so they act a little bit like stem cells and in that way they sort of mature into anything.

And what then happens as a data.

Team matures, when you get some maturity into the team, that's when you start to have specialization, that's when you start to have differentiation. And so that's when you start having folks who are really great at visualization or really natural talents in terms of data platform engineering or reliability, folks who are great at qa. They have that personality and that passion for the attention to detail. And so when there's enough scale in the type of work that the data science team is doing, only then I think it makes sense to start having those dedicated ancillary teams that can liberate the data scientists to truly focus on the science component, which is the hypothesis testing.

And once you enter that stage, how do you think about hiring or building a team around the different skills? Like, as you say, you don't necessarily want data science generalists then, but you want a team of people whose skill sets, question asking curiosities, complement one another, right? Yeah.

I think as you start, you want to have folks who are well rounded, but the farther along you go, I think it's important to have a team that represents your end users, whoever they may be. And so I think especially in companies where the product is data science, you want to make sure that your data science science team looks like the folks who use your product so that you have different perspectives and you can ask different questions and everybody doesn't look the same way, use the same tools, ask the same questions. And so I think it's important to have that diversity in all dimensions. I think folks who are senior and folks who are junior. You know, there's something I like to think about in terms of the luxury of ignorance, which is when junior folks in a team get to ask dumb questions or. Right. And dumb in quotation marks, because they're not dumb. What they are is unencumbered. They're unencumbered by the assumptions that we forget we make. They are unencumbered by the heuristics that we've developed that may not be applicable everywhere. They have this luxury of being able to challenge the assumptions that folks with more seniority are perfectly capable of. But you start forgetting you hear hooves and you think horses, not zebras. Well, the more younger folks are like, well, what if it's a zebra? And they challenge that and they force you to think about why you're making certain decisions.

I love that. And I love that you described in terms of heuristics that we develop over time, because we know that when we start using heuristics a lot, they're coupled with certain biases as well. So having a new point of view which is unencumbered by heuristics will also make us recognize our own biases. Hopefully also.

Absolutely. And, you know, not to knock on heuristics. They're great. They exist for a reason. We build them because they create shortcuts and they make us efficient. Right. It's the whole thing about, you know, thinking fast and slow and how our brains operate and how we create our own Bayesian priors and sort of go from them. But I think having folks with different priors participate in the conversation really enriches it.

So you mentioned earlier the types of questions that a data science team can think about and perhaps should think about. And you actually. And we may get to this later. Recently you sent me a draft of an article you're writing for Harvard Business Review, and you make a nice distinction there between the space of questions a team might be able to answer and the space of questions a team can and should answer. So I thought maybe you could speak to that a bit in light of this.

Yeah, I think that this is a perfect fit for that in terms of what usually can happen, and very easily, and I've been guilty of this as well, is you have access to data, and so you start correlating, you start exploring, and you start figuring out what could happen. And I think while there's certainly value in directionless exploration, as you're starting to build your own heuristics about these data artifacts, I think if possible, whenever possible, it's much more important to think about first what the objective might be and to have that North Star as you start spelunking through data. So when you think about what the question that is posed to you is, a lot of the times it can be easy to think, oh, well, I don't have a perfect fit for that question, but I have this other data set that I bet is correlated. And so you start going there. And I think one of the things that makes a really good data scientist is also humility. Humility to know that maybe that's not what it means. I mean, sometimes the answer is in an email thread somewhere that you don't have access to that you weren't involved in, that you weren't privy to, but the answer exists elsewhere. And so I think it's really important to have the self awareness to go and ask and become an expert, not just through spelunking in data, but spelunking through the organization, right? Making connections with other folks around the organization and truly gaining insight into how the data is generated, what context is it used for, can it be repurposed, what are the issues that potentially arise with that repurposing? And so really figuring out what kinds of questions can be answered is great, but what kind of questions should be answered, I think is something that the data scientists within an organization is well positioned to be able to ask and perhaps better positioned than anybody else.

And this speaks to a certain trade off, I think. I'm wondering, in your role as a data science manager, what are the types of trade offs you need to make and how do you think about making the right ones?

Oh, I think being a manager in any discipline, but especially in data science, I think those trade offs are everything. So data science is a little bit different than other types of work because you're not just answering questions. A lot of times you are figuring out if a question is even answerable, right? It's not just the how or the what, but it's also the if and so figuring out those trade offs. A lot of other disciplines have different trade offs, but a lot of the trade offs are also very similar in terms of how much time do you spend catching up on what the latest findings of a discipline, the latest applications, the latest methodologies versus Selling the discipline, selling it internally. Letting folks, you know, in legal and in sales and in operations, letting them know that this resource is available to them if they have questions that they would love to have more information, more data to help with their decision making. How much do you spend doing and usually making slides or writing memos or thinking through what everybody needs and articulating that and setting it in writing versus coaching versus growing your team and making sure that they have what they need and making sure that they are getting exposed to strategy so that they can make the best play when it's their turn, as well as planning and strategizing and figuring out who do we need to talk to, when do we need to deliver something by, when do we need to do roadshows and present some of our findings so folks know that we're a credible part of the organization that can be leveraged and can bring value. So I think all of that are the things that you are constantly trying to juggle and optimize as a manager. And also, you know, there's loads of additional questions. So who do you bring into your team? And how do you make sure that everybody who comes and joins the team allows you to get network effects out of that expansion so that you're not just having plus one, but you're having plus n because of all of the ways in which that person improves a team and covers blind spots?

And how do you think about the trade off between? I mean, when hiring for a data science position, you can hire someone with incredibly strong quantitative and data science skills, but you can also go about it, I presume, in terms of someone who maybe has some other expertise and can pick up a bunch of the data science in the process as well, right?

Yeah.

I'm a big fan of the data science bootcamps. Not all of them, but I think there are several that have been fantastic for preparing folks who have that ambition and that ability to learn the skills.

Right.

I think there's part to data science, which is that you can't teach, right. Like you can't teach somebody to want to answer a question correctly. But the how I think is teachable. And so I think there are lot of folks out there who are breaking into data science. I mean, the different institutes and universities are only starting to have quote unquote data science programs. I mean, pretty much everybody who came into data science over the last five years did something else as their training. And so here's a perfect example. On the team at iRobot, we have one of our data scientists who's originally trained as a marine biologist. And you would think, what does a marine biologist do in a robotics consumer company? Well, you'd be surprised because it turns out that there's a lot of research in her field. And what she did, she did a lot of studies with pods of dolphin in the wild. She actually traveled all over. And I'm sort of jealous. But it turns out that that kind of modeling expertise is really useful when you're thinking about a fleet of robots and how those robots behave independently. Independently. And so you can think of a fleet of robots as a pot of dolphin in certain scenarios. Obviously it's not a perfect analog, but a lot of the modeling comes extremely handy. And so that knowledge exists in the world and it's just a question of how do you know to look for it there. And she brings that level of expertise to us and she's an amazing data scientist. She has all of the qualifications to be a fantastic data scientist technically. But she also brings this added dimension that helps us solve problems differently and I think better.

Yeah. And of course, being from academic research or scientific research, knowing how to ask the right questions, but also if she did a lot of travel, data collection, that type of stuff, thinking about the data generating process, how the data was generated and how then you can model it is such a key part of what it is to do this type of work also.

Exactly. Yeah. And that's one of the reasons that I'm a big fan of internship programs as well, because it can seem like grunt work, but it's incredibly important grunt work. And I think we all did it. I mean, I did it when I was on Wall street as well. And as I was building my data sets and I was building these databases that got monitored, I understood very intimately what I meant when I made design choices and how my design choices propagated downstream so that what kinds of questions were easier to answer and harder to answer and why? And what was my governance model? Right. Like, I didn't have words for those things when I was starting out, but that's what those are. And so in our internship program, we have folks become intimately familiar with data gathering and data ingestion and data management, which I think down the line helps them tremendously because they are better able to understand context and to understand how important it is to be respectful of those design decisions and not use data sets for one thing, when they are really intended for another. And accounting for that.

Yeah. And just quickly, for any of our listeners who are really enjoying this conversation and your work at iRobot. Can they check out internship programs online or something along those?

Oh, yeah, absolutely. So if you go to our careers page and search for the Data Science internship.

Yes.

If you're interested, please apply.

Fantastic. And if you do apply, make sure to mention that you heard about it on podcast.

Absolutely.

Yes.

We'll jump right back into our chat with Angela Bassa after a short segment. Let's now hop into a segment called Project of the Month. I'm here with David Venturi, curriculum lead for projects here at datacamp. Sucks to have you on the show, Dave.

Sucks to be here with you, Hugo.

Normally, I'm extremely positive with our guests, but since I know you and that you can take a joke, I figured we could switch it up to keep our listeners honest.

Yeah, so I totally understand and am completely on board since I pre wrote this segment anyway.

So, Dave, first thing, what is a datacamp project?

So a datacamp project is where you apply several of the skills you learned in courses in a real world end to end data analysis.

Great. So now tell me about this project you're so excited about today.

Yeah. So we recently released a project created by DataCamp's chief data scientist, David Robinson, and it's super awesome. It's called Rise and Fall of Programming Languages. And in it, you analyze the relative popularity of programming languages over time based on Stack Overflow data.

So can you elaborate on this a little?

Yeah. So Stack Overflow is a programming question and answer site with more than 16 million questions on programming topics. By measuring the number of questions about each technology, like R, Python, Java, and JavaScript, for example, you can get an approximate sense of how many people are using it. Each Stack Overflow question has a tag which marks a question to describe its topic or technology. For instance, there's a tag for languages like R or Python and for packages like ggplot2 or pandas. And the data set you'll explore in this project has one observation for each tag in each year. And this includes both the number of questions asked in that tag in that year and the total number of questions asked in that year in total. And by manipulating and visualizing that data, you answer a bunch of interesting questions.

That sounds really cool. So my first question is, has R been growing or shrinking?

Growing a lot. A steady rise from just over 1 in 10,000 in 2008 to 1 in 40 in 2018. That's roughly 200 times growth.

So how about the data manipulation package dplyr and the Datavis package ggplot2?

Yeah. Also growing. They don't have nearly as many questions as r, only between 2 and 3,000 versus 28,000 for r of the total 1.08 million in 2018, but still growing.

And what are the most asked about tags overall?

Like total? Yeah, yeah. So overall over the past decade, the most asked about Tags list goes JavaScript, Java, C, PHP, Android, Python. 14 others then are the least asked about tag is Yahoo for whatever that's worth.

And the changes over time in those most asked about tags.

So the big takeaway is that C gets way fewer questions than it used to and Python has grown quite impressively.

Sounds like a great project, Dave.

Yeah, definitely. And if you've learned a bit about the Tidyverse, perhaps through David's also excellent intro to the Tidyverse course, this project is a great chance to apply those skills. Dave's an incredible instructor and as a former data scientist at Stack Overflow, he's the perfect person to walk you through finding insights in this data. And if you have a cool project idea like this one, you should also definitely apply to become an instructor yourself. The link is pinned at the top of my Twitter profile. Venturi DB Cool.

Thanks David.

Thanks Hugo. See ya.

Time to get straight back into our chat with Angela. So something you mentioned, Angela, is this idea of being a requirement in some ways to sell data science internally in an organization. And something I'm really interested in is how we're going to see our data literacy spread across orgs, and not only in data science teams. I'm wondering for you to have the best conversation with stakeholders, how much data do they need to be able to speak? Or do you see a future in which C Suite and other stakeholders speak more data and become more data literate?

Oh, I think the latter. I think it's going to start becoming even harder to not be able to credibly discuss your product or your strategy in a data literate way. I think the market has that expectation. I think it's becoming table stakes and to be able to ensure that your strategic decisions are based on information that you have had the foresight to gather so that you can make the right decisions.

So what are some common pitfalls or warnings you have for data science managers?

So one of my pet peeves is when a data team doesn't know what data is available and what it means and how it can be used. So I think the first thing that you need to do is have a big exploratory data analysis party.

Have data party. I love it.

Dedicate some time, you know, once a week, maybe 10% of everybody's time dedicated to getting lost in the data and truly understanding it and setting up coffees with other folks in the organization so that you can ask questions about how that data is designed and created and collected and stored and labeled. I think that's hugely important. I get really aggravated when folks think that's a waste of time because it's undirected. And I think it's hugely valuable if you're going to be the expert on your company's data, that you be the expert on your company's data. The other thing I think is to not over promise. So one of the things that tends to happen is folks know what's possible and so they paint a picture, but they forget to be pragmatic about how they're going to execute. And so not over promising is huge. But not under promising either. I think sandbagging backfires. I think you need to be able to accurately promise and then to deliver on it. And that's not just because it keeps you from that over under promising situation, but also because it builds credibility. If you can accurately assess what your outcome is going to be, I think that lends credibility to the actual outcome as well. And I think one way to get to that point where you can promise and then deliver is to be honest and to be transparent. Perhaps a little bit more transparent than with other disciplines, because the data scientist is trained to interrogate data, to interrogate situations. And so they're going to be able to tell when you're over promising or when you're under promising or when you're not sure of what the objective is. And so it's really important to have that clarity and to communicate that within the team and within the organization.

Great. So I think this has been a wonderful conversation about the state of data science management today and your practice in particular. I'm wondering what the future of data science in organizations, particularly relative to the decision function, what this looks like to you.

It's rosy. I think there's job security in data science. It is definitely something that's becoming more and more ingrained in the fabric of different organizations. And I think that's why it depends. So the future is going to look different for companies that have their product be data scientific or algorithmic versus companies that use data science in service of something else. I also think that the future looks different whether the team is part of a public organization, a startup or a large organization. And also the time horizon. So is this a team that is exclusively research and they're working on moonshots versus a team that is more operational and is enterprise facing and helping the company optimize its own functioning. I think all of those have different curves that they're on, but I think in any respect I can't see a future where we're not relying more and more on the expertise of folks who understand how to manipulate data.

And for all our listeners out there who are either data scientists, aspiring data scientists, or even have aspirations to get into data science management, do you have a call to action for them?

Well, I'm so glad you mentioned it and actually you also mentioned it earlier during our conversation, so I'm really excited. I just penned an article for HBR and it's actually part of a series that they're putting together called Managing Data Science. It's an eight week newsletter that they're putting together that focuses on making analytics and AI work for everybody's organizations. And so I have an article coming up. So by the time this podcast hits the wires, I think it's going to be two or three weeks old, so I encourage you and your listeners to check it out.

Fantastic. And we'll include a link in the show notes as well.

Awesome.

Thank you Angela. It's been such a pleasure having you on the show.

Oh, it's been my pleasure. Thank you for letting me nerd out.

Thanks for joining Our conversation with Angela about managing data science teams. We saw that as you move from data science roles to managerial roles, that is from being an individual contributor to being a manager, you need to remember that your goal is not to answer the question, your goal is to empower folks to answer their questions. Essential aspects are clearing the field to allow your team to do their best work, demonstrating value early on by both getting the low hanging fruit and shooting for the moon, really allowing the function to mature and having a team that represents your end users. Also, do not forget to make sure that your data scientists know what data is available, what it means and how it can be used. And one great way to do this is to have a data analysis party. Also get ready for next week's episode, a conversation with Wes McKinney, creator of the Pandas project for data analysis tools in Python, and author of Python for data analysis, among many other things. Wes and I will talk about data science tool building, what it took to get Pandas off the ground, and how he approaches building human interfaces to data to make individuals more productive. On top of this, we'll talk about the Apache Arrow project and how it can facilitate the future of data science work in terms of interoperability, the importance of data frames that are portable between programming languages and facilitating data analysis work in the big data limit. Not to give too much away, but we'll also discuss the challenges of open source software development and how Wes is approaching funding and resourcing OSS with his most recent venture, Ursa Labs. I'm your host Hugo Bown Anderson. You can follow me on Twitter Hugo Bowne and datacamp at datacamp you can find all our episodes and show notes@datacamp.com Community podcast. Thanks thank you. Thank you very much.