Read the full episode transcript
Generated from the exported YouTube subtitle track. Timestamps appear roughly once per minute and link back to that point on YouTube.
Today we're joined by Gabriela Costa, an analytics engineer, team lead at Indicium AI Gabriela works at the intersection of engineering and the business, helping make sure data is reliable, documented, and actually ready to support decisions. What makes her perspective especially interesting is that she does not treat analytics as just technical craft, she talks about the communication layer behind it all. Good data work starts with asking better questions, understanding what the stakeholder really needs and not jumping straight into SQL, dashboards, tools and solutions. In writing she has shared practical ideas around discovery, dashprovalidation, data modeling and all kinds of analytics engineering goodies.
So Gabriela, thank you for joining us today. For the audience listening in, can you tell us about yourself, your background and how you got here?
Great, thank you so much for having me. It's such a pleasure to be here with you guys. My background is actually international relations, so it is not computer science, statistics or what usually people come from. My first contact with data happened while I was working at internationalization project for a startup here in Brazil. And there I had to do a lot of data analysis and something just clicked, I fell in love with the field and never liked it. And even before I graduated, I made the move to data and I started as a data analyst for people analytics and then I moved on to consultancy. And right now I'm a data analytics engineer to lead in this consultancy and I'm leading a team that I'm really proud of.
Nice. Good. I think let's just start off with first things first. When data people communicate to stakeholders? What do you see them doing wrong and what would you suggest they change?
That's a great question. What usually I see people doing is that when we receive a request like I need a dashboard, for example, I need a sales dashboard, they start right away asking things related to the dashboard. So, oh, what is the future you need? Which futures you need? Which charts do you prefer? Things like that. And the problem with this approach is that they are assuming that the stakeholder knows what they want and that they actually need the dashboard. That is the best solution to their problem. And I think this way, the problem is that you can get a lot of false positives in this way because you assume that they were requiring actually what they need.
So they need a dashboard. That's the problem. They don't have this data. But actually, there is a lot of things behind that that can happen. And a lot of things that if you do good questions, you can get there. And at the end, I think the problem is that if you don't get a lot of in this discovery, if you do the interview and but your approach is more related to the solution, you are focused on this. The problem is that probably you will start developing a solution that you think it is exactly what they need and it is not. And at the end, the solution falls out of use. So this can happen. So yeah, I think the biggest mistake is to assume that it's exactly what they need and just asking things related to the solution.
Yeah, so I guess when they come to you, they tell you they need a dashboard before you start finding out what types of charts you need to build. You need to understand the problem. And a step that a lot of people miss, and I believe we spoke about this, Carillo, last time is also what are the constraints or what are they looking for in a solution? Is it cost? Is it budget? Does it need to be done by Friday? Generally, knowing these little constraints can also guide you a bit. I'm kind of curious, how does that conversation go with you? So let's pretend somebody comes to you and says, I need a dashboard. Do you immediately ask them, no, tell me the problem first, or do you have a more subtle approach to it?
Oh, great. What I like to do is to, first of all, understand better the problem. So I like a lot of the, I like to divide this phase into one I call business discovery, but could be business interview, and then another one data discover. So in the business cover, what I want to do there is understand their problem. So the idea here is to see, okay, you need a dashboard. So why do you need that? Oh, I need because right now I don't have one. Okay. Okay. And why you don't have one? Oh, because right now what I'm doing is that I extract some Excel files from a system and I create something in Excel, for example. Okay. And how long you take to do it.
And then I get more in detail to understand how the process is being done right now. So for me, this is like one of the key questions. Why do you need this? How do you do it today? And then I move on to the solution because this way I can understand actually if dashboard is the answer to their problem. If so, okay, then we move on to understand the questions that the dashboard needs to answer and what kind of decision they make through with the dashboard, with the information that we have there. But yeah, I believe that the most important thing for me in this business cover is to understand very deep what they need, what they actually need. And I think making good questions here is the key.
Of course, I have even like an example that happened to me like recently. I had a client that shared with me and that he already did that covered. Like, oh, I did it covered with the client and with the employees. And I already have everything that we need to do. And he even did like a wordframe like, oh, there's the boxes here. I need just this filters, this chart, and we are good. And okay, I was like, oh, awesome. So let's see. And I realized that in this dashboard, we had four plates with a lot of like with tables, big tables. And I asked them why you need that. And he said, oh, people like to extract and analyze in Excel. And I asked them like, okay, and what they analyze in the Excel, what they build in Excel, like what they are being able to answer in the Excel that the dashboard is not answering to them.
And he was not able to answer me this. So this is the thing he was talking to the users only, oh, what you don't like in this dashboard? Why do you want to change? What do you want here? Oh, I want the table. I want this. And he basically did the another approach that I was saying. So he was basically gathering a lot of requirements from them. And he was not actually understanding the decisions that they do with this information. So I think this approach of understand, okay, what you need, what decisions you do from this, what is the impact of this? How much time it costs for you? Things like that. I think it is a better approach to make better decisions.
Yeah, I've always thought back when I was a dashboard consultant, every time that somebody wanted to export something to Excel, I come to learn that it's for a lot of reasons. Sometimes there is the just in case, I don't know if there are going to be other requirements that I'm going to have in a few months. And I don't know if I'm going to have your time type of thing. There is the somebody in our team does a lot of complicated stuff that I don't understand. And it's like, oh, then we should have include that person instead of like allowing that person to export and do the things because maybe we can automate some of that work already in the dashboard.
There is sometimes I can feel for a controller autonomy, like to still feel in control of the solution. I think even if they don't export it, how did that possibility there help? So understanding the why and it's always like very different from situation to situation can also give you more clarity to a problem. In a way, it's it's the famous saying, if you ask people before cars if what they want, it's faster horses. I guess one of the things that I'm thinking of when I'm listening to you guys converse about this, obviously, one part of it is asking the right questions and understanding the business context. But what you're both kind of alluding to here is that sometimes there is a few more subtle and hidden signals when it comes to what somebody actually wants and why.
So let's take it a step further. So let's say we did the business requirements. We actually delivered a solution. Now, how do you actually make sure that they are happy with it and the business is happy with it? Right. Because I've seen this a lot in my experience as well. You deliver something that was agreed on. It was exactly in the requirements. And then you still get a bit of a lukewarm response. So what do you suggest people do there?
Okay. Yeah. That's actually a really good question. I think here I like to think in the solutions that are developed as a data product. And when you say product is something that is live, so it has some cycles sometimes that you develop something that is great for the business, but answer the questions that they have today. Maybe next month they need new requirements and that's okay. So what I like to do is to make sure that I have a process to get these requirements to see how the, for example, the dashboard, what could be another data product I've been using there, been adopting and things like that. And this way I can make sure that this product will continue serving people.
We will continue bring available to them because I see a lot of like data analyst, analytics engineer develop a solution and yeah, it's done. I already, you know, I finished this and yeah. And three things like a project. What is, it is not like wrong, but it's a way to see it. But if you think more in the future and people adopting this, I think this kind of approach is something that has been working here. So usually I like to, even for example, I will say dashboard because I think it is the data product that is most famous. Sometimes in the cover, I like to put a button where people can click it and they go for a forms there. And say, Oh, I want this new feature.
I need this because of that. And then things like that, they can require new things. And it's not just like for when they have an issue with the data, but also to require new things as well. So this kind of thing, it is very important. And also get some measures as well, like how people are actually using the dashboard they are using. They are seeing the dashboard, how frequently it is. Things like that, I think could be on help us here to see, okay, they're adopting actually the product. And yeah, I think that's one of the things. And one thing that helps me a lot is make sure that the solution is actually helping them to take decisions. Because at the end, when you're saying about data field, everything is about making decisions.
They want data because they want to make better decisions. So if you are able during the discovery process to show them the valuable of the solution to make better decisions, they will adopt it because it's exactly what they need to do on a daily basis. So I think if even like before delivery, if you make sure that they are connecting, so you'll be fine and all like that. After that, of course, it is not like the work is done. You have a lot of things to do and continue improving the product.
Yeah, and sometimes learning about these important decisions that people in your organization make can actually help you being productive. Like, hey, I noticed that you have to make a decision by the end of the month. Would it help you if I provided you this information like two days before? And you can potentially also be in the spot where you build solutions that people didn't know they needed.
Yeah, exactly. I even have, you were saying, and I remember just about something that happened to me. Client request, visualization would be about like scores for customers. So how much available this client is for me, for example. And I developed exactly how he asked it for. He was saying like, oh, I want this table with those columns. I need this visual. He was very specific and I did exactly that. But when you look at that, I was like, he can't take decision from this, not just with this information. And I knew this because I was in the discovery and I got a lot of information about what decision they need to do. So when I looked at that, I was like, okay, he needs more.
He needs more metrics here to help. Because for example, if Tony knows that Huan is the top score client that is very available to him, what he does with that. So he can do something. He can contact him, send an email on WhatsApp, whatever. But if you already did this yesterday, you won't do it today again, because then the customer, Huan, will be annoying. He'll be like, oh, okay, he's sending a lot of messages. But if you already see, for example, that you have three months that you don't contact me, then you will actually do something. So I propose to him, okay, I realize that only with this information, we can take decision from this. So how about we have this and that?
And he was like, oh, my God, that's exactly what I needed. I was thinking to extract from the dashboard and from the system and do something. And then he didn't know it was possible to do it. That's why he didn't ask it for. But how I map it, what they actually need and what decision he needs to do, I was able to propose things like that. And for example, right now, these things that I propose, it becomes a track of KPI. So for the whole company. So things like that, if you do a very good score, very good questions, understand the making decisions, wow, it can be bring a much more valuable to the person.
You kind of mentioned one of the topics that I think is fascinating, which is when you don't fully agree with the vision of somebody that made a request. Now, in your case, it worked out fine because you suggested something and they were really happy. But what I've seen and maybe a lot of people that are hearing to this can relate is sometimes people come with like, oh, we really need a machine learning thing or we really need a chat board or we really need to use AI. And you kind of know, like, you just think that sounds cool, but that doesn't really bring any business value. And if you were to deliver that, they're probably going to be happy and like, oh, wow, you're amazing and everything.
So it's not per se bad for you to deliver something like that. But you kind of feel like, yeah, but this is a bit pointless. How do these conversations when you as an expert disagree in many ways with the stakeholder that requests something play out for you? Tell us more about those conversations.
Yeah, that's hard when it happens. But what I like to do is how I say in this first conversation, I understand very deeply their pains. Okay, you want machine learning. Okay. And why that? And I gather all this information and something even that I learned with HUA is that you don't go to the dispersed meeting, kind of like showing that you are ready to say no for the person. So I don't say no. We can't do it machine learning. We don't have enough history data or things like that. I don't do it. I like to, okay, let's listen. Let's understand from like where this request is coming from. Like you saw, for example, another area in the company doing this.
You want as well. What happened? Like, I need to understand better this requirement. And after understanding better the problems, everything, then I can bring to the person like okay, to develop the solution that you request. Maybe you'll take this amount of time. We'll cost this or, you know, but we have this another approach that we'll match with everything that you need, but it's not a machine learning. It's this thing. And then I show to the person the ROI that he's going to have with those, another approach that is different from the one that they want. Usually this helps me and it works. But there are some clients that they are very difficult.
They want that way. And yeah, I mean, I already did once a data product, but then I knew that it was nothing once, but at the end I need to do another one. And I get there, you know, like they start trusting me more. I think that there is this as well, that sometimes the company has so many consultancies, experience, and some of those were bad. They kind of like don't trust you that much. You need to get there, you know. So it's something as well that, for example, in the company that I work today, it's something that I have with my clients. So it's something that is much better. Right now they really like, okay, I'm ready to listen to you. Do whatever you think it is better.
But this is something that you build. It is, yeah, it's hard, but we can do it.
That's interesting. There is a music band. I might misquote this, but I think it's you two. That one time I saw an interview and they said that for every political song, that was like a protest song, they had to release so many commercial hits that everybody would like to keep like a nice balance. What you're saying here is, even if what they ask you now is like, I don't know, in the grand thing of things like not an amazing solution or something, you just have to every now and then do it because that leverage in the future will allow you to provide more value in the end. That's a cool way of looking at it that I didn't think. Yeah. Nice. You know, the other thing that I would love to ask is we have been talking a bit about like requirement meetings and scoping the problem and everything.
But I'm curious too, how does that look for you? So imagine you have, let's say, a one hour meeting with somebody you're supposed to build, I don't know, a table, a pipeline, a dashboard for them. How does that requirements meeting go in your case?
Yeah, good question. Usually I like to, first of all, I really like the one book, I don't know if you guys know it, it's called The Mom Test. I like to follow a lot of the principles that they have there. So one of them, it's more like talk about more their life, their problems than the solution. So I try to not get that much in the, for example, dashboard or machine learning, because I don't know if it's actually what they need. So my folks will be in their problem. Another principle that I remember, it's more related to asking things about the past or the current moment. So things like, how is the process today? Can you show me how we do it?
Okay, how you get this information? Because if they are asking for you and it actually matters to them, they get this information in some way. They get from system, they get, I don't know, somewhere. And so we can ask them to show us. So show me your process, show how you do it today. This is another thing that I like. And also talk less and listen more. This is something that I always say to my analysts is it seems very simple. But nowadays we have so many distractions. It's very common to, for example, we are in a meeting, but we are answering an email and a WhatsApp, another thing, doing a lot of things at the same time. And this time with the customer, you really need to be there.
Like, and something that I really like it is taking notes. It's another thing that I like it. Why are they are saying and asking them like, okay, how do I do it? Okay. And for example, another question that I like to do is the impact of that. So for example, if you don't have this data, what impacts you? And this is a good question for me because then I get if that is actually a problem, like, okay, this costs money basically. Or no, this is just a nice to have. I would like to have this because we'd be nice, you know, and this way we can understand better their problem. So, my questions follows this way. I really like to understand like, okay, how is right now?
What decision you need to take? And much less about the solution itself. More at the end, I can ask more about like, if I understand they need actually is a machine learning, okay. I can make more specific questions related to this, but not in the beginning. And it's not like in the most of the conversation is not about the solution. It's more about these requirements. Those are the questions. Usually if it is inside those three principles of the mom task, we will work fine. I will, I will do it. And basically that's it. And then after that, after this business covering this, all this gathering, all this information, I like to make sure if we are aligned, so I at the end of the conversation, I kind of like summary everything and I send an email to them.
Like showing everything that we are talking, kind of like a follow-up. And then I like to recap everything and then the decisions that were made and to also, uh, reinforce the stakeholders. So who is being responsible to approve, for example, the data product. Um, even if there's a table that's being modeling, if it is a dashboard, if it is, um, a machine learning who is being responsible to approve and say that's okay, it is done, I like to reinforce since the beginning. And I also do like, uh, to sound kind of like an image. It is simple, but they actually like it. If it is, uh, uh, with a progress bar so I can show that, okay, this is all the process that we are going through.
We are here. The next one is this one. And then after your advancing, um, I also like to reply the mail and say, okay, we are here right now. And this works fine for me because they like to see, okay, we are having progress. Uh, we are okay. We are here right now. And they can see all the process as well. And it's something that works very well, um, over here. So it's how I like to do it. Um, I, I, I think there is no, like a set of questions that I always do. It depends a lot of the conversation, how it goes. But as I say, if it is in the mountains, probably principles there, uh, is the question that I will do.
Interesting. Because I've seen it played out in two different ways. Some people do it always with the flow, like be present, always follow up questions. And so it feels more like a therapy session. And then some people come with a list of very structured questions and it feels more like a job interview. So I guess from that balance, uh, I don't know. If you can see my hands from here, but you're a lot closer to going with the moment of having a list of structured questions, right? What I'm hearing a lot here is this really, first of all, we need to focus when we're talking to people. Uh, as you mentioned, it's too easy to have 10 different select threats open, 20 different clock code session, answer an email in the back while they're, we all know these people in the meetings.
You just see their eyes glaze off and you're like, you're not listening. I don't even want to talk to you anymore. You lost them at that point. Right. Um, having empathy, right? Which I think you're really highlighting here. You're spending like 90% listening to them and sort of understanding. Okay. How did they even respond to this? Oh, they're not really responding to that, but they have a little bit of, uh, an emotional response to that part. Maybe you should kind of go into that a little bit deeper. Um, I guess what is interesting there is though, like how do you, how do you teach others to do that in your team? Right? Like it's one thing to do this yourself and, and especially when you're dealing more juniors, right?
Like when they start off in their career, it's all focused on here and the requirements you build something and then you impress me, that's kind of really how most junior people start getting, you know, uh, foothold in the industry. But then you, you shift to these conversations and they have no idea how to do this. So what would you tell them? Like, well, how do you try to like teach people or coach them into like having that mindset shift and sort of be more comfortable doing that? Because as she indicated, right? Like a lot of people are very uncomfortable, not like filling up all the voids, all the gaps, having silences and letting somebody else take more of the lead in the conversation.
Yeah. Uh, so I try some things and I would say what is working for me right now. Uh, the first thing that I try was kind of like write down all the questions that I like to do, but then I realized that there is no, like, Oh, it's always this way it depends off the mating depends off a lot of things are a lot of variables. But I tried to do it and I remember that was a request of one of my analysts. And I went to a discover section, um, that she was doing. And I remember that was very, uh, she was like reading the questions and it was like, okay, done next one. And I was like, Oh no, it's not like this. Uh, it's good to have, um, you know, like, um, somehow I structured, I would say, but maybe not that way.
Like that, uh, that you were reading the questions and make sure you do every, you know, uh, because I think you lose a lot of, um, things that are being, um, saying right now because we're a very, you know, like, um, um, pantation of not losing the, that question. And so what that I, uh, I do right now, it's more, uh, first of all, I like to, uh, as then to participate of a data discover section with me. So they see how I do it is they think that it's being more like valuable to them because this way they actually can see an example and they were like, Oh, okay. You do this way. Oh, I do that way. And, and then they get more about it and I have kind of like, like a structure.
Like, um, the first fall, uh, I like to ask how I say more about the past and the current process, then I like to ask more about the decision they're making from there and just more at the end, I like to do more about the solution itself. Um, so I think it is more this way. It's more like, okay, what I like to do and how I, I'd like to ask first, but, uh, something that is working very well is, uh, actually bring them to the conversation so they can see how it is. And I also like to show how I prepare myself, um, before, um, the, the meeting. I actually like to study the stakeholder. So to see, um, it is like, uh, the person is a director, is an analyst, who is the person who is requesting.
Uh, I like to see, for example, if they're, they have, um, a degree in data, it happens sometimes, and I know that they will like, I talk about data and things more, no, in a way and using words here and there that they will like it. So I like to study a little bit more about the person, the business they are. So it's about marketing is about sales about this or that. And I like to make sure that I know the, the men words that they can use it, the concepts they usually re-will. And so those are some of, uh, the technicals, I would say that I try to do and teach my analysts as well, like being prepared this. And, um, yeah, I think it's it.
You know what, you just remind me on my first day ever as a consultant, my boss back at the time, uh, Matthew, he took me to a pre-sales call. He didn't show me any of the preparation or anything. He took me there. And then at the end, he spent like maybe 15 minutes telling me a little bit of what was in his mind. So it was like, and when this person mentioned something, I got the impression that they were actually worried about the budget. So that's why he steered the conversation in this way. And then this person was saying things like this, but I believe it's because of, uh, and that to me was like super helpful. So what I would compliment to you is like, yes, uh, take whatever you want to teach through a meeting through the preparation.
But to me, the thing that was like a life changer back then was to take 10 more minutes to talk a little bit about the debrief of like this crossed my mind, or generally when clients mentioned things like this, they actually need this. One thing I find peculiar in your example is, uh, you, you, you mentioned giving, uh, the people some questions and they start reading them one by one in a call. I guess there's obviously the regard there of, is there such a thing as over-preparing, right? I mean, on the one hand, of course you do need to know the language, but of course you do need to know the language and domain as, as you're describing, you know, what, what sales doing, what's marketing doing, et cetera, et cetera.
But on the other hand, and I see this a lot in, especially data professionals, because so much of your work is really focused on delivering a answer that's as correct as possible and very pristine. That takes a lot of effort and thoughtfulness and preparation. And there's a lot of this focus on preventing to make a mistake and looking bad, but then if you sort of extend that into a sales call or like a discovery call, it works against them because they're too focused on, on getting a certain thing done and they're completely missing all the signals and all these nuances that the client is basically showing them. Um, I think it's really interesting that you, uh, have them go on the call and what you described Juan as well.
Like that is, I think such an important exercise to like really shift from just the technical to being more of a consultant. And we've had a couple of episodes also, we discussed like what is really good consultant that's on, that's more well-rounded on the communication side. So on the technical side, maybe even have a little bit of, um, business savvy. So maybe they have some of their own ideas of how the business could run better. Um, I guess one of the things that I find when keeping paper trails though, which is what you mentioned, you give them like updates in the progress bar and you send the emails and you summarize everything. Now, of course you're, you're, you're going to talk to tens, hundreds, maybe thousands of people at some point.
And it just becomes this giant paper thrill, messy monster. So how do you, how do you deal with that from a day to day? Right? Cause I see this going wrong all the time. It's a decision goes to like four different teams, five different initiatives, some in emails, someone slack, some in some other place. And people just lose track of what they're even trying to achieve in the first place. Yeah.
That's a, uh, a great question. Um, usually what I've been working on a lot, um, here, uh, when we're saying about like, um, data products is make sure that we have a data, um, owner, I'd say, or data steward, and this person will be responsible to, um, and kind of like filtering all the requests that are being, um, um, done. So I think having, it depends on the structure of the companies, of course, but it's something that helps a lot if you have this person, because sometimes I have this that for example, I start developing a data product and. Okay. I have this person that is my stakeholder and suddenly most after that the product was being developing, then, uh, we discovered that we have a new stakeholder and this new stakeholder didn't like that much of the product because they are discussing off point of view of the product.
Oh, I want to see in that way. And then another one in another way. Uh, what I really like to do, uh, at the beginning is to make sure that I actually, uh, know who is making the decision. Who is, okay, I have four or five stakeholders and then, okay. So I then, um, um, uh, confirm and you know, I've proven, but, um, I think that they have this paper of the, like the data owner of something of the data. It's actually very helpful if it is possible. It's not always possible, but I think it is very helpful because this person will be responsible to, um, you know, like sometimes we will have a lot of requests, requirements, and some of them, uh, actually will be better if it is another product, you know, like, because, um, sometimes the person will start requesting so many things, people.
And you know, uh, it could be different views of the same product and maybe we can, uh, you know, like developing different things. Um, and I know it is very common to, um, at least for me, they request things like that all fits in one they are trying to. So, uh, sometimes it's in this discovery part as where, uh, I try to map as much as possible, the stakeholders and kind of like, um, no, like, and have a kind of confirmation from them, like, like, okay, it's me that you will make this decision and I will be responsible for that. I will be responsible to chat with my, my, um, team, for example, and things like that. So, um, at least it's what it's been working from here.
And you also mentioned that you currently run a team, right?
Yeah.
Just out of curiosity, aren't they more on the junior side or all over the place?
Uh, most of them are juniors, but I have some that are medium as well. Maybe.
I want one thing that I've been wondering a lot is, do you notice any generational differences between like the more young people that enter the field data versus people that have been, the way that I notice it is I actually was teaching a group of more junior people last year. And what I notice is I'm not talking about like, Oh, these generations, this, that, whatever, no, it's more like I was constantly like, wow, when I was a junior, I wouldn't have thought of that. Or when I was a junior, I didn't tackle problems like that. Do you notice some differences between generations in that way?
That's a very interesting question. Uh, what I realized, uh, from like more juniors, uh, nowadays is that they are very, how I can say that, like they depend a lot of AI. I feel like sometimes they didn't learn anything without AI, which is not a problem, we really use AI, of course. But it's kind of like, I can think without AI. I don't know, you know, like if we had some problem with cloud or chat DPT one day, I don't know if they can do the job sometimes, you know? Uh, so I think that, uh, one thing, like it depends a lot of AI. It's one thing. Um, and another thing, um, that I would say, um, it is, but I don't know if it is more the personality of juniors, you know, like, but, uh, some of them has a lot of difficult, I think it is something that we have in data, uh, to actually, um, communicate with people, I don't know, like con, connect with people.
Uh, something that I always say to them is like, don't be distracted because sometimes, um, they really get distracted even in a, in a meeting, they are here and they are there is something that I already mentioned about it. So I think the distraction, yeah. Um, the communication, but communication could be a problem of everyone. Even at Sanjur could have problems with communication. And I think this, uh, dependence of AI, it is something that I actually see a lot. For example, sometimes they show me a cold and I ask them, okay, but for why do I have to, why this and say, I don't know, just chat DPT told me to do this. And it was like, oh my God.
So yeah, use AI, but think as well, you know, like, uh, is something that I, um, seeing that the people that are arriving right now, um, are pretty facing.
You know, when, when you say that like people over in real life and they are, I have mixed feelings because on the one hand, like it kind of sounds logical that when people know how to do something, uh, manually, they know it better. But then I also think about it and say, for example, I, I can write Python recently well, but I've done this as early know how Python under the hood allocates memory to my computer. So to me, it's really hard to like, do people really need to know how things work as long as they're able to do them? Yes. No. How, how do you think about that?
Yeah. Uh, I think, uh, in that deep way, it depends on how much like your job requires you, for example, Python. Um, but I, I think you at least need to be able to explain what you are doing. So, you know, like, Oh, I did this because, um, you know, I need to get this result and then that's why I did it. Um, maybe not that technical way. It's more like, you know, like the logic behind, I think you need to be able to understand even to explain to AI what you want, you know, like you need to understand the logic and how you want the thing and why you want that. Uh, what is the purpose? I think this will be enough. Um, maybe it will actually right now with AI, you don't need to be the bass cold, uh, you have the bass cold, but if you, I think you still need to understand what you're doing, um, because at the end, uh, you will reveal the cold.
And if you don't understand what is being, um, like, uh, done, you can't know if it is right or not, you know? So it's something that, um, I, I had, uh, recently, uh, conversation, uh, uh, one of my analysts was showing me like, Oh, this number is not matching. I would say, okay, how you calculate that? Show me the cold. And when I say I saw the cold, it was like, Oh, is this, and why are you doing this? Oh, I don't know. AI told me to do it. Why? No, like you don't need to be that deep, but like you need to understand a little bit like, Oh, it's doing this because of that, because I passed this, it's fine, but he couldn't answer me. So I think this kind of like, uh, understanding is still very important.
We did, we did talk a lot about like, uh, advice for people that need to be always stakeholders, but I also want to hear your advice. So for anybody listening that either wants to get into the managerial side of data or just recently got promoted to manager, what are some of the tips that you would give them?
Oh, uh, I would say something that it seems very simple, but for me, it's very important is actually to care about the people, like actually listening. Um, because they're saying there, there are problems we can think about an an operative ways of how we can solve it. Um, as I say, one teach me a lot when he say about like the no, don't say no, uh, at the first time. Um, and it's something that I, um, it's been very valuable to me because, uh, at this beginning I listened then I tried to understand as much as possible. Okay. Then I see how this is actually possible to do it or not. Sometimes it's not possible to do everything they want and it's okay, but I will try as much as possible to deliver valuable to them, even though we have this, uh, limitations, for example.
So for example, sometimes they will request this solution. I would say dashboard again. And okay. I can bring, uh, I can deliver all the five page, for example, you require, uh, request, but maybe I can divide in two phases. Um, and with the data we have right now, I can give you, um, the stupid and the other three, I would need to ingest data. I would need to modeling data and I will give you in the second phase, but I already can bring value for you. It's a solution, you know, like maybe I can give you everything right now, but I can try on different approach. And I think that if you listen to people very carefully, if you care about that and you get their requirements, what they need, maybe we can think of in different approach, it doesn't need to be like, Oh, we don't have all the data available in the dairy house.
It is not possible, but they need, uh, if you actually did this discover, if they have a decision and you can make their life easier, why not? Like let's try something else because limitations, we will, um, always face some limitations in the companies. Um, the data will not be beautifully as we have, uh, in Kaggle, for example, we will have a lot of, uh, troubles and if you put my baby, we can, you know, navigate this, uh, in a better way. Thinking a different way, uh, is something that I, I actually like this kind of like challenging of not every, everything it is like, you know, in their place, it's every thing perfect. I like to see, um, how I can think different and enough way more creative, uh, to solve their problem, you know, like, so yeah, it's something that I would say, like actually listen then.
And after we can think about the, the solutions, the solutions could be a lot of, um, ways. So yeah, I would say that.
Just add some personal flavor here. Um, we all obviously always transitioned from another field into data. I feel like that's like 90% of the people working on data. Now your background was an international relations. So what are some of the things that you fought, you keep very from that field that you feel are very useful in your job still to this day?
Hmm. That's a very good question. Um, I'm thinking here actually international, uh, relations is something that I think, uh, for example, nowadays I work with, um, people from different cultures, um, even though like, even from India, from Columbia, from Chile, from a country of countries, and I think that understanding, um, international relations, we study a lot about like, um, uh, something that is like, uh, understanding different points of view and try to think in solutions. Um, I think it is something that we have a lot. I remember that I have a class that we are supposed to be like, uh, in the government department and we had to solve, uh, a problem.
And we were like, you were a country and I'm another. And something that I was like, uh, very, uh, was very curious is that we realized that there is no solution that everybody would be, um, like happy a hundred percent, sometimes it's not possible. And to deal with, um, things that are like limitations, you know, like, and you have to do the best is possible with what you have. This is something that I learned a lot, like, and, and think about the impact. Uh, so it's something that I, I bring a lot from there. And also I think this, um, understand of different cultures. Um, I, we had a lot of like, um, our marketing, international marketing, and we need to, um, um, adapt our language, our, even like our, um, body language, everything when you are talking to different, um, cultures and be very respectful to them.
Um, yeah, it's something that I really, I really like it. And I remember right now that I had a customer that is from India and he's, uh, speaks, um, Telugu. And, um, I was one day, I was like, okay, I will learn some phrases. And I went to the meeting and I say some phrase to him and he was like, oh my God. And he was so happy and, you know, and he was super serious. He was like, he didn't like to, you know, like to talk that much. He was like very hard. And nowadays everybody says to me like, Oh, you transform him. And it's just because I care, you know, like, uh, when you, you will learn and language, uh, their culture, they're like, Oh, you actually, you know, care about it.
And the same happens to Spanish, for example. Uh, I started to learn Spanish. I can say something here and there. Um, and people are actually very happy about it. Um, so I think this, um, uh, international line actually, like, and, and also think about every, uh, how everything can impact each other. I think, uh, right now that we have the globalization, something that, um, you know, something that happens in United States impact in Brazil and so on. So, uh, it's something that we, we study a lot and I kind of like try to bring this to here.
It's funny because that that's also even that like the impressed people by learning a bit of the language. That's also cultural. I think, well, Tony, you might know a lot of Northern Europeans when you just say a phrase in their language, they're like, Oh, please don't try. But a little concussive, like, Oh, wow. So even those little things, it's so culture, depending that it's so true. Yeah. I, yeah. What is also very interesting on the cultural side. I mean, all of us here have experienced a lot of multi multiculturalism through our work and through our lives. Um, one of the things that I always vividly remember, um, when, you know, we're back in the day, uh, as a student in Amsterdam, we had all these international students coming in, we'd show them around town or give us a little like cultural briefer before we'd have him over.
And that would explain us certain things. Like if you interact with a lot of Asian cultures, they take a lot more time. They sometimes might pause like one or two minutes after you ask a question. Cause they're really trying to think through and be considerate of the answer they're giving you. Whereas, you know, someone in the United States might give you an answer in, in, in minus one second. Like they're talking over each other. Right. And then sometimes even understanding like some of those smaller nuances and differences in communication, even if someone is trained in a different market and different country, they'll still have that in them.
Uh, and sort of playing, playing into that a little bit also has helped me personally a ton in consulting as well. Uh, other than of course, impressing them with beautiful sentences in their own language. So for those people that want to learn more about you, Gabriela, um, where can they find you, what's next for you? Uh, what should people be paying attention to?
Oh, great. Um, you can find me on LinkedIn, just search for Gabriela Costa and analytics engineering, and you can find me. I create content every week about analytics engineering and a little bit of what we share here today as well. Uh, most of my content, uh, is in Portuguese, my native language, but you can also see some videos in English as well. So feel free to check those out too.