Machine Learning Zoomcamp: Free ML Engineering course. Register here!

DataTalks.Club

Articles Slack Events Podcast Books Courses

Becoming a Data Science Manager

Season 6, episode 9 of the DataTalks.Club podcast with Mariano Semelman

Did you like this episode? Check other episodes of the podcast, and register for new events.

Transcript

The transcripts are edited for clarity, sometimes with AI. If you notice any incorrect information, let us know.

Alexey: This week, we'll talk about the role of data science manager. We have a special guest today, Mariano. Mariano is actually my colleague and works as head of data science at OLX group. I think Mariano joined quite a while before me. You've been with OLX for five years, right? (1:26)

Mariano: Yes, almost five. (1:45)

Alexey: When I joined OLX, Mariano was a senior data scientist, then I saw him transition into a manager. Then after that, he became the head of data science. Mariano has 13 years of experience, almost 10 of them were in data science. He's originally from Argentina and then moved to Berlin. Now he lives in Barcelona. Also I have here in the notes “And he's obsessed with…” And then it's unfinished. [laughs] So I don't know what you’re obsessed with. (1:48)

Mariano: With product applications. Yes. I am obsessed with the application of data science. That's the area that I enjoy the most. (2:20)

Alexey: Okay. Welcome to our event, Mariano. (2:30)

Mariano: Thank you, Alexey, for having me. I think it's going to be strange because I know you. Thank you so much for having me. It's an honor for me. I think you're doing a great job with DataTalks.Clubs. I think it was the anniversary very recently, so congrats on that. I'm all yours. You're the driver now. (2:35)

Mariano’s background

Alexey: Yeah, indeed. Actually, I wanted to get somebody on the DataTalks.Club podcast to talk about the experience of transitioning from an individual contributor role to a managerial role, and I couldn't think of anyone better for this conversation than you, Mariano. But before we go into our main topic of becoming a data science manager, I wanted to ask you about your background. Can you tell us about your career journey so far? (2:59)

Mariano: Sure. I'm a computer scientist and went to university for this subject. I did a Master’s back in Buenos Aires a long time ago – more years than I would like to say. But I was already working as a software developer, more or less, at the same time that I was doing college. I started working first as a data analyst, then as a Java developer, web developer. I even took a shot at mobile games. Data was my passion and within my Master’s, and I focused a lot on that and ever since. (3:27)

Mariano: That's how I jumped into applications of data science in the industry. Mostly because I found it more attractive to work with something where you could experiment very often, and if you made mistakes, it’s not so good. The targets were very clear and we had checklists. I found it very assuring. Then, I changed companies twice, but I was always working in the area of data science – things around personalization, recommenders, marketing, segmentation, etc. It was always around ecommerce, you can say. Most of my experience is in ecommerce. (3:27)

Mariano: Then I tried OLX almost five years ago and I had an amazing experience. I moved across three countries and worked with all types of people, cultures, projects, endeavors. It was super fun. So that's my summary. Please interrupt me, because you know me very well – I can go for hours without actually talking about anything, so. [laughs] (3:27)

Typical day of a manager

Alexey: [laughs] I was thinking “Okay how am I going to stop you?” [laughs] I’m just joking. Tell us a bit more about what you do as a manager. What does your day look like? (5:45)

Mariano: Meetings. [laughs] Okay, not only meetings. There is a huge component of spending time with people nowadays. More than I would like to say. Lots of meetings. But it's mostly because they are required, not very necessary meetings. But you need to spend some time with people. Also working on reviews and planning of code projects – everything around project management. OLX is a very large company, so some of the time goes on writing a combination of reports and proposals – everything is very well documented. So some time goes on that. The largest component and one that I enjoy the most, is mentoring, coaching and people development – making sure that you help people keep growing and being the best professionals they can be or they want to be. I could go deeper but I think that summarizes it. (6:01)

Alexey: That's quite a lot of responsibilities. (7:24)

Mariano: Yes. It takes a bit of energy but it's good energy. It pays back. And I’m not talking about monetary gain, I'm talking about the everyday rewards and the satisfaction of doing it. It helps to do it. (7:27)

Alexey: How large is your team? How many people do you manage? (7:51)

Mariano: It's always changing. I think when I started as a manager it was five, then seven at some point, then four. Now I think it's eight-nine people. They all have different seniority levels and roles. We have data scientists and machine learning engineers. We have junior, mid and senior levels in all the roles and each of them cover different topics and aspects that are collaborating with the rest of the company. (7:54)

Becoming a manager

Alexey: You said when you became a data science manager, five people reported to you – you needed to manage five people. That's quite a drastic change from having zero people reporting to you. (8:39)

Mariano: Yes. I had some experience before that. Not experience that I would put on my resume, but I had some experience mentoring and project management with two people. It was ‘light level management’ because they were not reporting to me. Jumping to five was a stretch and I had to learn a lot. It was a lucky thing that I had many people to support, mentor, and guide me. I took an approach of presenting myself as somebody who was learning. I was doing my best to help and learn on the way together with everyone. By no means was I planning to make drastic decisions and things like that, without consulting someone first and discussing it with the team. At the time I was relying a lot on other people to do it. But it was good – I like that I got to work with them. During my first year, when I got my first experience, I was super lucky. Even though I didn't choose the team, I was super lucky with the people I got to work with, because they helped me. I helped them and they helped me to grow. They were very experienced data scientists. So it was a very good experience. (8:55)

Alexey: Do you remember how it happened? I guess our manager came to you and said, “Hey, Mariano. What do you think about managing five people at once?” How did it happen with you? (10:40)

Mariano: Very good question. At that point it was more like, “Are you interested in this? It will help the company a lot.” It was with my current manager, Andreas, who said “We need to start growing the team and have more people training.” It’s impossible after seven or eight people, it's super hard. It’s too much, because you’re already distributing your time across many people and the quality starts to drop. That's something you learn after a certain amount of people that you manage. It's very hard to give your all to them. Of course, with more experience you can do it better, but there is still a limit. So, it was like that. And I said, “Okay, let's try it.” At that point, I was having a lot of fun in the company. I still do, but at that point, I was super excited about absolutely everything. I was in the company for one year and I had just moved from Argentina to Berlin, and I said, “Yeah, let's do it.” Summer helped a lot. In summer, you feel much more energized. So yeah, I jumped in and said, “Yes, let’s do it.” (10:51)

Preparing for the transition

Alexey: So you agreed and then the next day, you woke up being a manager with five people reporting to you? What was the first thing you did when you found yourself managing a team? (12:38)

Mariano: I think I got to know about it a few months in advance. Until it's announced and doesn’t actually happen, you don't know if it will happen. As soon as I knew that they wanted to put me in the position, I had one month or so to prepare myself. Luckily, I was on vacation as part of that. I was so excited and used, not a lot, but maybe one or two days of my vacation to write down my ideas and think about what will be my first few things that I will do – how will I structure my work. What I learned at that time was that there is this practice of the 30-60-90 days to write your plan. I'm not recommending to always stick to that, I’m just saying that it should be the way to do it. But it was a nice framework to follow and to structure your plan like “Okay, what I will do in the first 30 days, the first 60 days?” (12:52)

Mariano: In the first 30 days, I was meeting all of the people in the team, having one-on-ones with all of them. I started reading a lot about management tips. I didn't drown in it, but I was trying to see things here and there – things that I shouldn't forget – especially what to do from the technical point of view. Later, it was learning about all the projects they were working on. It didn't have to be super-detailed but I thought I understood enough to help them make decisions. They want somebody they could count on to make decisions. (12:52)

Balancing projects and assumptions

Alexey: How did you organize that? Did you ask them to onboard you? Did you go through the code? What exactly did you do there? I don't know how many projects there were, but with five people, I imagine it was like three to five projects for you that you maybe didn't know about before that point. (14:57)

Mariano: Maybe more. It was people that were already in the company for some time, so all of them have at least one active project, plus one, two or maybe three that they have already put in production at some point, and were maybe maintaining them. It was a bit of everything. For some of them, I asked them to onboard me, maybe to spend one hour explaining things to me. I remember, Piotr, who is still in the company – I don't know how patient he was to explain everything about advertising. He threw stuff on the board and explained what they were doing. It was very, very challenging, because it certainly requires a lot of agility. I thought I was super fast, because I could jump into any project and learn it fast and do it. But sadly, I was onboarding on two, three, four projects at the same time. So I had to be super fast. (15:16)

Mariano: An important thing to do was accept that you won't have all the information. Of course you also need to trust the people. They are the ones doing this, so if you have an idea, you should always start with the assumption that you may have a total misconception of how the application, or the project, that they’re working on, works. So may start your phrases with something like “Based on what I understood… because I think maybe this could work.” Maybe you're starting with very wrong assumptions, because while you’re learning things, you have very partial information. So for me that was important. (15:16)

Alexey: Do you remember how many times you were wrong in your assumptions? (17:22)

Mariano: Many. Even up to this day, I'm usually more wrong than right. But I don't stop proposing because even if it's wrong, it triggers a discussion and I think it structures knowledge around the topic. I'm okay feeling stupid all the time as long as there is a flowing discussion and we think about all the problems together. Because when I ask a “stupid” question, the team will explain to me, “No, you're wrong, because it’s not that, it’s this.” (17:26)

Alexey: Then you learn about the project more, right? (18:12)

Mariano: I learn and based on that, they can think of an alternative solution. Also because I start with the wrong assumption, sometimes I bring a solution that’s out of the box. I think of something in a different structure and that triggers a process - they laugh, but then they look at the idea and say “If this were different, this will work. So what can we do to make it to that?” It's more like that. I'm not shy when it comes to seeming stupid in front of people that report to me. Something I always say is that data science is an area that everybody specializes so much. Everybody works in such specific domains. It would be super arrogant to say that you know everything you're working with. (18:15)

Mariano: I think that anybody who is a specialist in data science knows that they're specialists not because they know all of data science, but because they are able to learn new things and adapt. But there is no way to know everything. Being a manager actually gives you less knowledge, because now part of your time is not on the technical aspects, but the people and the processes. You have to pay attention to all those areas as well. (18:15)

Search and recommendations

Alexey: Did I understand correctly – I know before becoming a manager, you were a senior data scientist in the relevance team, so you were dealing with recommendations mostly, right? (19:46)

Mariano: Yeah. It was mostly everything around search and recommendations. At OLX, which is an online classifieds place where people come to buy stuff, so from the moment the user comes to buy, they have three ways to find things, more or less. Maybe a few more than three, but let's talk about the main ones. One is navigational – where they go through the categories and start applying filters. The other one is through the search bar, which is one of the areas where we do the most applications – around the search. And the other one is through recommendations – when they’re on the homepage, when they navigate and see “More like this”. Or even when you reach the end of the results for search, what we recommend so that you keep searching. These are more or less where I was strongly experienced in, at least for the last few years. (19:57)

Dealing with unfamiliar domains

Alexey: So the people you needed to manage were working on advertisement projects, right? (21:04)

Mariano: Yes, in a very specific area. (21:12)

Alexey: It was about real time bidding and these types of things, right? (21:14)

Mariano: Kind of. It actually confused me a lot because I didn't know this thing beforehand, at least not in detail. That was my first “Aha!” moment, because I assumed it was the team that we were using to do publicity for OLX – to send traffic to OLX. But no, it actually was the team that managed the spaces we sold at OLX for third-party advertising on our platform, how to optimize the different areas. This involves things like how to do what's called “geo match,” how to personalize, and how to have better performance of the campaigns that are sold at OLX. That was really super new for me and I had to start doing a lot. (21:19)

Alexey: So you knew nothing about this domain, right? (22:25)

Mariano: No, not at all. Like they say in Spanish, I was with a parachute landing, you know? Improvising. If Pawel and Piotr are listening, my apologies. It was hard for me. (22:30)

Alexey: So it was quite difficult for you to get. Not only did you need to learn everything but you also needed to manage people who are doing things that you don't know much about. Right? (22:55)

Mariano: Yes. Then it becomes a little bit of extrapolating the learnings you have as data scientists to other areas. Because some things are different, such as the domain, and maybe some of the models. Not all of them, but some of the models. But there are also things that don't change. The structure of a machine learning project, making sure that you correctly define the problem statement, what type of problem you have at hand. As a basic, is it regression or classification? But even later, things like – supervised/ unsupervised. But even inside those categories – what type of problem are you solving? What are the caveats? Because not everything falls into boxes automatically. Even if you want to say “Oh, this is such and such a problem.” Sometimes you can change the lens and it still works. So, this part is still the same. (23:09)

Mariano: Feature engineering also stays. Maybe a few new techniques here and there. Also, the whole evaluation and connecting to KPIs – the monitoring, the alerting, etc. There are many things which are common to any data science project. Also, how to drive the hypotheses. When you are dealing with a problem and you're stuck, and you need to improve. “Which hypotheses to rise? How to answer them? What things to check? How to prioritize work based on impact? How to drive analysis in order to decide what to test next?” Those things –that exercise – stays similar across projects. Of course, coming up with ideas and questions, it's always super hard. I'm not saying it's easy, but I'm saying that the process of which stage to watch, that helps. I always guide people in this direction. I think that should help them. (23:09)

Structuring projects

Alexey: So you were coaching and mentoring people more in the direction of how to structure projects, how to approach this, how to actually form the problem that you have in machine learning terms, and then measuring and all that. So it’s more about structuring your approach. Then you leave the domain knowledge and actual modeling to your subordinates. (25:55)

Mariano: Yes. For example, let's say that the end performance is not good enough. Then we must first figure out how to ask the right question. “Is it an overfitting problem? Not enough data? Model not strong enough? Is there a difference between test sets and production data?” I first help find answers to all these questions. Then once we identify the problem – let's say we are overfitting. Then I help with all the ideas around overfitting, all the tools we have at hand to fight overfitting depending on the model, of course – undersample/oversample, regularization, etc. Even feature engineering sometimes, or getting more features – things like that always help. (26:16)

Mariano: Or let’s say the model is not strong enough, or the model is not learning, “Okay, what data can we think of?” Think about the domain. Sometimes it's better not to think from the model point of view, but think, “Okay, if I'm the person that needs to decide whatever.” Because I always say machine learning is an automatic decision system. At least in the way we apply it – state the problem, apply automatic decision systems. I wouldn't put this in a book – it's an oversimplification. But if that machine has to make a decision, what extra data can you provide? What extra piece of information are you going to add to help that decision? For that, you need to think a little bit like, “Okay, if I wasn’t working at OLX, and I needed to ask for information about something to make a decision, what information would I look for to make that decision?” (26:16)

Mariano: Then we can take out the domain – “How to model that? How to get the data?” Because that's always super hard. Then the other part that I also help in a lot is navigating the organization. That's the part that is not so much data science, but it's more of a soft skill or a people skill. So you're working on this problem and you need this amount of data to integrate to this system or figure out how this part of the system works. So you have to make the connection and make the conversations happen. In the real world, things are not always super perfectly documented, or it’s not perfectly clear how things work in a company as big as this one. Sometimes it's challenging. (26:16)

Connecting product and data science

Alexey: I think one thing you didn't mention is that you also help a lot – from what I see – is connecting product people (from product management) with data scientists and helping them by becoming a translator between them. That's something that is quite important. Sometimes data scientists, as I remember myself, tend to work on things that do not necessarily make a user impact. They're just fun to work on. But then product managers come with some ideas and you have to figure out how to connect these things. (29:29)

Mariano: Yeah. Maybe I forgot to mention this. If I can choose one thing to call the “key to success”, that would be the obsession with product applications. What I mean by that is – making sure that the data science solution is impacting the final user. That it’s helping someone – that somebody gets a benefit out of your work aside from just yourself. That somebody will receive this cool, almost magical thing that is data science and solve one of their problems that otherwise would be much more complex. (30:06)

Mariano: I think we are all living it every day, when you see something like how Google can find all the pictures of your cats. I couldn't do that even if I wanted to. I would have to go through all the pictures I have of my cat. It changes in your life, because now you can see a collection of that. Or even better, like all the pictures of my mom. Now I can see them all together and that's so nice. I like to see so many memories. Well, I want to achieve the same on paper. I want to create these “aha” moments, like “My life changed because of this.”Maybe not change, but at least so it seems that life is not so short, or not so mundane. I think that drives me. (30:06)

Mariano: Another thing that I put a lot of my mind to is, “What are the steps? How do you get from this to this?” Let's say I start with a data set and I’m optimising ROC AUC. And then all the work we do to start making an impact with this model. There is a huge gap between that. You have a pickle file or you have a TensorFlow model, and then what do you do with it? You're not gonna give it to the user. You cannot give a pickle file and expect them to ship it. So yes, you have to think about how to connect it. There are normally iterations of a product’s campaign. Experiments are one of the key words here – go and test your things quickly. Start with a very simple thing. If I can recommend one reading today, it would be – for me it’s very inspirational – “Rules of ML”. I think it's something Google shares a lot. (30:06)

Rule of Machine Learning

Alexey: Do you remember the first rule of machine learning? (33:24)

Mariano: Yeah, I think it's “Don't hesitate to try and use ML.” Right? (33:27)

Alexey: Yeah, I think it's something like, “Don't use machine learning” or “Start without machine learning.” (33:32)

Mariano: Yes. And I get tired of repeating that, especially with more junior people who come with lots of ambition. I see myself in their place because I was also there. There’s the thing when you go to university, and they tell you “Now, the first year, you're not going to do programming.” You reply “But I came to study programming.” They say “No. In the first year you will be doing math.” So you say “But I’m a programmer.” Sometimes the project, when it starts, doesn't need the model – it needs everything around it. It needs getting the data, a good evaluation metric, a system to connect it to the user – a way to experiment, or maybe try it. A very simple and maybe poor pipeline, but something that you can run a few times right and reiterate. It's really not productionized but something that you can use. (33:36)

Mariano: You want to fail fast. You don’t want to spend too much time on it. The risk is too high. If you said “in 6 months” and we all think “No.” In any project where the product manager asks “How long is it going to take you?” And you think to yourself “I want to have a very good solution. It will take me two months.” No way it will take two months to finish something. If you think that you are going to work for two months, it's going to be six because you will just spend the first two on getting the data, modeling, and making a small demo. So it's better to start with the simplest model you can do and connect it to this and in the first two months, you will see even a drop – that's okay. Now, you can measure that drop. (33:36)

Mariano: Once you have a better model down the line, that drop you made can be the baseline. You will be able to measure it. From modeling to testing in production, it won’t take you any time. You code, you work on your model, you test it. Is it a green light? Okay, green light to test. Then you go to test in production and you can decide then if you want to move forward or not. Then you have these incremental gains. I haven't read many books about Agile and data science. But maybe you have one to recommend? If you had to recommend one, Alexey, what would it be? (33:36)

CRISP-DM and deployment

Alexey: I like CRISP-DM, but there is no book. It's just an article in Wikipedia. I think there is a book, actually. But anyway, I like this process. It's a very old process – it’s like 20 years old or something like that. Surprisingly, it's still valid today. All these things like business understanding, then data understanding, then data preparation, then modeling, evaluation, and deployment. I think it's still valid today. I don't know where the IBM folks deployed it 20 years ago and what they used for that. (36:12)

Mariano: Java was already there, so the concept of deployment was there. Once you get through the technical challenges of doing data science – you know how to code, how to model, you understand how to evaluate – you cover at least on the basics. There is always time to learn very complex modeling stuff. But whoever is doing data science will tell you in our company, the modeling part is no more than 5-10% of your time. Of course, I'm talking about a year average, maybe there is one full month that you're doing modeling. But all in all, you will be doing a lot of understanding the problem, getting the data, connecting it to production. That's the most time-demanding. (36:50)

Mariano: Once you get through this technical challenge, for me, the next thing is learning this. Because you spend so little time on doing the modeling part that you better spend it on the things that are going to be impactful. You have limited time to work on the model part where it shows. There are so many things to try. It's a very deep area – there are so many things to try and to experiment. Prioritizing the right thing to do at each point in time, for me, is what differentiates the good from the bad data scientists. There are many scientists that will know how to do each of the possible things you can do. They know how to model, they know all the possible layers, they know all the possible techniques for cross validation, hyper parameter tuning – they know end-to-end all the modeling parts. They have no problem with that. (36:50)

Mariano: But then they struggle a lot on deciding what to do. Which part should I be prioritizing at some point in time? For me, here it goes back to identifying the problem. You start with the problem – what problem do you have? Then you do the experiment, you see what you saw in the experiment. Then you translate that. You bring it back all the way to – at which stage will you have the most impact on that problem? And you apply it there. (36:50)

Alexey: That's great. As a manager, you help people with this process – you help them stay focused on that, connecting it with the real problem. Then sometimes, I remember I was also in one of these projects where you would say “Okay. Hey, enough. Let's focus on actually integrating it with the product and then making sure that this is getting consumed and then iterating on that.” I think this is quite important that somebody tells you and then I think “Okay. Yeah. That's correct. I should try to wrap up and start iterating.” That's one of the things you're doing, right? (39:44)

Giving feedback

Alexey: You were talking about this 30-60-90 technique. When you were talking about your process of transitioning from an individual contributor to a manager, you said that in the first month, you wanted to meet the team. You were meeting the entire team and you were doing a bit of reading. Then in the next month, this is the 60 part – midterm – you were trying to get onboarded and understand all the projects that the team was working on and also learn a bit about the domain of these projects. I wanted to ask you – what was in the third month – the 90 part? (40:25)

Mariano: Okay. While you're telling me this, I went and opened the site because I couldn't remember. But here it is. In the third month, I did feedback. Because there was no point for me to give any type of feedback until spending at least one quarter there. I didn't give lots of feedback at that point. It wasn’t critical. I think everybody was working fine at that point. But I took the time to give back what I think was my opinion. But I delay that until the very last place, because I wanted to make sure that I have a full view of the situation before giving any type of feedback. (41:10)

Mariano: I saw myself the other way, like you do in some things. All of us have had managers, right? All the time I compared “What would I like in this?” I put a little bit of my personal touch. I treat people the way I would like to be treated. Because I don't know, it feels fair. Or even, of course, treating people better than I would like somebody to treat me. I don't like somebody coming in the first two months and telling me the things I did wrong. No because I'm not doing them, but it feels like somebody is judging you by the cover. You want to spend some more time – maybe 60 or 70 days are not enough. But I already felt after one quarter of working on projects, I've been able to do iterations, on working with OKRs, and seeing how the team performs, on how they were structuring the projects. At the time, it made sense to already give some hints and start working on that. (41:10)

Alexey: So it was feedback, right? In the last month of the 30-60-90. So you were giving feedback to the people. (43:31)

Mariano: Yes. Even if it was not bad. But I was giving my opinion on what I saw so far. (43:35)

Alexey: How do you give feedback? This is not something you know how to do as a senior data scientist. Well, sometimes you do, but this is not the main responsibility. But as a manager, this kind of becomes your main responsibility, right? How do you approach giving feedback in such a way that people can receive it and not become defensive? Because this can sometimes be a challenge, right? (43:47)

Mariano: Well, it first depends on the person. It depends on how you are, how the other person is, and what the feedback is. But there are three parts of the communication. But I had good mentors. One of them told me that, especially when you're going to give feedback that you do not feel comfortable giving, the first thing you ask the person is if they are interested in receiving feedback. You have to start the conversation with “Are you interested in receiving feedback?” “Yes/No” Some people just don't like it or don't trust you, especially the very beginning. Later on, you build up trust. But at the beginning, maybe you have to ask. (44:17)

Mariano: Aside from asking, you have to care about that person. You're giving that feedback because you care about them. Because you think it will make them better or that will help them. That already puts you in a better position where they will listen to you. But you never give feedback like “This is what you have to do.” Except for very clear things like if somebody is behaving in a very unacceptable way. But that happens rarely. I think in over three years, I think I saw it just once. You don't have to really even think about it, you just have a one-on-one and say, “Don't do that.” That's the easiest feedback to give, when somebody does something that is unacceptable for a professional. (44:17)

Mariano: For giving tips or feedback on things that you think are harming that person’s progress, you should start saying that it's advice. It’s something that you feel could help them. You say that may be wrong. Just because you're a manager and you're giving feedback, it doesn't make you right. When you start like that, at least for me, I say it because I feel that way. I’m giving them my opinion on what I think. Of course, I won't lie to you – the opinion of your manager also impacts your professional career. It's impossible to deny it. That’s how things flow, unfortunately. But that’s not the main point – you do it from the point of view that you care, and you open the possibility that you may be wrong with the feedback. You give them the space to think about it, and to see if they reflect on that – if they think the same – and if you think it will help them. Maybe too generic, maybe we can do an exercise and give it with a concrete example. I don’t know if it's the objective of today. (44:17)

Alexey: Basically, it boils down to caring about the person. When you're not close, maybe in the first month, you ask them first and then I guess the rest just happens naturally, right? (47:50)

Mariano: Yeah. Giving feedback often also helps. (48:07)

Alexey: Having regular one-on-ones, right? (48:10)

Mariano: Yes, one-on-ones. For me, as I mentioned, I believe they should happen at least once a week. Of course, with every single person, maybe 15 minutes to catch up once a week, that's fine. You may feel compelled to skip it if there is no topic to discuss. But there is always something to talk about, even more with remote setups. Even just to say “hi” and see how the person is doing. People go through personal matters all the time or they may feel like they're trapped in everyday work and in problems. I always have this philosophy – the same one as I told you – I treat people the same or better. (48:13)

Mariano: The other one I have is – people spend a huge percentage of their conscious life at work. So it has to be not just a nice place, it has to be a place of growth. It has to be a place that in some way feels like a game right? It's not a game, but I mean – suppose you can make mistakes and they are not so harmful. In your personal life, making mistakes is much more harmful. While at work, you can always change your work or change the theme or start from scratch and change the project. Making mistakes at work is a safe place to do it and it should be, plus learning from those mistakes. I feel that it's a place to learn a lot, not just about your profession and also life. Like how to relate to other people. (48:13)

Dealing with people leaving the team

Alexey: That’s nice. I noticed that last time I checked questions, there were none. But now I check there are four. So the first question is, “What's the hardest thing you need to deal with as a manager?” (50:21)

Mariano: I'm thinking. I think there was more than one. I can tell you – losing somebody in the team that was very close to the team. Sometimes there are people that come to the team or maybe they'll completely evolve or not. When somebody is very good and brings that team spirit. They work to make sure that, not just themselves, but everybody around them has a better time. Seeing them leave is super painful. You never get used to that. (50:39)

Alexey: How do you deal with this? Just accept that people move on? Is there any other way? (51:35)

Mariano: It’s the same as when you give feedback. You wish them the best. If they choose to leave because they think it's the best for them, you support them. I think a person makes their life choices like this. It’s what a manager should do. Sorry, I got emotional [laughs]. Who asked that question? Yes, that's one of the hardest ones for me. (51:43)

Doing technical work as a manager

Alexey: Yeah, I understand. Thanks for sharing. “Do you have time to do technical work as a manager or not at all?” (52:28)

Mariano: Well, it depends a lot. The straight answer is – mostly not. You shouldn't be on the critical path of any project. No project should depend on your work. Your role as a manager is unblocking, facilitating and making sure that every project is on time and people can work easily. So, if you say “No, I will work on the most important parts of the project, step aside, wait for me.” You will have something pop up because you are the manager – there is always something that pops up that is urgent. So you cannot work on that. (52:37)

Mariano: But you can still do a lot of things. You can do prototypes. You can participate in the merge request and review a lot of code. I read a lot of code. I spend a lot of time reading. Instead of reading Twitter, I read code every morning. That was something I also showed you a lot. Without humbleness, I can say that I can read code fast. I like navigating lots of code. Whenever someone in my team is coding or some other team is coding, I will jump and read a lot of code, make suggestions, mention libraries. Of course, not as a blocker. (52:37)

Mariano: I usually try to make suggestions or things like that. For people, of course, I will mention things I think they should be improving. Not things that I want to see, but things that I think they will benefit from. Because if you have coded for some time, you know that you hate your code in six months. So I just give tips so they hate it less in six months, from that point in time. I try to help them that way. (52:37)

Alexey: So you mostly spend time reading code, giving feedback on code, then sometimes prototypes, but mostly code. Are you also involved in architectural discussions? (54:45)

Mariano: Yes. For example, now in my team, I have some machine learning engineers that are quite senior. They are very good. So I rely more and more on them. For example, they do quite a big chunk of that. But at the beginning, yes, I was working very, very close to that area. I used to write, but there are more people that can solve it on their own, and they create very good solutions. But even better than I can – way better than whatever I can say. (54:58)

Dealing with bad hires

Alexey: Okay, yeah. Thanks. Another question we have is, “How do you suggest managers should deal with bad hires?” That's a tricky one. (55:38)

Mariano: That’s a tricky one. Yeah. It's always a dilemma. Of course, I will say something that will make whoever asked the question hate me. But the first thing to do with a bad hire is have very good interviews. It's better to take longer to hire somebody, but to be super sure that that person will do well. Even at the expense of having longer interviewing processes and losing candidates because they're accepting other offers somewhere else and you took longer, than to be in a situation where you’ve got a bad hire. Because you lose more time hiring somebody and onboarding, and then realizing they're not working, than having to interview the total amount of people. (55:48)

Mariano: Once you have a situation that already happened? That depends on what the probation period in the country is. Every country has a different probation period. But let's say if it's Germany, which has a six months probation period, which is huge. If you have such a long probation period, then at three months, you can already do an evaluation. At that point in time, that’s what you can do if you think it's not working. Or even if you think it's working. But if you think it's not working, you say, “I think it's not working because this, this, this. I think you're not on time. You call this off, etc. It’s not working.” For the people that are performing, you also give them “You're doing fine.” People are already stressed on the probation period, so it's good to give them reassurance if you think you're doing fine. There is no point in people feeling without confidence if they're doing fine. (55:48)

Mariano: If it's a shorter period, then make sure to do an evaluation like one month before. And don’t just give feedback, but also do what we call at our company “a development plan” – other companies have similar things. “These are the things we think you're not doing well,” I say as a manager, “You can improve them by doing this.” So you give them some suggestions. Not things that they have to do, because everybody learns in a different way. Some people prefer courses, some people prefer hands-on, some people prefer a mix or being mentored, somebody teaching them. But at least it's not just saying what's not working – it’s also giving them some possible path, and opening the doors for them to figure things out. You can think about it together regarding how to improve on those things. (55:48)

Mariano: If there are signs of improvement and you're willing to wait, then the person can keep improving. But if there are no signs of improvement after the probation period, then you have to stop the relationship, unfortunately. It's best for both parties. It's not only good for the company, but it's also good for the person because, otherwise, they will stay in a situation where they are always underperforming and they will end up with a stigma. They're always with a stigma of being the one that doesn't perform. They cannot grow in the company easily later on because there was a stigma that you started out super bad. (55:48)

Mariano: If it's much later than the probation period, that's even trickier and takes longer. Of course, I always say it's very important to give people the opportunity – you have to give this development plan and work with them, spend some time. It's the kind of situation that demands the most amount of work, in comparison to the results, obviously. But it's gratifying in the end. When people react to that and start working, it's quite gratifying. It's a good situation. Not everybody is super performing all the time. It will happen at some point of your career that you are under the expectations. So it's good to have a heads up and somebody to hold your hand for a bit and show you the path. I think that's good to have a manager doing that. (55:48)

Alexey: Yeah, it's nice to have a manager like you. (1:01:00)

Mariano: By the way, you have to ask my team and not me if I'm doing the right work. (1:01:05)

Alexey: [laughs] Exactly. Maybe for the next interview I'll invite somebody from your team. (1:01:11)

Mariano: [laughs] Yeah, I could be just saying anything, you know. (1:01:15)

Alexey: Do you have time for one more question? (1:01:19)

Mariano: Sure. I'm all yours. Yes. (1:01:22)

Keeping up with the industry

Alexey: How do you keep up with the latest advancements in the areas that you work in? You need to guide the team, so how do you keep up with the latest developments in order to be able to do that? (1:01:24)

Mariano: Yes. Good question. Well, I was asked this question in the past. For me, there is no recipe. It’s something I have greatly internalized, because I learned it the hard way. Except when you're working at big companies, the Microsoft, Google, Facebook, Apple of the world, right? Or if you’re working on something very niche or very AI specific, – like an AI-centric company. I don't try things that have not been proven before. It's not that it has to be exactly like something that somebody already did before, but I usually try things that certain conditions don't allow. But I usually like trying things that some other company in a similar domain have tried in the past. (1:01:37)

Mariano: Something I really like to follow very closely is what other companies are doing with their data science team – what's working, what's not working for them? Whenever I see that they're using something new that they were not using before, that I am not aware of – then I want to study it. I’m also particularly interested in NLP. I really like it. Whenever there is something new, like ELMO at the time now BERT and transformers, or other pre-trained things. I try to say, I'm not cutting edge. To be honest, I don't need to be. For the modeling part, I'm not cutting edge. But for me it really pays off to be more cutting edge, or being on the latest developments, around the engineering point of view of data science. That way I think where we're delayed, as far as I know. Our trade – the world of data science – is past due at least five years with practices. As a profession, it grew super fast. We now probably have 10x the amount of data scientists now then what we had five years ago. The practices that work in such large teams across the company are adapting all the time because it's something new to work with so many data scientists. So that's the only thing I keep super up to date with – what we call ML Ops, maybe? I think we have talked about this a few times with Alexey. (1:01:37)

Alexey: Yes, we discussed “What is ML Ops? What is not?” But basically it’s productionizing in machine learning, right? Also all the processes and how people communicate, what the process looks like, what the tools that we need to use are. (1:04:37)

Mariano: Yes, exactly – the systems around the processes and how they all shape each other. How the systems support the processes to make it easy. We know that things are simple to use, but at the same time they help you and they help you with a process – they make an efficient process, but they are not a pain in the ass. I am very allergic to bureaucracy. When the process takes you more time than the thing you're actually doing. For me, it's not work. (1:04:51)

Wrapping up

Alexey: Yeah, I just took a look at the questions that I prepared for you and I realized that I count only like 10% of them. [laughs] (1:05:35)

Mariano: That's my fault. [laughs] I told you, I speak too much. (1:05:44)

Alexey: No, but like we actually diverged and I think it turned out to be better than what I had in mind. So yeah, thanks a lot for joining us today. Thanks a lot for sharing your story with us, for sharing your experience. Also, this 30-60-90 thing, I think it’s useful. Actually, I've talked to you before I became a manager and did that thing as well, when I was doing the transition. So thanks a lot. And thanks, everyone, for joining us today, for asking questions. I should have started asking questions because we still have a couple of left. But maybe we will keep them for some other time. (1:05:47)

Mariano: We can do a follow up or with another manager also. (1:06:28)

Contacting Mariano online

Alexey: Yeah, perhaps. Okay. Thanks, Mariano. Thanks a lot. Thanks, everyone as well for joining. By the way, I wanted to ask you one last thing – how can people find you if they have a question for you? (1:06:31)

Mariano: Ah, okay. I think the best way would be through LinkedIn or my personal email. My LinkedIn ID is M Semelman. You can find it like that. I think we were talking at the beginning, right? If you just Google my name and I’m only one. I was lucky and unlucky to have a very strange name. (1:06:45)

Subscribe to our weekly newsletter and join our Slack.
We'll keep you informed about our events, articles, courses, and everything else happening in the Club.

DataTalks.Club. Hosted on GitHub Pages. We use cookies.