Data Science Hangout | Edgar Gallo, Daimler Trucks | Training a Team of Data Scientists

Transcript#

This transcript was generated automatically and may contain errors.

I just want to welcome everyone to the Data Science Hangout. I know most of you have been here before, but if this is your first time, it's an open space for current and aspiring data science leaders to just connect and chat about some of the more human-centric questions around data science leadership. We really want to create a space where everybody can participate and want to hear from everyone. So there's three ways that you can ask questions. You can jump in live. I can pass you the the fake microphone and put questions in the chat. And then we also have a Slido link where you could ask anonymous questions too.

But this will be recorded and shared up to YouTube as well for anybody that missed it today. But I'm so excited to be joined by my co-host for today and friend on LinkedIn. I know we haven't met yet in person, but I'd like to introduce you to Edgar Gallo, Chief Data Officer at Daimler Trucks North America. Edgar, could I turn it over to you to have you introduce yourself and some of the work that you do on your team?

Thank you very much. Yes, absolutely. Very excited to be here. I've been attending for a few weeks now and months, I can say. I hope I meet the caliber of the other co-hosts you have had. Big shoes to fill here, but over the time I've learned people are very welcoming and warm. So my background, I've been with our company for almost 15 years now. I started with them in finance and controlling in a very quantitative like role. From there, I moved into a role where we—a team we have in our company is kind of unique in that it is an internal consulting team. And what we do is we focus on process improvement, process engineering, load balancing, things of that nature.

And back when I joined, we had the two areas of focus together. One of them was our area in manufacturing and our area on the non-assembly space, if you will, processes like accounting and hiring, things of that nature. And it was in that, let's say, play space where I did a lot of the analytics that were not so much driven by my interest, but the interest of others, which was really, really key for me to understand and really tag along into what back in the day with the background in econometrics and stats, I was able to recognize the data science.

So I run a team of very curious and inquisitive people that were split between the East Coast and the West Coast. We run projects all over the place, super fun. But something I learned over time is that the ability to measure not only their satisfaction with their work, as in are we moving the needle or not with all the time we're spending in this analysis, but also the stakeholder satisfaction, right? Are they seeing a difference that is measurable? It was really closely connected to the ability to get data from the processes. And that's where I had the aha moment where we really needed to move into more data-centric focus.

So I pitched it to my boss, he pitched it to their bosses, who pitched it to, you know, there's always more bosses, but they all were receptive of the fact that we really weren't adding any more headcounts. And we have spent about, I want to say the better part of three months studying the need of the company, right? Doing this market research, internal, if you will, to where we had found a really nice gap that we could fit. And also a training, let's say, the training method, what do we need to get from really smart people to practicing data scientists? So those were the two outcomes of this three month long process. And as a result of that, we started a team of data scientists that started working for the company.

And as of November of last year, I moved into the Chief Data Office role. Again, that's fine, you know, doing the laundry with the data scientists, I realized a pattern, and that was that for the first or the early days of our, let's say, our existence, most of our projects were not so much data science projects, but data engineering projects. Where's the data? How can we get it? How can we make sure it's reliable, trustable, things of that nature? So that really piqued my interest into the whole world of governance and access management and data management. And that's what I do now for Daimler Trucks in North America.

Training a team of data scientists

That's awesome. Thank you so much for that introduction, Edgar. And I know you just touched upon that training piece a little bit and building up that team. But I think it'd be awesome to hear a little bit more about how you went through that process. And I know you mentioned like a buddy system before, between new data scientists and existing ones. But we'd love to just dive into that a little bit.

Yeah, absolutely. So when I was hiring for this team of consultants, I really didn't focus on a specific background. I more so have always focused on, I'm infamous for making up words. So I focus on team get alongness, right? So I try to get different personalities that will get the best out of each other when I put them to work together. So with that in mind, I ended up with people from accounting, people from engineering, really people with real life work education versus a specific degree or things of that nature. So we had a really diverse team in that sense.

And I noticed that was very successful for the consulting piece. So when we started looking at the stacking of the data science piece, it was a little more challenging in that we have to have some rigor to the training, right? So when we were doing the research part of the pitch to set up the group, we went out and said, okay, what would it be that we needed to do from a quantitative side, but also from the soft skill side? And it really validated that we needed to continue having this introvert and extrovert balance, if you will, because the extroverts were really good at explaining to others the black box, and the introverts were really, really good at creating this black box.

So that was kind of the beginning of setting up the buddy system. But then really one of the, let's say, value propositions for the team to be created was how do we disseminate this in a company that it's trying and trying and having really advanced engineering in some pockets, where we're creating trucks that are now powered by electricity and batteries and renewables, trucks that can drive themselves. But on the other hand, how do we bring the rest of our company up in this layer of upskilling, right? So that portion was also a value prop element where we said, look, we're not only going to create training for ourselves, we're going to find ways to disseminate this knowledge.

So that was one of the pieces where we said anytime we engage with a department in the business, we want to have a buddy system, we want to make sure that we start, we're the driver, and our clients are in the backseat. Eventually, they choose somebody that gets along with this and put them in the passenger side. So we can start creating more proliferation of the understanding of the business knowledge and how you apply the data science techniques, until eventually we swap and they are driving the project through and they see it to completion with our coaching.

So that was one of the pieces where we said anytime we engage with a department in the business, we want to have a buddy system, we want to make sure that we start, we're the driver, and our clients are in the backseat. Eventually, they choose somebody that gets along with this and put them in the passenger side. So we can start creating more proliferation of the understanding of the business knowledge and how you apply the data science techniques, until eventually we swap and they are driving the project through and they see it to completion with our coaching.

So for that training, what did that look like? Or did you use outside tools? Or did you just identify a few experts internally? So just like I make up words, I'm super thrifty. And I'm always trying to have the least resistance from the folks that have to approve anything I pitch. Super shoestring budget. So we looked at where most people were coming from. And this is for specifically for those that were going to join the team. And most people have a certain content of playing along with Excel and do some data mining. So we focus on what most people know now.

And then we focus on actually the Coursera data science certification. So we took that as the backbone of our training. And then we just did this little spider chart to see how far people were away from it. And once we knew what were the primary targets of training, we looked at either partnering with Coursera, or LinkedIn Learning, or a couple of other places where we have some corporate licenses and affiliations. We ended up working with a company, I think, out of the UK. And they had really specific training for things we wanted to learn how to use like Alteryx designer, Alteryx server, you know, statistics, things along that nature, but they were all web consumed. And we managed to get a great deal through our indirect procurement team that did wonderful negotiation for us. And that was not only for us, but we were able to negotiate licenses for those that were joining us in projects from the business.

Instead of just giving them what they're asking for, ask what they're trying to answer, right? Because sometimes they come to you and say, Hey, can you give me the ROI on, on moving this supplier from here to there? And you can just give them that or find out that more contextually, what are they pursuing?

What role does the Chief Data Officer have?

Oh, sure. Hey, Edgar. I heard that you said that you report to the CIO. And I was interested in your thoughts about data being within IT versus I've seen a trend of taking the chief data officer and making it its own, like making that area its own reports to the CEO. I was just curious what your thoughts are, where you think that's going and how it's worked for pros and cons.

I think, yes, I've seen the same. And it's, it's an interesting path in that. I think it's a spectrum of maturity, right? And I tell you, we're a very traditional business. We're an industrial. Our focus has been on making the best trucks, the most reliable trucks forever. We have an extremely smart group of engineers that can do calculations over and over and over. But I think we're finally getting into understanding that those calculations eventually, you know, let's say fill the bin and they need to go somewhere, but they can't just go away because our trucks last a long time. So we have a commitment to our customers. And when we're troubleshooting a truck that 10, 15, 20 years old, those calculations matter. So now we're slowly creeping into the data management topic, right?

Which forever has been in IT. But the cool thing about it is that my boss is not traditional IT CIO. He's a CIO that is proactive. Let's say a business maker, if you will, in that he understands that for the longest time, the accumulation of data is a good thing if you know how to use it, or it's a bad thing if you don't know how to take care of it and curate it. So I would say at the moment for the maturity spectrum and where we are as a company, it's working really well for us because his understanding of IT is leading edge, I would say. So he's a really good broker of support with our board.

Now, I know that as the board understands more and more about the risks and the benefits, then we talk about ransomware and the risks and, information security and information access management. And then we have more and more, let's say, regulations and right to repair, CCPA, and you name it, right? Those topics are taking kind of a space of their own. And that's where with the CIO's support on it, the board realizes more and more that the CDO, it's an important role in that somebody's got to be doing traffic control beyond the business that we traditionally support, beyond the design, beyond the improvement, beyond the innovation on the product. So I don't know if I see a future for us in which the CDO would report directly to the CEO, but definitely I see a much more ingrained and deeply rooted relationship.

Centralized vs decentralized data science team

So when we started the team with the data science group, it was part of this internal consulting group. So while it was centralized, it was serving the whole company. So it was deployed from our consulting group, but it was working with purchasing or with aftermarket controlling or with finance, all across the board. The key there was to work widely because the purpose was also to elevate any place where we went to and bring about the knowledge and the tools and the thinking methods.

So one back, I think you're talking about training. The training was very focused on the analytical tools we wanted to leverage because, again, with a shoestring budget, I didn't want to go pitch, oh, by the way, can I get this tool and that tool and that tool? There were other groups that were significantly ahead of us in that they found tools like data mining tools or data aggregation tools that weren't really IT per se. I mean, we're not talking a full-blown informatica solution. We're talking about something called Alteryx and Alteryx Designer. And it's really like SQL and Seras where you just drag and drop, right? Just like you could do like a Shiny app.

This thing helps you with that in that it just kind of does a data mining result. So this specific online software training, it wasn't really just for Alteryx, but it had a bunch of other topics, really. So my whole inspiration from this came from a company in the UK that back in 2014, 2015, basically took Tableau and some data mining tools and created a school. I think it's called the Data School. And that was kind of the inspiration is like, get the data, drop in, understand the business, get the data, make it stable, the data mining piece that is. And then the improvement should be made measurable via some sort of visualization tool. And not only because it's that piece of satisfaction we're looking at and for the stakeholder satisfaction as well, but in that they continue to improve their processes after we're gone. So they continue to measure the improvement and see where they can take more for the benefit.

So this software solution vendor in the UK was a good choice for that super variety of topics. But with an accountability system that you have to take a little quiz, a little test every so often, your manager would know about it. They would keep track of what you're doing and the speed of your progress, things of that nature, because the training also needs to have some sort of floor to it. Otherwise, we just hang out, which I tend to do.

Architecture wise, we are a 75 year old company. So you can choose the name and we have it. It was our old IT adage in that business had the budget, came to IT, asked us to get something done, and we would just get it based on what the business wanted. For that specific area, not so much holistically. So now with our new CIO, it's more of a holistic view. What do we need to keep that serves every single function and what can we consolidate? So now the pursuit is that. So not that it's simplifying because as we add off-brand cloud solutions, architecture gets more complex.

Deploying data science solutions

So when I was working with the team, I was also in the middle of getting a master's in data analytics. And this was an interesting combination between the School of Statistics of the university and the College of Engineering. So they both combine classes. So the College of Engineering is teaching everything on Python and all the ML and AI applications. But the School of Statistics was more about hypotheses and prove it and replicate it. And we do it. So I was one foot in both. And for that reason, I was very open to the team using either.

So I had a team member that was really good with R markdowns and his presentations. And he was really good at conveying that to the senior leaders hiring us to work for them. And another one that was just very comfortable with Python and doing some NLP applications for our HR team, for example. So we've used both. Not Julia.

After-sales data science applications

So yes, we have, like I was saying earlier, now IT has the center of excellence that has the big data group. And they have deployed some of their scientists across the aftermarket. And we have some very interesting applications in part replenishment, inventory volumes. We apply to replenishment, apply to optimization of inventory levels, apply to timing of changeover. Basically, a changeover for us means we have finished the design of of either a product or a vehicle or an option in the vehicle. And we tested it, and it passes all of our testing. And then we communicate to our supply base that we need some inventory from their side, because we're going to make this now available for purchase. And that's the changeover point where we say, it's no longer internal. Now it becomes an outside looking option or product.

So on that timing, we've also deployed some interesting data science applications to improve with the volume, right? If they were saying, hey, get 100 of this, we're saying, well, based on our data science approach, you need twice that, but in two different locations versus just the one. With our footprint of PDCs, Power Distribution Centers, we are having some interesting applications of that as well. And some of the products that we warranty as an aftermarket product as well. So yes, it's all over the place.

Low-code and code-first communities

It says, your work encompasses both low-code and code-first communities. Any ideas about how to build and encourage mutual respect between those two groups?

Oof. I think the first is trust. I was in the business, and I moved to the other side. Before I moved, we were working on low-code using OutSystems. And it was really, I was part of a bunch of different, very stressful meetings. But the last few, mostly as an observer, and where I was able to pick up that our IT counterpart, we're really stressed about something, but we were not picking up on it. And their stress was more about, hey, you guys, you really haven't seen the full picture on the other side. Hey, you guys, we haven't really made a good effort on showing you what it looks like. But when you put something out there, and you go from your development, and you pass your QA, and you put it in production, it's on us. And we want to know how much of your low-code application are you willing to support Saturdays and Sundays versus how much is on us.

And then we just start kind of like peeling the onion and understanding really what was driving their stressors, right? The guys that are working on full-blown development piece, they know all those pitfalls. And they know they're going to be on call. And they know they don't have the luxuries of the analytic teams that just go off on the weekends as well with all their stakeholders and come back and deal with issues on Monday. So there was a lot of discovery and empathy built seeking to learn what we didn't know. So from low-code, you're moving boxes here and there, deploying, yeah, you make something faster, automatic, and you get pat on the back. But that requires a server. That requires information classification. That requires security around it. That requires a bunch of stuff from the infrastructure side and the software version side. And a few of the things that we really didn't know about. And not because we didn't want to, but just because we didn't really have the foresight to ask, what's driving your stress? What am I doing that's stressing you? So the moment we started doing that, we started building bridges and trust and taking advice better.

Building the data science team

We identified things like, say, we're looking at improving a process between two key stakeholders in the company. And the stakeholder that hired us had more data. And the data was 100% pointing at the other stakeholder being at fault, right? So we started going after, well, why can I have more of this data? Why can I do my own measurements? Can I get more of this? Can I get more of that? And having that unilateral data push on you to make things happen, it was really what the driver was. How do we do this? How can we take really a data-driven approach and not so much a which stakeholder is more prepared approach? And those were some of the kind of, I would say, failure modes, right? When you're trying to help the company but only one stakeholder is benefiting from your process improvement, from your analytics, it really makes no sense when you think as a system, right? As a system, the imbalance can come from either side, not just from the side with data. So that really drove us to think, how do we create a team that can do this data-based decision-making?

And what does your data science team look like today? Is it made up of, or I guess, how many data scientists versus data analysts?

So my data science team, I think all but one have turned over into the business. Actually, one of them moved to a different area of Daimler, into Mercedes-Benz cars. So it's kind of all in the family. But what happened is, as a result of that, we had really deep and long conversations with HR. We had really deep and long conversations with other areas of the business. And they understood what they were looking for. So job descriptions got better. The proliferation of copy-paste of the skill sets that we were hiring for, I see them now everywhere. So now we have data scientists in the aftermarket side, in the marketing side, in finance, for sure. And they might not be labeling themselves as data scientists, but the practices and the conversations we have when we get the data community together are very much of those that have the same literacy and skill level. So now I can say we have them everywhere. They just look a little different.

How do you get the data science community together? Do you have some internal group?

We do. COVID ruined a few things. Among those, what we used to do every year, we call it DTNA. That's the acronym for the company, DTNA Data Day. And purposely, it's never been a day. It's always been two days. And everyone's thrown off because they're highly quantitative. And they're like, it's data day, but it's two days. And then that's the conversation started. But we used to get everyone together. And my team was the driver of it. And we would get speakers. But then we would be all over the company connected with people and finding what is something that you want to tackle. You want to work in session? You want to proliferate knowledge in your area? What can we do to assemble interesting topics? So we would do that.

Nowadays, with one of my responsibilities being the corporate data catalog, we change a lot on our data stewards community. I have a couple of things I believe in, like having the latest and greatest version of our software, deploying benefits and improvements and things like that. So those are drivers for me to keep the community alive and growing and using the data catalog as we aspire it to be. So that's another forum where we get not only the data scientists, but the data thirsty, let's say.

And what is the data catalog again? It's the brand. I don't know if I should say the brand or not. But imagine that you have Brazilian databases and schemas and all this stuff, right? So when you're trying to deploy your RStudio into a database with the ODBC, you kind of want to know what's in it. And instead of just going in there and trying to read all these columns and get samples of all this data, you can go to the catalog. And the catalog is a mix between maybe I'm dating myself, but the yellow pages and Yelp, right? It's structured, organized, it has content, but it also has recommendations because over time data gets copied or federated or what have you. For your use case, you might be looking for a specific transformation of the data. And if it's Yelp style, you know that it's being used for a prior case, or you can look at queries that have been used to create a report for XYZ. And that's the community piece of the data catalog.

Lean and data science

It's very interesting, because from lean and Six Sigma, it was about what's being, first of all, is a process what it directly needs to be. And lean, you're always in recovery afterwards. Because you think about data flows and transformations and the stages of data. So if your data is not reliable, your analysis might have lots of holes in it, right? So that's kind of, I think, the first leap of faith between data and data science.

And when I was coaching some of these teams, I'll give you an example. We were working in one of our manufacturing sites, and we were working on a question of interest, material handling and receiving. And it was like a lean driven approach, right? Are we doing the right things for the right size? But then we're getting to the quantitative piece of it, and everything was kind of out of whack. It just didn't look like anything, right? So I was telling the team, why don't you look at the data acquisition piece, right? We have three shifts, and it turns out that some of the people in one shift were using four or five out of a 12 shortage recent codes. And then along comes the second shift, and it's always the most stressful one time-wise. So they were dumping everything into one. And then the third shift was like, sometimes we're like, well, we'll just leave it to first shift to do it, right? So you're supposed to be capturing the data of the recent codes of why you're having shortages in 12 different categories in three different moments in time, and they were totally uneven. They weren't really driving the learning we needed. So that's where lean behavior leaps into the data quality, which leads into the data science analysis possibility without the data being skewed already by acquisitions.

Advice for new data science leaders

I would say challenge yourself to be as smart and clever as your team is. People are asking me, you already have a master's, or you want another master's, and this and that. I'm trying to do this very smart thing and attract very smart people to create a team. And if I don't understand and I don't expand my mental model, I can't meet them at the same spot, right? So being intellectually curious, and it's not that you have to know more because you're the boss. It's just that you have to know a little bit more. It's not that you have to know more because you're the boss, but it's so that they find your pursuit and they find that their knowledge is valuable to the point where you don't mind spending a couple nights a week learning more and understanding more and having much more depth in the conversations.

It's not easy. And I remember I did this to my own boss where I said, look, we're going to start working on this project. I'm going to come out and tell you it's going to take me two months, I said. And you're going to say, great. And I'm going to go away laughing and say, hey, I have no idea what I'm talking about. And he's like, really, would you do that? I said, well, not me, but you're going to have more people working with this team eventually, different leaders. So at the end of the day, he ended up joining me and taking a Python class with me. And we did homework together and we challenged each other, but he was understanding that in this new era of data currency, really the throughput conversations we had had nothing to do with just pure effort. There's so many more variables that go through it. And he was humble and wise enough at the same time to pick that up and turn out to a great role model for me, for people in his peer group.

I would say challenge yourself to be as smart and clever as your team is. So being intellectually curious, and it's not that you have to know more because you're the boss. It's just that you have to know a little bit more.