>> Everybody, welcome to the Spotify Teams and Tech Series. We're very excited to introduce our guests here today. First, Atsu, would you like to introduce yourself? >> Yeah. Thanks guys. My name is Euteu Kahana. I'm working with MDOCs. I've been in this telco space for almost 25 years now, has done different roles over a period of time, from a engineering background of network telco space, to a data engineering, who now more into a leadership role of account management, working with one of the tier one operators across the US, working into more of a solutions and products role, has done business development and product management back in the days. Really looking forward to the chat later today. >> Very cool. It sounds like you have both mix of engineering and also the business side and very curious to dive into all of your leadership experience as well. Euteu, would you like to introduce yourself? >> Thanks Jeremy. I am the co-founded CEO of Squatify, a team optimization platform, which links and develops performance inside teams in organizations. My background is 20 years in a global leadership, leading a global leadership development consultancy, drawing all the learnings out of that, working with Fortune 500 organizations, and then creating a platform which will enable teams everywhere and anywhere to improve their performance. >> Absolutely. I love the dynamic we have here, where Attil can go deep dive into his own career learnings. NPA can give us the perspective of working and coaching all of these teams all around the world. Here everybody, I'm Jeremy, your moderator here today. I want to start with this question to learn a little bit more about the teams, Euteu, that you manage. How big is your team and how are they structured? Could you brief us also just generally on what they do as well? >> Yeah. Like I mentioned, I'm responsible for tier one customer for US. I have a small team, I would say 20 to 25 people directly reporting to me, who are working on a client location, doing pretty much focus on the network engineering side, and some of the data side. That's what they focus. With NAMM Docs, we have a very metrics organization, where we have some of the offshore teams, some of the remote teams working in different geographies, supporting on an as needed basis, but they have a different team structures. From a solution architect point of view, from a network engineers point of view, from a pre-sales point of view, those are the assets which I use to manage my account, manage my relationship out here. Like a slightly deep diving into what my team role is, from a day to day basis. So we are responsible for one of the tier one customers within US, where they are heavily focused on the engineering side, the network side or do you design a network, how do you optimize the network, where you need coverage, where you need capacity, where you need the, where you are seeing more data utilization. So we are focusing on that side of the world. And then some portion of my team is responsible for the overall network architecture itself. Like how do you define, how do you define the cloud architecture, how do you deploy your network functions, how do you optimize, you know, the big buzzword going on these days is AI. How do you kind of implement your edge architecture as your network functions? So those are the kind of the teams which we are focusing on, on the upcoming technologies as well. Yeah, I got it. I want to dive right into team leadership philosophies. Perhaps going back to you, it will, could you tell us what are, what are your team leadership philosophies? I would say, I have a, I would say two word philosophy, which is team together philosophy, keep it simple, keep it transparent, keep everybody informed and involved basically. So what that means is like every team member has a very focused and a very, I would say specialist role, right? In every, every big organization, you're always kind of focused on one portion of the solution, which you may or may not be able to, which you may in some cases have a project management role where you know the entire product or you may be a kind of a DevOps guy who's kind of building some of the algorithms, right? You don't know what the algorithm will lead up to a product or how the end customers are going to use it together, right? So when I, when I say my team together philosophy is like having each and every team member to know the, the bigger cause of the things which they are doing, right? And how that small portion, which is a very net solution and a very productive work which they are doing, how does it connect it to the bigger scheme of things? And because me being kind of on the, on the front end with the customer itself, like what kind of feedback we are receiving, which features are being more useful than the other and how we can improve some of those features, how we can improve some of our product utilization, product placement within the industry itself. I think, because once you give that end goal feedback to the, to the guy who's building algorithms, the idea starts to flow by itself because eventually there is no one brain who can kind of build the entire solution together, right? And it should, it's another right approach as well because then it's a, it's a directed approach. You are kind of working in a contained environment focusing on to achieve one X goal, right? But if, if you have a team of 20 team members, understand that goal and the ideas are gonna flow in as well from maybe from five of those, maybe 10 of those, right? And they might have an idea which might be better than yours. And which might be, I think there has been a, some of the philosophies, like I think we all know like the Costco example, right, or Amazon example, they tell you what to buy a, not that what you are there to buy, right? So some time to the end customer, you have to tell them what they need instead of they tell you what exact feature you need. And that can only happen because sometimes you as a leader interacting with that three, five set of people at the end customer, you're trying to understand their requirement. And then kind of try to develop that into a product which is, I don't know if it is 70% or 99% accurate, that's the right approach as well, no denying on that fact. But if you have the innovation bubble through from the ground up itself, you don't know what the scenarios are gonna change. I think that's why like the team together approach, generally bubbles up new ideas, goes you into a different directions and then help you achieve much more than what you can achieve with your own knowledge to be precise. - I love what you said about team together. And I'm starting to draw the connections here. Together alignment clarity in the strategy, everybody moving the same direction. Together working together, collaboration, communication. And you also mentioned earlier about innovation, right? And competency. I wanna pass this to Pia here. Can you tell us how this ties into the three Cs and also what the three Cs principles in coaching? - Yeah, I mean, thanks Jeremy. I mean, this is, wow, this is music to my ears and a great start to my morning at all to hear this, to hear your philosophy because we work sometimes with organizations that think they have teams, but they actually have groups of individuals and they're two separate things where, and what defines them is exactly what you've been talking about. So having that common purpose, linking action with purpose with a unifying direction so that everybody can see the part that they play in that bigger picture. And when we looked at teams, we looked at all the research that have been done around teams. We worked with the London School of Economics and we developed these three major conditions that helped to create teams to be successful. And the one that you were talking about is the first one, clarity. So really important that teams know why they're doing what they're doing, what they're doing, and then how they're going to work together to actually achieve that. And quite often what happens, what gets in the way is individual KPIs or OKRs. They get sometimes in the way because then we're focused on our own goals and not seeing that together view of what can be achieved. And then once you've got that direction, then what type of environment or climate, the systems, the processes, but also the culture, the way that you work, the depth that people feel safe enough to offer different ideas. And then finally, the competence of the team. And the skill, technical skill is a given to some degree. It's more the team dynamics. Excuse me, how well do we listen to one another? How do we coach? What's our attitude towards the team? Are we team players? And really interesting to see those 40 questions in Squad of Fire under those three conditions. And we're able to see that really the clarity piece is so instrumental of being the foundation stone. It's very difficult to have a high performing team. If you don't have, as you said that together, what are we actually all collectively shooting for? And what is our piece in that? And then what's our interdependency? What's our hand over? If you imagine the baton change over, we've all seen disastrous baton changer that's in the Olympics, in the relay races, and smooth ones. And that's what happens inside a team. Well, I think that's just to add on what you just said. Like right before this call, I was on a team's call, basically, exactly talking about the kind of the handover part, right? So obviously, all of us being remote now, and at different times, on different locations. So we have a end delivery with one of our customers. And everybody has a portion to play, right? As simple as that. And sometimes, like, you have to run from A to Z. You have to tell your customer only the Z portion, right? But you have to have a guide to A and then handover to B. But if B is not waiting for the A to finish, it's going to set in a pile box, and the food is going to expire at some point of time, right? We all work in a food chain restaurant, where the plate has to be ready before the meal comes down, right? So I think that entire team synchronize. And then, actually, that's what we saw like Kariya today on our call. Like, we can improve our timeline instead of telling the customer that next week will be done and ready. When we did this entire math, put it on a piece of paper, we realized that next Tuesday is realistic. So we are already saving three days. I was like, we obviously, theoretically, all should be working in a synonymous, right? But we all know that anything new happens. We have to build a small process or modify a small process to have the food chain continue to run it before it gets stale. And then all of us need to work in a full rhythm. And that helps overall save time as well. Like, nobody is waiting for it. Everybody expects that it's going to happen at that time. And then you continue to work on your day-to-day stuff. Yeah. Yeah. 100%, 100%. And I love that analogy of, like, you know, you've got to plate up. It is your coordination. And then what tends to happen is because all the members of your team, and particularly, you're in an engineering space, that there sometimes can be the holding on to the technical expertise, but not seeing how it fits in that broader picture. That's a natural. That's a really natural thing. So the leadership element of the team is to show that broader picture and how everything links together. Yeah, not definitely. I've definitely experienced that firsthand as a startup founder, managing teams for the first time in my own experience. I also want to comment. I really relate. You were talking about individual KPIs versus team goals. And, you know, when folks work together as a team, the performance goes up, you know, by 20%. And I relate to this because a decade ago, to throw Microsoft under the bus because I worked there, around the time I joined, they were just transitioning from an individual KPI system, a stack range system, where, you know, there are people on the top and people at the bottom who would be managed out. And to a system that was more about team goals and team performance, and you would be measured by your impact to enabling other team members to succeed. And so I absolutely saw it in effect and sort of that change to more focus on a team. And I think the fault there was the process, right? The process was encouraging the wrong behavior. And I want to transition into process. And I want to hear, Atul, this feels like a bit of a black box mystery sometimes to managers. But how do you, what's your processing system for tracking, measuring productivity and performance over time for your teams? - Yeah, no, I do agree. It's a black box, which tools and system we have in place, whether we are happy with that tools and system in place or not, I think that I'll leave it open ended without answering. But because I think that's why I think like the example that you gave right in your past life, having an individual role and an individual KPIs to calculate, measure on an annual basis, right? On on a quarter basis. That's, for me, that's a very, very long time, right? And all of us have an up and down in our, in our motivation, in our career path and in a successful delivery as well, right? We all have, we all have successful, we have done more than 110% most of the time and has done 70% in some of the projects as well, right? And obviously not to mention we all have been blamed for that 70% more than we should have and less, less wow factor or a less thank you for the 110% when we delivered. Although the proportion was this proportion on both sides, right? I think that's what I prefer to avoid and try to avoid with my teams as well, right? Obviously all of us are not gonna be 110% on each and every project and each and every task which is gonna be assigned to us, right? There are gonna be some hiccups, some failures that is bound to happen. How, and obviously, wish list is how do we make it, how do we make our success rate more than 99 or 99.9? I never recommend 100%, I never want to reach 100% because failures is a learning as well, right? At the end of the day, not that I plan a failure, but not to kind of get into a, I would say detailed RCA of the failures itself, right? I don't get into bog down stage of like I have a seven day figure out of an RCA of a issue, right? Have a high level finding because I think all of us know that we are about to fail or we are gonna have a delay or whatever those reasons are. It's pretty obvious to a leadership team as well as at an individual level as well. I think the idea is to kind of find out the issues, how do we, if we need, if it's a process impacting, impact the process, change the process, find out, or if it is an individual contribution error as well, right? All of us has individual contributors who are not team players has led to successes, has led to the failures as well in the past two, right? So I think the way I measure individual is measure towards the team contribution itself, right? How do they gel along with the team? How they are supporting each other? I think that KPI is obviously, there's no, we don't have any systems in place to kind of measure those to the way I'm talking, I would say a bit philosophical to say that because I don't think systems exist to kind of measure these things. But I think that's the, that's the, that's the area of approach I try to focus. Although there are individual goals, which we have systems in place, which we put it in, what we have to achieve and all of us try to achieve or surpass those achievements as well. But as of today, systems are cut out for as an individual contributor, individual success, individual KPIs, not as a team KPI, not as a team success. Team success is more, more as a, more as a word of mouth, more as a success factor than the KRI system in itself. - I wanna comment on a couple of things there. First, I'll do a shameless plug for our team, Squatify here, because it is such a system, that's why the team invented it. Teams like Salesforce, Anithy, and they use Squatify to look at specific issues, take actions, track improvements, month over month. It helps build engagement and accountability. The second thing was I actually wanna dive deeper into what you were talking about this. I love the approach and it sounds like you're building this culture, 99% 100% empathy for engineering. And I'm wondering, is there a process? Is there a, how do you execute that? Is this lead by example, all hands? Is this one on one meetings with managers, hiring the right managers, training the managers to sort of spread, you know, the culture that you're building? Do you, how do you implement that idea? - I would say you picked the word basically lead by example, is the way of working over here. I think that has been the approach, which has been successful. And I think that is visible and kind of easy to transmit it out as well, right? So, like I said, there's no systems in place theoretically or with punch it in any systems to kind of showcase broadcast without as well. I think that has been the right approach. And that's the culture, which I try to build it within the team itself, that whether it's a, whether the team member who's asking anything from any particular information from you or any support from you, whether it's part of your team or from any edge joining team as well, how do you kind of share that information and make, I would say, make all the findings and sharing, obviously now being all these cloud data sharing in place as well, make it as conveniently shareable as possible instead of holding the data to yourself. I think I know Pia gave an example earlier from a technology point of, from engineering point of view, everybody is kind of focused towards holding onto that information more and more. But I think that culture has shifted to a great extent at least within my team as well, which obviously I try to do it as well, put everything at the share point itself, make it all accessible, not open to the public, but kind of shared within the groups or in the adjoining groups as well, so that we don't kind of create a spam for everyone. But at least make it shareable that they don't, they don't have to know me or call me to get that information, it's at a common repository available, repurpose, whatever they need to, that has been a kind of a mantra for success. And that's how I would say, that has led to some of my team members contributing to the same culture as well and the same philosophy to instead of holding the data to themselves, make it more weekly, bi-weekly, monthly, knowledge sharing sessions, all of those, has started to happen and kind of be available and open and up for the grab as well. - Absolutely, sharing learnings. And we appreciate you sharing your learnings here today with our community as well. I wanna switch gears and dive into, I wanna ask both of you this, stories of challenges that team leadership challenges that you face and how you overcame them. I'll turn to Pia first with this question. Could you give us, show us a story of a team that you coached, a challenge that they started off with and how you helped them overcome that challenge, short-term and also the long-term impacts of that? - So I think, I mean, there's a number of different user cases here and so I'll pick one or two just as soon as an illustration. Quite often, teams start working with us and they think they're a team. And then the process when they undergo Squatify and they actually then are able to look at data that they have given about themselves, then they start to see that actually they're a group of individuals. Quite often, if you see it a leadership team, they're functional leaders in a team, not an enterprise team, so which is a completely different thing. So, and it's quite interesting that awakening. I think there is a choice point when you're working with a team. Do we either carry on as masquerading as a team when we're really a group of individuals or do we now start leaning into what are those things that are gonna accelerate us? How we create that sense of shared goals? How we dig deeper in terms of our communication, our transparency, how we build greater levels of psychological safety inside the team. And I'm with many technical teams that have started as that, and that realization actually we're a group. And I have a wonderful team that I'm working with that periodically, every sort of six months, they look back and go, wow, look at the distance that we've come. We are evolving as we go through this process. So, they are better able to make strategic decisions, to challenge one another. And that challenging the status quo is a big gap inside our global data set for teams. That doesn't come easily. And you have to have a level of trust and transparency, and you have to build those levels of connections across the team to be able to do that. But what you see is a real accelerating of those capacities. And then of course, what happens is, those leaders inside that leadership team become better leaders of their own functions. So the whole thing starts to cascade and you get that flow on effect. But I'm working with a team now that is just becoming increasingly diligent about their outcomes, how they're tracking, what the interactions are across the team between each other, the levels of transparency. In order to deliver more effectively on time, on budget, which is literally how they are measured. But it's all seeing that the interactions of this team is a causal impact of those outcomes, which is a big evolution. - Okay, I wanna dive into something you said a little bit more. Could you help share with us what are some signs that because mindfulness and self-awareness, right, if you're working as a team or not, was one of the big issues. What are some signs for our audience can look for if we're actually a team of individuals and not working as a team? And a follow-up, what are some signs that that's improving, right, and what's sort of the effect of that? - So if I give a context piece, so a lot of the teams that we work with have been in sort of posts, shockwaves from COVID. And there's been a lot of organizations that are in restructure and in change and transformation. So that's the context that people are working in. So some of the things that you see inside teams are what people might believe is some dysfunction, but actually is an impact of some of those workplace changes. So they may see that there is frustration, there is unresolved tension, there is sometimes a slowness in decision-making, there is poor allocation of the work across the team and there is an overall frustration about the lack of resources that are inside the team. We'd all like more time, more money and more people. They're just, that's just a given. But really interesting that the question in Squatify enough resources to get the job done was for a couple of years, the biggest gap in the whole Christian set between the importance, what people wanted it to be and what it is. Now it's dropped to number four and number one is understanding how to work together. That is the number one gap in teams. So what teams are realizing is we, of course I'm a highly competent individual, but I might be butting up against and having frustrations with other people in my team. All the second gap is a challenge of safety, the ability to challenge the status quo. So actually people don't speak up. So they're holding onto that frustration and then there's that sense of we're not being really transparent here and that slows the team down. So it's sort of, it's not dysfunction, but there are dysfunctional elements in the team. And I think that's at which when we work on the clarity side of things, unifies, that speeds literally in 90 days, you can speed and accelerate that teamwork amongst the team because they then have a unifying goal and they realize where some of those frustrations may be lying. - Angel, I remember speaking with you in the past, I'm curious if you have any similar experiences of overcoming frustrations or maybe even how team members work together, whether they want to work together, right? Or things like that. I'm curious to hear a story of challenges that you've overcome as well. - Yeah, not definitely there are quite a few stories, I think some of the examples we already took it as well. But I know we all have examples of COVID, but I'll take it before COVID basically. But before COVID era, when I recently moved to Northern California, almost like 12, 15 years back, we wanted to expand into, when I moved here, so we kind of started doing some of the network services. It was very, very localized work, very small team. We kind of moved to Northern California. We kind of hired a bunch of guys, individual contributor experts and their domain, like PMH and so very focused, very diligent. Initially, that was our kind of a first ever project. I was the lead there, so we started working on that. And then we realized like, this is, as a company, car leaders at that time of realized that we are really going against the really big giants, right? Like Ericsson's of the world. And this is not the model we can kind of continue to duplicate because having five or 10 resources, all experts, domain experts sitting at one location, right? And then if we move to another region, then hire another 10 experts, hire another hire another right, which is a never ending. And everybody's a domain expert, and we all have to generate as well one or two leaves, your projects really fall apart. So that kind of transpired the conversation, let's build a remote center. We start getting into that thought process. Okay, if we kind of take it back to our, still within the US, but to our kind of other centers where we can have a pool of resources, we're gonna start supporting your market only, but at least they are still started to work in offline mode. So that's where some of the challenge and friction starts to happen, right? Because suddenly the domain expert just start to kind of lose their focus, lose their energy because some experts on at some other location is supposed to do their work, right? But kind of bringing that was kind of one of the challenges because at the initial startup stage and the starting stage, when you have an X work done from an Y person, there are quality challenges, there are timeline challenges because it's on a different time zone. Now, obviously, if you're an individual, you can do that stuff in two hours, four hours, three hours. You're a dedicated guy for it, once it goes to a pool, then it becomes a 24 hour 48 hour SLD, right? To start with, obviously, because there's only one guy out there. Slowly, while the team building is happening, right? And so the word challenge is to kind of onboard that new concept, onboard the centralization concept, maybe some of the training exercises that was supposed to be done from the domain experts. But once they start to realize that instead of being a domain expert and being focused, once they start to see a career path that instead of being an individual contributor, they can be a team leader, they can support 10 markets, they can have 50 people supporting the task. Instead of going over, going after only the legacy technology, they can start focusing on the new technology, they will have the bandwidth, they'll be representing overall as an MDOCs to the customer instead of being an expert domain expert into it. That's when the thought process started to change. We started to kind of learn like instead of having a delivery of four hour or the move or being sitting next to you with the customer to kind of making some of those changes or some of those data engineering report, better get it done offloading from some other team members as well, that starts to trigger and that starts to expand. Once they start seeing an expansion that as an MDOCs, the way we have the team structure, once the client starts to see it, we started to expand the domain experts who are like four or five. Now they have 15 other guys who are kind of supporting it, getting things done and they are focusing on the next 4G, 5G of the world, basically. That's when the dynamic starts to change, basically. So, obviously there were initial level of friction in that initial level of pushbacks, initial level of delays, you know, the typical finger pointing blame games. But I think once they start to realize the real picture, once they start to realize their own growth path as well, which is the overall growth of the company itself, I think things starts to maneuver in the right direction. So, there are obviously challenges to start something new. There is always a team who wants to go at 1,000 miles per hour. There are team members who wants to stay consistent, stay focused, follow the process, follow it to the T, and then instead of innovating, wants to kind of, I would say, fix everything to a 99.99 percent, right? So both are as valuable to each other because you need to have an efficiency, you need to have an innovation, you need to have a solid process in place because neither success is either easy, and success becomes harder after a failure as well, right? Because customers are going to remember your failures more than your success is, right? We all know that as a KPI, once you fail, your manager is going to kind of talk about that for next two years, your customers are going to talk about that for next two years, even though you have delivered 10 other projects before time as well, right? So it's a fine balance of innovation, speed, and consistency, which you need to kind of follow through. When you are kind of expanding your team, when you are seeing the friction, how do you remove the friction, how do you kind of take it as an opportunity, how do you give the opportunity to the right guys, and then structure the team accordingly for the success? - Wow. There was so much in there, and thank you for sharing that with us. I especially, what resonated with me was, you tied the personal career growth plus the business growth, seeing the impact, right, of their work. And all sort of using as motivational factors to implement this change. I was curious, did you just sort of come across that strategy or just start having this idea and experiment the strategy, or did you learn, like, where did you learn that? Did you learn that from your own mentor or manager? Or, you know? - I would say, so the way I will be transparent on that end is we know quite a few industries following the same methodology. This was first to be implemented within MDOCs itself, within our group itself, because it was a new work, new opportunity, because so far our focus has been very client focused, very location focused. That was like, it was before COVID days, when everything was to be on premise. So that was the structure, right? So nothing remote. Nobody talks about remote back in the days, right? So, but having a common team structure. But if you say, like, this is not the first thing which I came up with an idea, because this is the way Verix and Nokia's Google Amazon, everybody works for so many years, because all of their teams are not contained at one location, right? Obviously now they are more dispersed than before the COVID days. They do have teams, they also try to have their teams in a one common office, right? Whether it's a Seattle or California or anywhere, they have that same team at a most of the time at the same location, while their parallel teams might be in other office location or somewhere else, right? Because obviously all big giant organization have so many teams, and obviously everybody is not at the same location, right? But they collaborate with each other, wherever the less interaction points are, I think that's when they start, when they used to separate it out, right? But in our case, this was supposed to be a daily interaction, like in the night the data gets processed, in the morning the report starts to come out. So we started to see a benefit of it that having a different time zone who starts a bit early, kind of get you a stuff ready by the 9 a.m., you come in the morning, became a success story for us as well. But there are like so many industries following the same methodology, but it was first for our side of the group to kind of onboard that kind of culture in our team. - Got it. So, you know, the last topic I want to discuss with you all is your career learnings, and I want to ask both of you this question as well, and we can start with PIA here. What would you say is your most important career learning in engineering team leadership? - So, and I've had the pleasure of working with engineering leaderships for teams for about 20 years now, which, you know, shows my age probably. And what I see is the domain expertise that you talked about at all is so important. It's like the foundation. You have to be good at what you know. And, but in order to fit into the whole delivery machine, there is a lot of gray, and you can't necessarily control that. So, building the other skills around the domain technical expertise becomes as important as the technical expertise. So, I find that in that leadership, when you are open to reflecting, to learning, to actually being aware that it's never a finished job. You don't reach a sort of a peak of leadership and then that's it, because the situation changes and you're building greater stakeholder networks. You're able to influence more people. You're able to become more strategic and create better value proposition inside the organization. Your technical capacity, as you evolve in that leadership, sometimes that technical capacity doesn't evolve at the rate that your leadership evolves. And it's being open to doing that, means that you can really amplify your engineering and technical leadership to a much broader audience, which I think sounds at all exactly the journey that you've been on and what you propose. But I think that's a choice point for leaders. And you probably work with leaders that want to hold on to their domain expertise and don't necessarily want to go into the gray area of leading other leaders to achieve that. - Yeah, not definitely, Pia, I think. You mentioned it perfectly. I have some of my team members who wants to hold on to that domain knowledge and wants to grow in that path. And sorry for that, some of the guys, kind of the growth stopped at a certain point of time. And I had quite a few discussions with them. I was like, what your focus area is? You're kind of reaching out to your limits unless you start getting into the leadership side of the roles or start developing a new skill set. This is kind of, you are gonna peek out at certain point of time, right? At certain stages, in certain part of the careers. That starts to happen and that's not the right thing, but that's the problem which happens in certain domain expertise. Obviously, there are certain domain which where you need that special expertise. Obviously, I come from an engineering background. I come from a hands-on design experts who likes to do network design. And I know one of my mentors back in the days told me, and he took me to some of the meetings. I was not the most vocal guy in those meetings. He said, like, yeah, just sit with me, learn from me. I don't know what he saw at that point of time. I'm talking about 15 years back. He said, like, just sit with me and start to learn. I want to groom you in this direction because that's the right path. You don't have to do it today or tomorrow, but start focusing in that, start kind of changing the lane. So that's slowly area. At some point of time, you will change the lane and start going in that direction. I'm still thankful to him that he started moving my car in the second lane. That helps me where I'm currently today. And I have tried for some of the guys. Some guys have changed the lanes. Some guys didn't change the lane. They want to stick with their own base of working with their lane as well. Not that one is more successful than the other, but if I have to give you my viewpoint, if you don't change the lane, I think whoever has changed the lane has been more successful than whoever hasn't. So that will be my viewpoint. I think overall as a journey, I think all of us needs to learn new things. It's not the technology or the leadership principles or how do you manage the team. I think it's said some mix of everything. It's a mix of everything because you cannot be as domain expert as you are 10 years back. But you need to know enough, because you come from that background, you are always getting attracted towards it. You always need to know enough as well so that you can guide the team too. Because we all have been burnt by the fact in the past that somebody non-technical or kind of from a non-engineering background came as a leader, which has an entirely different thought process. Sometimes it has been, is a good learning. Sometimes it has been a bad learning as well, right? So I don't know which one I got. I won't mention that here, but you all have seen a bit of the stories right at the end of the day. - And what you mentioned at all is something called the Ram Sharan road, a brilliant book. Actually, now nearly 20 years ago, but it holds true, called the leadership pipeline. And that looks at your journey from an individual contributor to a team leader, to a manager, manager of managers, function business leader, enterprise leader. And the premise of it is, is that each of them, like you talk changing lanes, at each transition, you need to stop doing 30% of what made you successful and be open to a new 30% in the way that you value your time, new different set of skills. And it's that choice point, because some people don't want to let go of what's been successful. But it's unlikely that what you were doing will equip you to the future of what you would like to be doing, unless it's the same. - Yeah, no, I think you mentioned it perfectly, like you have to let go of what you were doing. I never read that book, but 30%, I think that's a good point, which everybody should take, to continue to kind of not leave the past or leave the past experience. But I think create a space, right? I mean, all of us are kind of overwhelmingly busy all the time. I think create a space in your mind, create a space in your work style as well, to kind of start learning something new, right? Whether you want to go into a different domain direction or into a leadership direction, right? It doesn't matter at the end of the day. I think it's the change, which is always needed to kind of help you grow, because if you want to climb up the ladder in either way, shape or form, because you're all professional, that's what our end goal is at eventually at the end of the day. That's the way to do it. Yeah. - Well, thank you all. The last question here is, who should reach out to you and what's the best way to reach you? I told you, would you like to go first? - What did you ask, Mike? - Oh, who should reach out to you and what's the best way to reach you? Yeah, who's from the community? Yeah, engage. - Yeah, so I would say I'm available on LinkedIn and if anybody wants to reach out to me, I'm not mentioning my phone number here, but most of them to reach my LinkedIn contact. Full name is Etul Kahana. Who should reach out to me? I would say any technical domain experts who are working in the telco domain or the business development product solution side. I kind of expertly, my expertise kind of fall into that region. And obviously based in the US, if any expertise, any support you need, I'm always welcome to help. - Awesome, and fear. - I think it's a similar thing. So leaders who are looking to evolve with their team, looking for high performance, looking to measure, so to create a tangible way to be able to see what all these things that we've talked about in a measurable way can create that blueprint for success. LinkedIn, very active on there. So my is Pia Lee. There aren't many of them names like that on LinkedIn. So I'm very, very interested to receive requests and messaging with people. - Awesome, and links will be in the description. That's the end of our episode here today. I wanna say thank you to Etul, thank you Pia for speaking. Everybody, thanks for listening and we'll see y'all next time.
