Latest / The Unfiltered Engineer / Ep 6: Influence without Authority feat. Sumit Mudliar

Transcript

Ep 6: Influence without Authority feat. Sumit Mudliar · The Unfiltered Engineer

• Vishakha Motwani: Hello and welcome to the Unfiltered Engineer. My guest today is Sumit Mudliar. Summit has spent nearly eight years at IceDQ six of them as senior software engineer before he moved into his current role as head of customer success. A job built entirely on influence rather than authority. Today we are talking about what influence without authority actually means and how to get buy-in from people who don't report to you. Hey Sumit I'm so excited to have you here. Sumit Mudliar: Hey, hi Vishaka. Happy to be Vishakha Motwani: And where are you tuning in from? Sumit Mudliar: here. I'm tuning in from Glastonbury, Connecticut. just near Hartford. I used to live in Stanford where my office was, so a recent move. Yeah. Thank you. Vishakha Motwani: congratulations on the move But I'm so excited about this topic. this is something that I feel a lot of engineers struggle with. And I've I have seen your growth from we've been together since college, and I've seen that how you understand people's perspectives, how you bring people together. and that's why I want to kick this off with the simplest question is what does influence without authority even mean in practice? Sumit Mudliar: In influence without authority in practice I would say means a lot of listening, a lot of negotiations, in a way that you meet them halfway, you try to find out what they want before you actually tell them what you want or what you think about it. Vishakha Motwani: That's interesting way of putting it because I would have walked into a meeting thinking Hey, this is what I'm proposing, this is my suggestion, but you're this is like the biggest thing that I would say for me, difference of perspective is you go in and you listen to them. That's the that's where the empathy piece comes in. what is actually influence? Sumit Mudliar: I influence, when I think Vishakha is mostly around how can I give give my my team or who am I working with a a piece of my mind. But in the same at the same time I want to look at what they are looking for. Are they really looking at looking at me for that advice or that recommendation? Or it's more like they've come to me with a problem of theirs and I have to go back and come back with something which would make more sense to them. And it which would make more sense to me as a person that hey, this is where I would want you to be, or this is what I would suggest, but still let them feel that they are owning the process, which is actually very important because I do not have any authority over them. I have to make sure that they feel that yes, this idea has has been synergized with me, but it's it's it's still there, baby. It's still their thing that they are doing. Yeah, I'm just somebody who they are talking to, maybe bouncing their ideas against a wall. Vishakha Motwani: That is so different from what I worked in in my mind because when I'm think of when I think of influence, I'm thinking the Instagram influencers or I'm thinking something that you would wanna buy. So before we dive into the perspective that I was thinking, could you talk a little bit about your role? you said when they're coming to you, they're asking you want to know first what do they want, but paint the picture for us what does this role look like for you and where does where does the influence that you speak of comes into picture. Sumit Mudliar: Sure. So I would say I I had been doing this for very long before I actually got that idealized, and I still did not know that I was doing this. when I was talking to customers, where I I so I moved to IceDQ as a software engineer where IceDQ was building their next generation platform. So 10 years of current gen, and then we wanted to revamp everything. So I started off as an architect. We built the platform out. And then once the platform was built, we were ready to give it our start migrating our customers from current gen to Nexen. That is when I switched gears and I moved into this role. So I never had the opportunity to go and sell something. Or I never thought that I could do that. I was more the background guy that, hey, you give me a problem, I'll solve it, and then I'll do my work. But the company needed me when we landed Morgan Stanley. And we did have a guy who we hired, we trained specifically for Morgan Stanley, but once he entered that atmosphere, he could not kill it over there. And Morgan Stanley was like, No, we want somebody who's technical, we do not want a project manager or we do not want a consultant. It's like somebody who knows the system in and out. So that is when they sent me still as an Engineer, but then I realized that hey, I am good at this, so I can hear, I can listen to their problems, and then I can not at the same time, but maybe the next day, maybe a few a week later, I could go back to them with my solutions. That hey, would you want to try this? Do you think this would make sense? This is what the product can do. This is what you are looking for. I think we can find something in the middle ground which would. solve your problem without me having to go back to the product team to get a to build a completely new feature and that is how I learned that hey my I am able to influence people obviously I had to build trust I had to establish myself over there that hey I am your guy I know the product in and out you throw me throw a technical problem at me you throw solutioning problem at me, I can go back, get a solution and make sure that I'm giving you what you want rather than giving you something that you don't want but I think would be a perfect fit. Vishakha Motwani: That is so well put. Like this is amazing. You already went through the journey of being an engineer to customer success. But Sumit Mudliar: Yeah, yeah. Vishakha Motwani: you said something which resonated with me big time is you you try to find the middle ground with your customers, right? And a part of it, your expertise is you know the product and you're trying to understand from your customer what they want. So Tell us what does that look like when when you say that I am trying to understand what they want, you're listening, but then also the piece of it is do you understand what you're listening? How do you clarify what you're listening something you can provide, right? Sumit Mudliar: Right, right. That's actually the learning and the research part. Sometimes I come out of a meeting clueless that hey, I didn't understand a word what this guy was saying, but I took my notes, I asked materials from them, and then I went back and I did my research. So the next time I'm meeting this person, I am a subject matter expert in that. If I'm not a subject matter expert, I will go to my boss. I'll find someone who can help me become a subject matter expert next time I'm meeting this guy. Because that is where I think people listen. You I did I did the listening part in the first meeting. I met you, I understood, I tried to understand, but then the next time when I'm going to you, I have to contribute. If I'm not contributing, then I lose relevance. And it's it's all about timing as well. Well, so I cannot stretch this long because if I want to build trust, it has to happen in the first few meetings, it has to happen essentially with them that people should be able to, I won't say rely at the very beginning, but at least they should feel that hey, he understands what I'm trying to say. Okay, he does not have a solution, okay. He's not contributing, but at least he listens and he understands. That was and this role when I stepped into customer success, I had been doing this, but I was doing this only for one customer. When I was pulled as head of customer success, I had to repeat the same process with a lot of them. with everyone actually in the organization. And then that is where I learned that prioritizing my work and making sure that the customer's priority or whoever I'm working with, their priorities are also important. It's not just about me. It's not just about what I think. It's not just about what I am providing. It's more about what they are asking for. And then there would be some place what I can offer. Vishakha Motwani: so you have just multiplied your input and listening through all the different Sumit Mudliar: Mm-hmm. Vishakha Motwani: types of customers and I bet that you're hearing different requirements from all of them. But you said something which I'm very curious to know. You said your first meeting, some there are times when you don't understand, but you did the job of listening, So my question here is, how do you listen but don't try to find a solution in the very same spot. there would be times you Sumit Mudliar: It it's I totally get that. Yeah, yeah. Yeah. I I I and you you you Vishakha Motwani: times when you would yeah go for that. I think you understand. Sumit Mudliar: have to you have to fight that instinct. Just like I was not able to do right now because I was I just like hey, I know the answer, but I I had to fight that. I even when I knew it I was like let the person finish. Let the person communicate what they want rather than e sometimes it was not even cutting them off. It was like, Hey the solution is obvious, I know it, but I still made sure that I let them speak their part. I let them add their at least clear their mind because sometimes what happens is while talking to me people actually elaborate on their problem and sometimes they come to the solution by themselves. I have to do nothing. While speaking with me, while trying to explain me what they want, they find the solution on their own. They reach the goal on their own. I am just a wall who's there to talk to. who to listen to, who might put some anecdote anecdotes here or there, or I might sh share a few personal references that hey, yeah, I understand. Yes, we had we did something similar, not exactly that, but yes. So it was more of understanding and listening and holding back your instinct of knowing everything. Vishakha Motwani: Also that involves so much of empathetic listening. It's like you're trying to give them you're trying to share your experiences, but obviously what is your what is your mantra to say that okay, not yet, not do not speak yet, let them finish speaking, but what is your main reason why you would avoid speaking other than allowing them to clear their mind or coming to a solution? Sumit Mudliar: other re reason I would avoid speaking would be I want to I want to understand the story behind the problem. So I want to get behind them to it it so it could be not just a customer I'm working with a lot of different teams in the organization at as well. So before I give a solution or before I come to a conclusion I want to get the story behind how they how did they reach over here what's causing you this it could be an issue or or discussion or why did we come to this point is more important to me rather than how to solve that problem. Vishakha Motwani: Precisely. Okay. That that makes so much sense. to you're there to understand them versus to give your side of the story. it's a very difficult perspective in my opinion to to s to stand here and to be Okay, let me see what I can do for you versus okay, tell me I'm here to I'm here for you, I'm here to help. Just help me understand your problem, right? Sumit Mudliar: Hm. Vishakha Motwani: But there is something else that you touched, which was priorities. And you said that For you're trying to find out their priority. It's not just about your priority, but you also have a goal, for example, if there are two senior engineers, or when you were an architect, You were influencing decisions about architecture. So I'm thinking in terms of me being in that space of there are there are teams that I have to convince, for example, to make some certain technical decisions. And let's say I'm the one calling the meeting to influence their decision to make a change. That Sumit Mudliar: Mm-hmm. Vishakha Motwani: works in my favor, but obviously it works in their favor. So at Sumit Mudliar: Mm-hmm. Vishakha Motwani: that time, my first instinct wouldn't be tell me your problem, because they might not even see the problem. But I'm Sumit Mudliar: Mm-hmm. Vishakha Motwani: here to ask them to look at things differently. So, how would you approach that side of influence without authority where They actually don't see any problem, it's just that I want them to take a different direction. Yeah. Sumit Mudliar: Yeah, so I I can I can and can give an example in my early days when we when I had joined Torana IceDQ So we were discussing what technol technologies to use because it it was it was going to be a complete revamp of our current architecture. So from monolithic we were going to microservices and then we were like we want to build identity access and management, we want to make sure, we wanna have a messaging queue. So we had a lot of Of these discussions around. And thankfully, my CTO is the guy who listens, but he is also like you have to prove why do you as in why are you standing behind this point? Is very important to him. Because even if I make a wrong decision, he's like, that's okay, but at least. Be assertive of why you are recommending this. He'll go back and he'll do his own research. But if I'm suggesting something, he wants to know what legwork did I put behind this, and that is what happened in those meetings. So I did not have influence over him, as I didn't have any authority over him, but I had to influence him. And we we took a lot of these discussions in stride, and my mantra, when I was talking to him about these discussions was always that I I have tried this, I have tested this, and then we used to always go back to the requirements. So it's not that we need to decide on our technology stack. It's about what functionality does this technology bring. What are we looking for? So we are looking for identity access and management. It's not more about the tool or the technology that we're using. It's more about what it should provide. What what's the functional aspect of it? And yes. Technical there's that's there are plenty of products, you can always choose the better one. You and it's not written in stone. Technologies change. Every three years you have something else. So what we chose six years back is is is on a path where we might have to change something new. But our core principles that we set behind, they do not change. And if I can convince somebody with the core principles that hey, I got your problem, I understood your core principles, here is what I have in mind. This is what I suggest. Do you agree with this? If you don't, we can go back to the drawing board. I'll come up with something different. But I do not want to force my decision on you. I do not have an authority to force my decision on you. But I did my best work behind this. So I stand tall behind what I'm recommending you. You can have it's it's more about trust, right? Unless he trusts me on solving a problem, however good a solution I give it to him, he won't be convinced. Vishakha Motwani: But that that's what makes you a better engineer or a bet better at your job, like not accepting the first thing that comes to you. And it's not out of Sumit Mudliar: Yeah, yeah. I I yeah comes to Vishakha Motwani: ego, it's more out of research. I have done my share of work. Now they will go and do their share of work to help you understand Sumit Mudliar: Set off. Vishakha Motwani: that okay, this is something you brought in, but may or may not work. there are a few things that you touched on where you said that like I have lived that life of monolith and trying to change architecture and convincing people. But there are Sumit Mudliar: Ha ha Vishakha Motwani: times when you when you're in discussions where you actually you get pushback, And the pushback Sumit Mudliar: Mm. Vishakha Motwani: is sometimes how do I put this? The pushback is sometimes not very strange. relevant to the problem you're solving. So you said a few things in terms of okay, we have to go back to the requirements, then you have to see the solution. What is the technology providing? And with the rapidly changing technology, six years down the line, it could very well go through a migration. So how do you put all this together and still package it into a solution that looks like a gift and you put a bow on it, At that point, somebody will come and say that, hey, six years down the line we'd have to go and change it, So how do you find the find that or convince somebody that for now this is the best perfect solution, but also be open to changing your solution, Sumit Mudliar: So it it it a lot of it comes under what I understood of the problem. A lot of it comes under what's our vision, where are we looking at this? So these are some questions that I might ask in the very beginning. So my first meeting will always be me listening or me asking questions. I do not want to come up with a solution at the very beginning. I want to understand where are we at? Where are we looking towards so what's what's your future state where do you want to hold on Okay. where cross the door. Where where are we at? What's our future state? And then it comes boils down to the decision that What I am coming up with, it might not be correct. It's not that what I have is the best. There are other alternatives out. So if something in in some of these discussions I've been pro and wrong. So I I I never took these things on heart. I was always that hey, that that I I can live up, I can live with this, I can understand, I can maybe find a better way to do this. Maybe yes, you are right. Let me go back. Check, do my research and come back to you. If that works, that works. Vishakha Motwani: yeah, I I love this like the the one thing there are two things that I feel it's so big that you said very casual, which probably is your everyday is one is baselining, right? Like where are you at? And the second Sumit Mudliar: Hmm. Vishakha Motwani: piece is where are you going towards, which will define your solutions because there will always be something better out in the market for you to choose, right? And the second thing you said something about like you're not tied. You're not married to that solution. And help me understand, as engineers, or maybe you've burnt your hands because of this in your early years in the career, when we proposed something, at least I had that mentality, like, but no, but like it's mine, my solution is good. Sumit Mudliar: Yeah. Vishakha Motwani: I know it. I was I now I understand that it's not about me, it's about the business, it's about the problem that I'm trying to solve. But at that time it did feel like that that I'm married to the solution. Why won't you pick mine? So how do you change that that perspective for yourself or somebody listening? What would you say to them? Sumit Mudliar: I I think for me it came with accepting a lot of changes. So my my move from India to US was very humbling. So when I I when I was in FIS, it's this was like what 2014? not 2014, 2018 when I moved. So I was already doing pretty well for myself, but I always wanted to be in the US. I I've been traveling on B1, but I was like, hey, I wanna live this life long term. And I came here. I left my job. I did not continue came with the same organization. I picked up a different organization. And initially I thought I'll do consulting. So that is where I learned this. When I I did not learn this in my full-time work at FIS. But when I was consulting, I understood that hey, there are people who are better met me at at some organizations, but they have outsourced this work to consultants. such as me to learn something and then provide and then recommend and then there were times where my three months of work or my six months was work was just a document and then it never got implemented. But s but that that was a humbling experience for me. Prior to that it was always like hey, I know this code. I work on an order management system. I've been work doing this for six years. I am The God of this system, or at least this product. If I don't come to office tomorrow, order management Vishakha Motwani: Ha ha ha. Sumit Mudliar: system will have will break. But then when I started to do consulting, it was like, I don't matter. What I do doesn't matter. Yes, they're paying me, but it's still a report which somebody will look at, will somebody will decide. If they have a budget, this would get implemented. So that is where I learned the that I cannot get tied to my work. I have to Vishakha Motwani: Yeah. Sumit Mudliar: be open, I have to make sure that whatever I'm doing at that moment, I give my best, and then I leave it out there. if it's good enough, it'll survive. If it's not, I'll do something else. Vishakha Motwani: I love that so much. There is some mindset coaching going on here. Sumit Mudliar: Yeah, yeah. Vishakha Motwani: you do the work, you give your best, but you leave the outcome Sumit Mudliar: Yeah. Vishakha Motwani: to where it's meant to be. So if you go back to tying back to this idea of like we touched a lot on understanding someone's problem, then you doing your research and you coming up with a solution, how do you convince? let me give you a imaginary scenario. How do you convince a customer or a person or a tech lead, whoever that person is, who's adamant on going towards the other way, who's not so open to the idea that you're giving, but you have to still give your best. What does that best look like for that person? Sumit Mudliar: So I I have been through such situations. sometimes it was like if if I was forward deployed or if I had somebody working in that organization, I would set up a parallel example for them. So we our product is a data quality, data reliability platform. So it's usually on-prem. So customers have it within their environment. It's not a SaaS application. So we do have forward deployed engineers who have access to the systems, so they can set up examples and then I it's always better being visual rather than being theoretical. So if I can show something, that would be my go-to approach. So even if the person does not agree s with what I am recommending or what we have for them, we'd we'd always build a proof of concept. A proof of concept goes a long way. If if I can do something, if I can show you, hey, this can be done, this can be done in your environment. it's it's it I've seen that it changes hearts, right? It it changes decisions. But if I'm not able to do that, the best that I can do is make sure that I'm doing my research, I am providing evidence, I'm try I'm repeating that in my own environment and I give give out I I have to talk in numbers. If I don't talk in numbers and if I just talk in documents and slides, I'm that what that ship has already sailed. Because if I'm working with somebody who is so adamant on his way of doing things, to prove that person that hey there might be another way is very difficult if you're not talking his language or her language. So get to the Vishakha Motwani: I like that. Sumit Mudliar: yeah, yeah. Vishakha Motwani: Would would you say that to speak that language, a part of it you have to learn in your initial meetings, when you're understanding, when you're trying to get in the requirements. Yeah. Sumit Mudliar: understanding their problem. When when w yeah, yeah, right, right. Vishakha Motwani: So th the last thing, What does that buy-in phase have in the past look like for you where you did get in get a buy-in or where you negotiated? Sumit Mudliar: The buy-in for me mostly has been that we'll we'll meet you midway because I'm I'm working with a lot of customers who I have zero influence, zero authority over them. so what happens usually is we understand, we come up with a proposal and then we pr present that proposal. But we make sure that the pro proposal resonates with what they are looking for. And it it happens with when I'm talking to in internally also, because if I need something as part of customer success, I have to make sure that the product design understands it, the product development understands it, the QA understands it. Because If if I'm if I'm representing the customer internally, I need to understand what's their problem. How are we solving them? I have to make sure that the product team who's who's actually the owner of the product who who has built this out, they r understand that hey, if I'm asking you to change something, there's a legit reason behind this, and this is why, or is it it it's making it better? Right, it's n I'm not taking you back from what you designed, and then I have to also convince the development team to squeeze this in. Because they are like, hey, we have a roadmap and we have releases for the next Vishakha Motwani: Yeah. Sumit Mudliar: three months. Where do I take this? Unless unless it's it's it's a bug, I'm not taking it because I have my roadmap fixed. I have deliverables. Vishakha Motwani: Yeah. Yes. Sumit Mudliar: I have QA team is is the same thing. So I we have to make sure that whatever is coming out or whatever we are recommending, there is something for every team over there. So the product team is happy that the product is becoming better. The development team is happy because it's it's instant monetization. Anything that you do for the customer is is monetizing, yeah, right? It's not something that you will will get fructified next year when it goes out. So and with QA team, we make sure that they understand what they are testing. I and I do this exercise within my organization a lot that hey, because I I've been a developer, so I taking off that developer hat and putting a customer hat becomes difficult for devs and QAs. So I am their mirror. I I make sure that they understand whatever you are building is great. But this is how I'm going to use them, or this is how the customer is going to use it. So you too understand that what you are building is super, right? Vishakha Motwani: Yeah. Sumit Mudliar: But there are a few nuances which you might have not seen, which which I see. And I'm here to work with you to make sure that the end goal is a better product. Vishakha Motwani: Sumit, I have to say this is an amazing skill to have to be able to represent the customer as well as convince the people within your organization. And I bet this is something that you have to do more often, with any change or any new customer. Sumit Mudliar: Yeah. Vishakha Motwani: let's say a new person coming into an organization, let's say tomorrow I show up with you, how would you explain to me To make small changes, small steps towards thinking like how you think, understand everybody and try to help everyone, but that's also a piece about you're not trying to please everyone, not you can't make everybody happy, there is always going to be that part. So h how what would you tell to somebody like me who's just starting off to understand that hey, I have these five people, departments or teams. that I'm working with and how do I keep my mind open towards a change to influence these people? Sumit Mudliar: Great question actually. And I do this a lot. So we our our team is pretty new. It's I won't say it's been there long. My team, the the one I got after I became head of customer success, we used to do a lot of different things, but we were never defined in a way that we've started to define ourselves now. And we did a lot of standard operating procedures, and that is where we laid down the guiding principles. So if you are going to join my team or if you're gonna be working with me, I will lay down the five basic principles for customer success is You have to be open, you have to be honest, at the same time, you have to make sure that you understand and you have that humility to take everybody's point in consideration. You have to talk to the customer to understand what they need. You have to talk to your product team, at least understand what they have built. Right, because they they they've built something with something in mind. You you have to understand that. You have to talk to the development team because it it it changed hands. They are giving you releases. So if you are going to send something out, you need to know what you're sending something out. You talk to QA teams to again see the process, what they did, how did they make sure that what was going out is certified and with some documentation and other things. So my experience or my exp my suggestion to my team is communicate with everyone, never assume. Make sure that you get to the bottom of the situation if if when it's a feature, when it's a bug, when even it could be a functional it could be a rollout that's gonna happen to a customer. Be prepared, be open to ask questions. No question is small or no question is big. And dig in. Vishakha Motwani: I love that. Sumit Mudliar: Don't as Vishakha Motwani: Yeah. Sumit Mudliar: in y unless you do your legwork, unless you get to the bottom of things, you cannot be successful in this role. Yeah. Vishakha Motwani: And for that matter, I guess for every engineer, be be open to listening. I think there is also this aspect of we walk into a meeting with assumptions, we walk into any of the technical discussions thinking that, okay, my way or the highway. but that's that's the idea that you have to completely crush it down. It's we the idea is we come out of this meeting with a solution, not necessarily my solution, but a solution. So I Sumit Mudliar: Mm. A solution, yeah. Vishakha Motwani: yeah, I like that. And I could ask you so many more questions, but one of the most important questions that I would love to hear from you is what's the biggest mistake people make trying to influence without power? Sumit Mudliar: My biggest mistake to influence without power. I always feel that and we've discussed it about many times in in the in this podcast itself is not taking into consideration other people's priorities. That that's the biggest mistake I think. So if if I am trying to influence something, I have to make sure that do you wanna be influenced? What is your priority? Yes, you have come to me or we are talking about it, but is it a priority for you? We we've ha and I'll give you a example with something which happened very recently that there was a feature that we were gonna build, but it never actually was a priority to the product. so it kept on moving off the plate, it moving off but there was a customer who asked for it. All of a sudden I see an email that hey, we had discussed this six months back. Where are we with that? So I could have said that let me check with the product and I'll come back to you. But what I did is I reached out to her with that, yes, what you're what you're asking is important to us. And we did have some design sessions around this, and then I showed her what we have done, but I told her honestly that this hasn't been taken into development yet. So I do not have a date for you which I can stand back to it, and then what I understood from that conversation was this is something which she is looking for, and then she would be using this in her organization pretty heavily. So we turned that discussion from a feature request to, hey, can you help me build this? So I got her ideas. She contributed in the design itself. Then I had something much better than what I had in place, and then I took that to my product team. That hey, this is now a better feature than or a better requirement that what I had brought earlier, which never got prioritized in our meeting. So her priority was important. I took her priority in consideration, and then with that, it helped me get leverage internally. So that is one of if I would have not done that, if I have not taken her priority in consideration, I would have could simply said it's not in our priority, it's a roadmap item. Maybe you will get it next year or maybe after that. Yeah. Vishakha Motwani: God, this is such a great example because I love this because it's it you came out of that conversation with the whole different solution, which you wouldn't have imagined, Sumit Mudliar: No. Vishakha Motwani: the only way that you came up with this is your openness to listening to them, to making sure that How much of this is important. And if it is really important to them, they are willing to contribute, That's the biggest Sumit Mudliar: Cool. Yeah, yeah. Vishakha Motwani: difference where you'll see people being involved in that decision that you want them to take steered towards. Yeah, Sumit Mudliar: Take yeah. Vishakha Motwani: this is so good. And Sumit, I would love to keep talking about this. This is one of my very favorite things because most of the times people say, you need to be as a senior engineer, as a staff engineer, you need to be able to influence with out authority, but nobody explains why or how or what does it mean. So thank you so much for taking the time today and explaining this. We are at the part where I ask every guest the same three questions. So what is the one thing, one takeaway that you hope people listening to this would remember? Sumit Mudliar: Mm. I I would say people listening to this should remember that be open in your conversations. never get married to a solution. Always be open to what while while entering a room enter enter with an with an open mind. Don't fixate on things, don't get too what's I I'm forgetting that word. never be possessive of your ideas. Let your ideas float. Right? Let people contribute to your ideas. that is what I would say. Yeah, yeah, yeah. Vishakha Motwani: How do you do that? How do you walk in with a blank canvas? how do you walk in with this openness? Sumit Mudliar: Yeah. So I I don't o I'm not saying walk in with a blank canvas. Be prepared to to a meeting that you're going, but be open at the same time. So I'm prepared, but I'm open to questions and open to feedback and I'm open to listening to what you have to say. Yeah. Mo more active, yeah, yeah. Vishakha Motwani: Yeah, it's more listen more active listening, listening with empathy. Awesome, awesome. And the second question that I have for you is what is a book or a show that you recommend engineers or people around you or something that you've been liking very recently? Sumit Mudliar: Very recently I've been reading a lot of book on building AI agents. and if it's not work, if it's spiritual and I have to gr credit my to my wife for this. So I've started reading Srimad Bhagavata. Yeah. yeah. Vishakha Motwani: would you recommend that to people around? I think that involves with active listening, I would say. Sumit Mudliar: Listening, yeah. If if if I were to recommend people, I would say at least start with Bhagavad Gita. So I I finished Bhagavad Gita and then I moved Vishakha Motwani: I know. Yeah. Sumit Mudliar: to Srimad Bhagavatam. But if people just give it a shot. Give g read it as a book. if you c read it as a spiritual book, that's well taken and I would be really happy if you do that. But even if you are not spiritual, read it as a book which teaches you how to live your life. Vishakha Motwani: I love that. Thank you so much. And the last question that I have for you is what do you do when your laptop switches off, what do you do to disconnect from everything? Sumit Mudliar: When my laptop switches off, my my daughter keeps me busy. She is she's my bundle of joy. we do a lot of things together. and if I'm not doing that then maybe I'm I'm playing either tennis or pickleball. Yeah. Vishakha Motwani: Love that someone. Thank you so much. Children have a way of bringing you to the present and grounding you in the current moment very instantly. And they're the best. I feel they're the best ways to disconnect. Sumit Mudliar: I I I can listen to her so much as in and she has so curious questions. Yeah. Vishakha Motwani: That probably helps you learn too, where did they come from? What are you asking? Sumit Mudliar: How did you think about this? My first question, how did you think about this? And she was like, duh. I think you are six-year-old. Vishakha Motwani: That's so so wonderful. Thank you so much, Sumit for taking the time today and leading us through this discussion. I really enjoyed it. And I hope that people understand that listening is not just your passive listening. listen to understand. Try to be in their shoes and you're trying to find a solution for them versus pushing your agenda and your goal on them. and I hope people are. are able to see the difference through your examples, through what you have been through and the role that you play in your organization. I so appreciate your time and thank you for being here. Bye. Sumit Mudliar: Goodbye. Thank you.