Latest / The Unfiltered Engineer / Ep 3: Measure What Matters feat. Nobel Xavier
Transcript
- Vishakha Motwani: Hello and welcome to the Unfiltered Engineer. My guest today is Noble Xavier. Noble is a director of engineering at Indeed, where he leads Auth, Identity, and Profiles Experience for Glassdoor and Indeed Company. He spent nine years in the Indeed and Glassdoor family, climbing from senior software engineer to senior engineering manager and now director with earlier roles at Dassault Systems and Intuit. Today we are talking about what impact actually looks like from a director's seat and how engineers can measure and talk about their impact and their own value without it sounding like bragging. Hey Noble, welcome to the show. I'm so excited for this episode. Nobel Xavier: Hi Vishaka, glad to be here. Vishakha Motwani: awesome. tell us where you're tuning in from. Nobel Xavier: so I'm currently based in Bay Area. I work remotely. Glassdoor and indeed have a remote work policy. We have an option to use the office. We have an office office Vishakha Motwani: Yeah. Yeah. Nobel Xavier: in Foster City. So occasionally I hop in if there are meetings or something like that, but mostly working from home in Bay Area. Yeah. Vishakha Motwani: You're busy day. Awesome. Awesome. It's so good to have you here. So before we dive into the actual topic, I want to understand from you what does impact mean to you? Nobel Xavier: So I think depending on who your audience is, the definition changes. But like in my day to day, in my seat, I think when I look at impact, I think it comes with a dual mandate in the sense that at the end of the day we are all in service of business. So That is first and foremost that hey, what is the impact to product? What is the impact to the users, consumers, customers? That comes the foremost. But the engineering leader ecosystem comes with an extra set of mandate as well, which is long-term engineering health, like long-term architecture health. So when I look at impact, I think those are the two areas where I'm primarily focused on. when it comes to measuring impact or for that matter evaluating impact. Vishakha Motwani: Thank you so much for like mentioning it from the business piece and the engineering piece because it while it interweaves together, but I also understand that the way you put out your impact or the way you show it to other people has to be sometimes different in the way that who you're presenting it to. So if we were to speak about like from your perspective that as a director, Why does this hold so much importance? Like we all know in job interviews, you kind of prepare with respect to your showing your impact because that's kind of the only way that you can help evaluate the candidates. But in your day-to-day, how does that show up from your from your side? Nobel Xavier: So I would start by saying that I think measuring impact and exp like building the muscle to express or translate the impact for your work is not something that we should just reserve for interviews. But I think that is a forcing function we should all of us, like I think at every level, right? From a junior engineer or an intern all the way into the senior leadership, I think that is something that's a forcing function that we all should or that's the the framework of thinking we should all get into. Now in my day-to-day or from my vantage point, as I said, like I think impact can look either on the business side or on the engineering side. But it all ties down to what is the organization's priorities? What like I think every every organization, whether it's a small startup to a multi billion dollar corporations with thousands of employees, they do some level of planning. I think it can be right from a quarterly planning to depending on how big the organization is going into yearly planning and multi-yearly planning. So if I think first and foremost, I think understanding what are the priorities in your e in your organization, I think is table stakes. I think that that can like how nuanced or how detailed your understanding is changes from level to level. Like if you're junior, it might be more narrow in the scope of hey, we have the organization priorities are XYZ, but my team's priorities are ABC that ties into XYZ. So I will just focus on A B C and then the higher you go, the the broader business you start to understand, the more expanded those priorities look like and At the end of the day, I think no matter I think expressing the impact should all that is the denomination that you should come back to that hey, this is this is how the work that I did or the effort that I put added value to the organizational priorities. Vishakha Motwani: That's I like that you separated them out that w a piece is measuring and another piece is expering. And I want to get into that. But before we get into even measuring or expressing, with whatever changes that our industry has experienced in the past two, three years, needless to say that how do we measure the outcomes with AI being involved and so many changes AI being being done by AI. Nobel Xavier: Mm-hmm. Mm-hmm. Mm-hmm. Vishakha Motwani: What does like impact versus looking busy mean Nobel Xavier: Mm-hmm. Vishakha Motwani: to you? Like what's the difference? Nobel Xavier: So I would say that I think and this is I've seen this more often than not, and I have been guilty of doing this as well in my early in my career, which is evaluating impact through complexity. Just because something is not is complex or takes a takes a while to do or is hard to do does not mean or does not translate proportionally to the business impact. Or the engineering organizational impact. So I think first of all, I think we should remove ourselves, our effort from the equation and objectively evaluate like hey, what's what's I can do this, this is let's say thousand hours worth of work, I can definitely do this, but that should not dictate what the how impactful this work is. when once you do that, I think the latest industry trends or like again like I think the whole point whether he AI has made in this AI era, like coding is losing its what do you say, this niche skill or like a very hard skill to master. as it's losing that sheen. Again, like I think I don't I'm not completely on board with that. But yes again like I think in that sense you will start seeing more observing more and more when you start disassociating the effort involved with the impact, you'll start seeing that answering that question becomes more and more simple. And sorry, I think there was a last like I think there was an ending part of your question that I I want to Vishakha Motwani: it was more so like what does looking busy so if there is a different meaning other than complexity for you? Nobel Xavier: Yeah. So I think at my level I would say I'll start from like I think my level and then we can go into other areas. In my day-to-day, I would say that looking busy more often than not will translate into less impact. What I'm what I'm what I mean by that is like I can have my calendar packed with meetings where even if that is not the case, I think I can be getting into tactical solutioning and whatnot and yes I think I might feel that hey I I'm adding value to the organization but it more often than not may not mean that I'm doing my job right. one example of that that I can think of is let's say if my one of my teams hypothetically speaking let's say has continuous production issues and I jump into those production issues. My team also jumps in and I'm leading the charge from the front, delegating work, handling comms and whatnot, and in informing all stakeholders, creating a plan, investigating the logs and whatnot. And I can do this very well. And I can have that false sense of satisfaction that I am contributing, but If you ask me, I think if I am not thinking through, hey, why is this happening again and again? What's the recurring pattern here and what are the defensive measures we should take? that could be coaching my managers that report into me or team leads that report into me on how we can mitigate this. Or it could be reviewing the architecture with my team leads and principal architects and saying, Hey, is there something that we can do where we can scale this? So if I'm not doing that part, I don't think I'm being impactful in my role in this particular equation. So I think busy work, more often than not at my level, can Vishakha Motwani: Yeah. Nobel Xavier: create dependence. And dependence does not translate into impact. If I'm not freeing Vishakha Motwani: my god. Nobel Xavier: of myself more and more, I'm not making myself more and more obsolete, then I'm more and more getting sunk into like quicksand sunk into tactical and day to day stuff and then I'm not adding value to what the organization expects from me. Vishakha Motwani: Yeah. That I bet you that there are so many people who can relate to this at some level or another because I feel called out at that point where you said that complexity is not equivalent to impact. And the part about like I yeah, we are busy. We are busy resolving a production bug. We are busy resolving organizing these other things around the thing that will make a difference. So Having said that, I think we get the idea of looking busy, and that will look different for different people. At your level, like where did you come to this realization that this is busy work or this is something that's not adding value to the thing that I'm trying to accomplish? And after that, we'll go into some of your ways to measure impact. Nobel Xavier: Mm-hmm. Vishakha Motwani: But if you were to take one step back and see that. In this point, at this point right now, how can I understand in my current situation whether I'm doing busy work or whether I'm actually moving the needle for the organisation? Nobel Xavier: That's a good question. So I think let me say this at like maybe different level. Like I think let's say you're a junior engineer. for a junior engineer, it would look very different from what it'll look to a team lead to a senior engineer. So I would say at a junior engineer level, I would say if you're doing repetitive work, I think you should ask yourself that question. Hey, Is this work that can be automated? Is this work that can that can be simplified? it could be like for example, it could be deployment config. As a junior engineer you're getting into on call deployments. Again, like I think this is not true for most of the companies, but there are a lot of teams and companies that still manage legacy systems and then there are manual deployment processes. and it has just been like given that it's a legacy system, more often than not, modernizing it requires a lot of uphill battle, so people are just like, Hey, if ain't broke, don't fix it and they more often than not, I think it's the resident junior engineer or the experienced engineer in the team who gets handed that responsibility. So I think one question you can ask yourself is like, hey, is the friction here there is something really systemic that we cannot automate this? Or is it just that, hey, we are not finding the time. So maybe I can work with my team lead and figure out, hey, maybe not immediately, but like within the quarter or in the next quarter as we get into quarterly planning, can we carve out like some time to automate this? So that's what at the smallest level smallest impact radius that you can think of. And then there are various flavors of it that can be extrapolated at every level. Vishakha Motwani: Yeah, absolutely. I think you dropped something golden here in saying that can I automate this or can I make my work less, right? Like if you were s being selfish and lazy, like that's your next question. How can I make it more easier on myself? which also brings you to a flavor of like not bragging, but supporting yourself and saying that you took the initiative to see that there is a pattern. Nobel Xavier: Mm-hmm. Mm-hmm. Vishakha Motwani: And you brought it up with the team to really make sure that your team is doing the work that's needed versus kind of wasting time on something that's legacy. So Nobel Xavier: Mm-hmm. Vishakha Motwani: either you migrate or you you just make improvements in the maintenance system, right? Nobel Xavier: Yep. yeah. Vishakha Motwani: Okay, so moving back to impact. So how do you measure and talk about your own impact without sounding like you're bragging? Nobel Xavier: So I think again time and place matters. So depends what is the context here. Like, is it I'm writing my performance review or talking to my manager, or I'm like in a staff meeting and just having Vishakha Motwani: Ha ha ha. Nobel Xavier: office that hey, see how cool I am. Like that matters, but again, like I think jokes apart, I would say that. Once you're leading a team, like I think right from a T L level, team lead level, I think what I have observed is With the fear of because people are very hesitant about no sounding braggy, they over-index on the other side side and like sound over humble. because like it is at that time when like let's say the senior leadership in product or engineering is asking you about your impact or like for example, let's say as a team leader you're writing your performance review, and if I'm on the reviewing side of it, and if I start seeing sentences like, we delivered this, we did that. Yeah, I understand, like I think you don't want to sound pompous, but this is not the time and place for that. I think depending on what's your seniority level, I think you there is no harm in expressing objectively what is your contribution to the initiative. So like if I'm writing like let's say if I am expressing my contribution, yes, I think more more often than not, I think leaders grapple with that that hey, I need to ex I In the interest of me saying that hey, I did something, I also want to make sure my team's getting recognized because I need to get recognized, but my team I shouldn't be leaving my team behind as well. So I think discerning your contribution versus team's contribution there, I think is I would say doing justice to the question there and you don't need to hesitate there. So as as a leader, w what you sh what I would do in that situation is again, like I think you know. what your contribution or like what your ex expectations from you were in a complex project. So at my level I would say that, hey, the decision making, the architectural accountability, I think, yeah, those are my contributions. I reviewed the architecture. Again, the architecture might be made by some, but my team delivered it. And that's totally fine. Vishakha Motwani: Absolutely. there is something that you pointed out about like leaders and using the V statement, which is so so common, I guess. Like people have to get into the habit of saying that. And I can tell you my instance, I had an intern working with me, and I did not want to put their achievements in my performance review, even though I was the one who's completely helped and mentored that intern. And at that point, I think I learned a little bit about like, you know, their achievements also come under your because you helped them get there. Like they came with zero knowledge. So Nobel Xavier: Yeah, yeah. Yeah. Vishakha Motwani: it's not so much as you're taking away credit, they will get the credit for sure, 100%. Nobel Xavier: Mm-hmm. Vishakha Motwani: But you also get to take the credit that you meant to them to come at that level. So if you were to go back, let's say there is you talked a little bit about like leaders and Team ownership. if I were to talk about as as an IC, where Nobel Xavier: Mm-hmm. Vishakha Motwani: do you collect this impact? Where can I find this measurement? I have some examples from myself, but I want to hear from you at your level. How do you suggest the ICs in your teams or outside of your team? Where do Nobel Xavier: Mm-hmm. Vishakha Motwani: where can they find these? I want to say numbers. Do you agree with me that impact is relatively like measured? You It's almost every time numbers, percentages or users or something. Nobel Xavier: Yes, yes, I would say I think the business works in the denominations of numbers. So I think if you're having a hard time finding the numbers, it's very well a case of that hey, you d either you have yourself not instrumented measurability there, or you just don't have access or you're not aware about what are the tools that I can use to measure measure the impact. I would say that it starts few steps back, which is when the project is being scoped. I think you need to be inquisitive and you need to put your product hat on and first of all start asking. Let's say the ask is there is an XYZ project, it has like it is building some features. More often than not, I think junior engineers will directly get into solutioning. I think the first and foremost thing to ask there is who is this for? What are we trying to solve? Who is the target you consumer for this? Like what is the pain point we are solving? Then you jump into who who is it for? And once you know those two answers, then as the implementation progresses, you start thinking about, hey, how are we measuring impact? Like is More is there someone who's already doing it? Like more more often than not, I think the PM in your team is incentivized to measure that. There is like I think majority of the cases. Again, there are platform teams that do not have a PM, but in general, I think PMs would be very keen in measuring if we are spending X amount of time, it needs to correspond to Y in impact. So if that is the case, I think. Reaching out to them or your team lead, I think, is the first step you should be doing. if you don't get a clear answer there, that means there is a systemic problem because I think I like to encourage a culture of measurements across the board. so if if I can't measure it, that means I can't claim that work is done. So it could be I think as an engine like I think as a engineer it could be user traffic data or data in amplitude user data or it could be telemetry data. Let's say you did a let's say you say you say that you have refactored a service. tell me, like I think if if it has refactored, just don't tell me hey, these X amount of lines have been removed. I mean like that's a that is not that does not that is I would say a false metric because What is the value to business if you have re reduced 10,000 lines of code to 5,000? Like I think, is there any benefit? Like, hey, are is there an improvement in the deployer time? Are there less test? Has this improved the test cover test coverage or automation suite? Has this improved if there's a re-architecture or rewriting of the service, can you compare latency of your APIs or page load times or lighthouse scores? Like I think those are actual impact because that'll actually drive revenue. Vishakha Motwani: I I absolutely love this that you gave like very specific examples on what you can measure because sometimes people often get confused with this idea of what are numbers? Do I and sure like PMs are a great resource to be connected with I think some of my very much like activation percentages or the projected LTV has come from PMs and I'm very grateful that they share it really openly about it. but one of the things you briefly mentioned, which I want to tap into because I come from that area of platform, which Nobel Xavier: Mm-hmm. Vishakha Motwani: you did say that it's not so easy to measure impact when it comes to platform. or it's not straightforward. I don't think it's impossible. It's just not straightforward and it requires a little bit of perspective change. you mentioned a few instrumentation tools, but do you have any examples or something that you could recommend the audience on how do you go about dealing with platform measurements? Nobel Xavier: So again, like I think I'll follow the same principle again. Like I think let's not measure for the sake of measuring. So and I think given that it is like I think platform teams are not directly involved in building the product. it's a little more like I think you have to think two or three orders further to measure impact. But nonetheless, I think without a solid platform team, no matter how great your product is, if the availability and in the infrastructure doesn't support it, it's as good as you might as well not build the app altogether. so when it comes to platform, I would say this that talk to talk to your engineering leaders. There is always some at some level There is always a discussion that talks about the cost of infrastructure. it stems from the CTO all the way down to the EMs or team leads in the platform organization. But There is always cost associated with the infrastructure. Every time we every company will try to optimize that cost. Because again, the more optimized that is, the better your revenue is. Because in tech companies, infrastructure cost is apart from payroll, infrastructure cost is the primary share of cost to the organization. So once I think more often than not, I think those leaders will be acutely aware of Where the priorities are. Now, once you know that, I think you can then translate that to whether you are on the DevOps side of it or infrastructure Vishakha Motwani: Mm-hmm. Nobel Xavier: side of it or site reliability side of it. You can always then see, hey, what are what is what are the tools we are using? is there a way to improve that? Arbitrary example. Let's say for an organization, their log ingestion bill is very high. Can I create like can I set up some time to evaluate, hey, what are these services that are generating that are like the biggest cost houses of our to overall log bill, and then checking, hey, is this just noise or is this really needed? if it is really needed, can we use sampling to still solve that? And I think that's just one example. There are others as well, like if you are once you start understanding like the cost function of it, I think you can also start looking at hey, are there any legacy services that are not on Kubernetes and they are still being deployed through past services? If that is the case, let's bring it here because then we get auto scaling, auto shutdown easily and then our Vishakha Motwani: Yeah. Nobel Xavier: cost can go down rather than having Vishakha Motwani: Yeah, yeah. Nobel Xavier: like a high number of instances always up. So again, like I think there are ways to measure that, but I think if I have to paint in broad strokes, you can think of two two dimensions. One is cost to business and the other would be dev productivity. So have can I save if can I measure some express something as because I did X on an average why devRs are save Vishakha Motwani: Yeah. Nobel Xavier: saved. Vishakha Motwani: Yes, yes. I love that. I love that framing because as much as we'll talk about like the big services or the investment that your organization has put in in say AI or wherever other places, it all boils down to we're trying to save somebody's time and money. Who's Nobel Xavier: Mm-hmm. Vishakha Motwani: that somebody and how much are we saving saving? So that's very precisely put. I like that you went into like three to five different directions for platform because that gives them the idea that, you know, it's not just a service. It's not just your cloud. You can actually do make meaningful impact. It doesn't matter wherever you are, I guess. the one thing that you mentioned initially is don't measure for the sake of measuring. Tell me a little bit more about it. What makes you say that? Nobel Xavier: So I think it's easy to oversimplify the message about measuring and then again, as you said as you are very well aware of, like I think measurement measuring success in every circumstance may not be easy. And when it gets hard, there is always something you can measure and call it a day. But that may not always align with what what the business needs are. So That is why understanding what is like what is the objective we are optimizing for. At the end of the day, like I think all roads would eventually lead to business and a dollar value. So the sooner you're able to make that connection, I think the easier your measurement journey is. Vishakha Motwani: So it's either time or money for the organization. So you've Nobel Xavier: Yeah. Exactly. Vishakha Motwani: done some, you've put in a dent towards one of these two and Nobel Xavier: Mm-hmm. Vishakha Motwani: it'll it'll show up. So would you say that doing these conversations, no matter at what level you are, about speaking about it with leaders, understanding the need, or also you've mentioned quite a few times the goals that your organization has yearly, quarterly. Would you say that doing these conversations more and more would put you a little bit further every single step into measuring your impact? Nobel Xavier: Yes, I think absolutely. Eddie I think one of the things that and again, like I think it's not completely wrong, but again, like I think in the last twenty years I think we have always been encouraged to value the craft, given that it is such a high skill craft and it is difficult to master. So that there is an overemphasis on making sure that engineering excellence or the Taking always the right architectural call, right programming practices, doing everything by the book, I think is highly valued. Don't get me wrong, that is highly valued. But I think and that everyone is going to do. that is just table stakes. But taking a step back and also seeing, hey, That is again in service of business. So I think make being able to make that trade-off when it is not in the service of business and then taking a taking a more optimal path. I think if you're ab the conversations with your leaders around impact will eventually lead you to that path where you eventually start becoming better and better in analyzing trade-offs rather than just going for the perfect solution. Vishakha Motwani: This resonates with me so much because there are times when you want to do something, but then you understand that I'm not really making a difference if I did invest my time in this. Or there are times when you know the effort is so high and the impact is so low that you kind of you need to discard a few things from your project list, and that's just a part of the business. You have To kill some babies to have to make the business flourish. And it's okay to do that. It's okay to take, do these conversations and express that, yeah, we wanted to do this, it's not happening, let's move on. one last thing that I want to touch on is we talked about measuring success, but let's say there wasn't success. We measured it, but Nobel Xavier: Mm-hmm. Vishakha Motwani: The success was either neutral or negative. I would like you to dive a little bit deeper into what if the impact was negative? How d how can you learn from this or how can you present this information and understand that mostly anything that you've measured, if it has a negative impact, it it will tell you some data, something else. So if you can shed some light on that piece of information. Nobel Xavier: Yeah, so I think right off the bat, I would say you go where the data leads you. You don't need to be worried whether it is leading you to a good place or a bad place. But it is basically a mirror to whatever project or initiative you are working on. and more often than not, I think when we build new projects in the tech business, they are bets. We have a hypothesis, we have an assumption, and we think that hey, there's a There is a consumer pain point, and then we go through the whole exercise of how might we, jobs to be done, and we build something out. but at the end of the day, that is a bet that we think this is what the user this is what can alleviate users' pain. So measuring that and if the data tells you that hey, this is not panning out as you hope to be, is still as an engineering leader, that is still valuable to me because And if a junior engineer or a senior engineer comes to me and shows me that, I think it is not, hey, why showing me this? It's like, hey, I'm very glad you brought this up because we can then start discussing, hey, does this require abandoning the idea or a pivot, or do we need to pivot? because again, the more you measure, the more you know, the more you know, the better you can make the product. So I don't think Vishakha Motwani: I don't know. Nobel Xavier: I think there is nothing bad or There's nothing to belittle there that hey the data is negative, I think. Negative data is still data that is still t telling you where costs can be improved. Vishakha Motwani: such a like I like that that at your levels like that's what matters. Like you either you abandon, you move on, and you pivot to a different Nobel Xavier: Mm-hmm. Vishakha Motwani: piece of or project and you learn from it. I think that's the biggest takeaway here is you learn from it. And sure there are times when the numbers won't be reflecting what you had hoped they would. And again, learning process, move on. Keep doing, keep going. Like you said, it's a bet. We make bits. We understand the market and we try to do things that will be in service of the business. Okay. One last question before we kind of wrap it up is what is one of the biggest mistakes you see that engineers make in showing their value? And I'm talking in terms of ICs and like presenting that information to you. As a leader, like when you look at it, is there something that comes to mind that would be like, hey, you could do this better? Nobel Xavier: I think let me think like I think what's a noteworthy mentioning advice here. and I think this is something that I have done in the past as well, so I'm guilty as charged as well, but getting too early into optimization. I understand the sentiment. I understand the eagerness to do the right thing. Us as engineers, we want to make sure the system's scalable. But again, when my product is just 1000 users at the moment in the prototype stage, I don't need to optimize for an imaginary scale. And more importantly, doing that. thinking like I think more often than not I think one thing that happens with all of us hey this looks easy I mean like I can just spend one evening or one afternoon and like optimize this and this will be awesome. And again I think all of us Vishakha Motwani: Hey! Nobel Xavier: have gone through the emotions of this it is never one afternoon. It becomes multi-days Vishakha Motwani: No. Nobel Xavier: and at the end of it you're exhausted and you come back to your team and say hey I did this and because of this there are two other tickets or f feature tickets that are getting now rolled over into the next print. Yes, I appreciate the sentiment. I appreciate the your Vishakha Motwani: Yeah. Yeah. Nobel Xavier: like I think the good person or good team member intend to do the right thing but I would say that I think at an again, like I think more at the junior levels, I would say always be in consultation with your team leads, your DMs, your leaders. Because at the end of the day, they are executing a strategy and that requires everyone to like I think it's a team sport. It's like in a how in a soccer field, like I think there is a center midfield, there's a left finger, there's a defen defensive midfield. Don't leave your position without letting the captain know. so Vishakha Motwani: What an analogy, what an analogy. I love that. Nobel Xavier: Yeah, I mean definitely do it. I mean, like I think I'm not saying don't do it. I'm just saying that propose that as an idea. I think you should always lead with, hey, here's a solution for this pain point. I think we should do this. The sooner the better. Do you think we have time now? I think every team lead. Every engineering manager, every director, every VP would want to do the right thing. It's just finding the right time slot where we can slot that work in and claim that win. Vishakha Motwani: I I absolutely like that because I wish I'd gotten this advice sooner. Because one of the things with proposing it comes back down to doing something that's not going to add value. Right. So Nobel Xavier: Mm-hmm. Vishakha Motwani: you're either you deliver the basic deliverables first Nobel Xavier: You know. Vishakha Motwani: and then you go around doing the good stuff, the s and it It adds to your initiatives. It's never Nobel Xavier: Mm-hmm. Vishakha Motwani: going to be taken away from you. The credit is never going to be taken away from you. And you never know when you've proposed something, you'll actually realize that there are two other people who would have said the same thing, but they've scrapped the idea because of some other architectural Nobel Xavier: Exactly. Vishakha Motwani: implications, blockers, and things like that. So thank you so much. This was like perfect. But we are at the part of the show where I ask every guest the same three questions. So if someone remembers one key takeaway from this conversation, what would you like that to be? Nobel Xavier: I think don't measure for the sake of measuring. I would say that is the Vishakha Motwani: yeah. Nobel Xavier: way I'd like to say always find yeah, always find Vishakha Motwani: This requires Yeah. Nobel Xavier: like what is the value to business or value to the user that I'm providing. Vishakha Motwani: Yeah, absolutely. I think this was this is something that people would have to step back and take a note of their surroundings. It won't be easy to identify, but once you have, it builds such a strong muscle going forward and that's as leaders you can impart that knowledge or guide people, mentor people through it. Yes. what is the one show, one book or something that you recommend? other engineers, other leaders in your organization recommending. Nobel Xavier: think I think the books that I read early in my career are no longer are any longer valid but I Vishakha Motwani: Yeah. Nobel Xavier: I would say I think one thing that has not changed or and I think will not change is adaptability as an engineer. again, being at the forefront of change, I think you have to always be ready to adapt to things and be a quick learner as well. I think that is just a mindset and I think there are habits around Vishakha Motwani: Mm. Nobel Xavier: that you can build it. I think atomic habits I would recommend there. I think it gives you a framework to get over your resistance and Charter into new habits, cultivating new habits, getting out of your comfort zone. So I think that's my book recommendation. Yeah, and Vishakha Motwani: I hope that people build this habit of measuring success and measuring their impact. It's like the smallest scale. You start with the smallest Nobel Xavier: Yeah. Vishakha Motwani: habit and you build up on it. So the last one, how do you disconnect from work? When your laptop closes, how do you switch off? Nobel Xavier: I think having some sort of hobbies or passions outside of work definitely is something that I would recommend. with that being said, I I I don't want to say that hey everyone should have one. I think if if just not doing anything helps you reach us, that's fine as well. But I think for me particularly, I think I enjoy a little bit of photography and lately a little bit of gardening as well that I find calm. So I think I try to maybe not after the work, but before the work, get up an hour early and like I think spend some time in my garden garden or plant like I think something that if I've got a new plant, like looking at it, taking care of it, pruning, fertilizing it, I think that's something that I find very calming these days. Vishakha Motwani: I love that. Yeah, it's I think being with nature kind of grounds a lot of people. So Nobel Xavier: Mm. Vishakha Motwani: gardening is your way of doing that. So beautiful. Thank you so much, Noble, today, for being here. I really appreciated your insights and I really wish that if had somebody told me this earlier, this would have changed my trajectory. Early on, like it still is very valuable to me. I have done measuring impact and but the sooner I would have known, the sooner I would have understood the meaning and the importance of doing that. It would have led to a lot less conflicts and a lot more achievements in my belt. But thank you so much for being here today. I appreciate your time and see you all in the next one. Nobel Xavier: Thanks