"Is People Management the Right Path for Me?" (Video & Transcript)

"You can never do the work of 10 engineers, but if you enable 10 engineers, you can really feel vicariously that ‘I had this impact.’" - Vibha Rathi

"People management is not always the glamorous role. A lot of people assume it is very glamorous. That's not the truth. It has a lot of responsibility because anything that touches people, it influences people's experience." - Sri Koneru

Join Sri Koneru (Cloud Product Infrastructure Lead at Confluent) and Vibha Rathi (Climate Engineering Team Lead at MSCI) as they share their authentic journeys from senior engineers to engineering managers. This candid conversation explores the challenges, opportunities, and key skills needed to successfully transition from coding to leading teams, offering practical advice for engineers considering the management path.

Sri Koneru is a seasoned leader with a remarkable history of scaling teams, technical platforms, and products across diverse industries, encompassing more than 14 years of technical people management and leadership in e-commerce, payments, and cloud infrastructure.

Vibha Rathi is a hands-on engineering leader with more than five years of experience leading platform and product engineering teams including managing managers.

Heidi Williams is the Founder of WEST and CTO at Murmuration.

Transcript has been edited for clarity.

Sri Koneru: Hi everybody. Nice to meet you. My name is Sri. I currently lead the cloud product infra at Confluent. Prior to that, I was at Facebook, PayPal, eBay, consulting companies like Accenture, American Management Systems, and some startups. So that's a little about me.

Have been working in this industry for a long time. Worked as an individual contributor for over 10-plus years and in a leadership role for the past 12-plus years. So that's a little about me.

I'll get to the second part of the question, which is what is my entry into leadership? So this is back in 2010. This was at eBay, where I was a staff engineer on the experimentation platform. So the domain itself was fairly new to me, and I was working with this amazing set of leaders, got very inspired to learn more about the domain. So what I did, out of curiosity and motivated by the leadership, is I started reading about experimentation.

I started understanding a little more about, not just building the platform, but seeing what is the end-to-end impact of the platform, the customers, the upstream, downstream, once an experiment is done. So the whole life cycle, and out of natural curiosity, I started getting involved into any problems that would come up with experiments.

So after reading a few books on experimentation and statistics, I took on more interest to go and pursue business statistics. And this is out of my own personal time and extension campus, doing courses evening and weekends.

After that, I went even one step further and signed up for design and analysis of experiments at MIT. This is the journey, and I was really doing well as an individual contributor because as I started building that expertise, I started getting that attention as well as being pulled into a lot of important discussions and being at the table.

So enjoying the role as an individual contributor.

So around this time, there was one experiment at eBay that didn't go well, and this was not in the list of experiments that was in my radar to focus on. However, I was very curious what the problem was. And so I spent the weekend going and helping my team because during the week I didn't have the bandwidth to spend time on this. And the reason why I'm sharing about this is to tell you how the leadership journey happened.

So when I went, it was the problem. I was very curious what is happening, and the team was struggling. So I went and spent, debugged, triaged, very complex issue, but we nailed it. And the surprise was the following week, the leader of the other team that was going through this experiment surprised me with a box of energy bars.

So they were sitting on my desk, I was like, wow, this never happened to me. And was very pleasantly surprised.

And then I got a call asking for more information about the experiment, and answered all that. So fast forward a couple of months down the lane, early 2011, that is when there was an opportunity that opened up in this leadership org. And somehow I got to know about the opportunity, and I got pulled in into some conversations. It unfolded itself. So this is a leadership opportunity to manage the checkout platform, order management system at eBay.

Now the choice, the decision making, was I invested so much time, and I'm really enjoying my role as a staff engineer on the experimentation. Do I want to go and start doing people management as well as being a manager level one on a completely different team, a core revenue-critical system? It's going to be extremely busy. So yeah, it was a tough time. I mean tough time to make a choice because both seemed very attractive. I think it was around that, that I had a conversation with my mentor and we discussed the pros, cons, and what is it that I feel excited about? So my mentor could see I really felt very excited about leading a team, a charter, not just a domain. And I said, okay, why not try? I took the leap forward, had a great support from the leadership, from the new team. So that was my entry into management.

Heidi Williams: I love that. Yeah, I think certainly curiosity can open doors. So I love that you're just exploring that and then being recognized for that and then being invited to influence more. So that's great. How about you, Vibha?

Vibha Rathi: Yeah, so I currently lead the climate engineering team at MSCI. A lot of people don't know what is climate engineering. I didn't know much before I joined this company as well. And it's a really cool space, actually.

So MSCI is basically a financial data provider for companies and investors. And what we do is we scour the internet, the company's own financial records, publicly available climate and sustainability data, and then we build insights on top of all these sources of data and position it to investors and companies that, oh, here are some opportunities to lower your carbon footprint, or this is your year over year emission growth, or this is your hazard risk in terms of...McDonald's, like 20% of your locations are prone to tropical cyclones. So, next real estate investment that you make, would you like to make it somewhere else?

So we like to provide all these rich sources of climate data to help companies and investors.

And also, awareness is everything. Our hope is if companies, investors are more aware of this, they will take more measures to be sustainable. And then we have this overall success of fighting climate change, if you may. So that's what I do currently: I lead a team on climate engineering in MSCI.

Before this, I worked on customer support engineering for autonomous vehicles at Cruise. Cruise is a Waymo competitor. We were testing in five cities. I don't know if people in SF, you've seen Cruise cars going around? So that was also very interesting.

And then I also spent time at Meta working on Facebook Groups, another one of my favorite products to ever work on. And then at Microsoft in two stints: on Teams and B2C identity in my last stint.

So going to the second part of the question on what was my transition to management, it sort of naturally happened, and I was one of those people who was trying to avoid management.

I was like, I don't want to do this. I mean, like somebody put in the chat, why would you ever do this? I was one of those people, at least early in my career. But then I found that as I grew more senior, especially at Meta, I started to naturally run teams. The pace is really fast, and somebody needs to come and start leading. Nobody will ask you. Somebody just has to say, okay, how about you do this, and I'll do this, and let's talk to that team, and let's make everything pull together. So I sort of naturally started leading and running projects at Meta.

And the aha moment for me was that I had been avoiding this. I was like, it feels so much better to have impact as a team as opposed to as an IC. And you can actually have oversized impact with a team.

You can never do the work of 10 engineers, but if you enable 10 engineers, you can really feel vicariously that I had this impact. So I really loved that feeling. And I also found I'm growing new muscles. Being a manager now for almost five years, I feel I'm learning new things. Your technical stuff doesn't help you all the time. It's a lot about influence without authority. It is about building those relationships. It is about keeping people accountable, even if you want to just be liked and so on and so forth. But sometimes you have to be the bad cop and keep people accountable. So yeah, I think I just sort of naturally fell into it, and I think I love it now. Yeah.

Heidi Williams: That's awesome. I love that. I feel like, as an engineer, we have problem-solving brains. And I always think the fun part is thinking about the people problem-solving that needs to happen. And I remember, it was not a tech lead, but I was a team lead, and basically my job was to help manage feature teams where you had engineers and QA, and there were a few that had really contentious relationships, and they couldn't get anything done.

And so I loved going in there and debugging, why can't we move forward? We're all working on the same thing, et cetera. And I realized I have a passion for that kind of problem-solving, as well. And I think that does come up more as a people manager. It's just the problems are not all in code. They expand out maybe organizational, et cetera, et cetera.

So, sort of flipping the question a little bit too, because I think, as I said, when I started, I was a team lead, not a tech lead. I think now the industry does have roles where individual contributors can be influential. They can, if they want to, be working on people problems and moving projects forward, and having impact. But if you had to think about what are the factors that senior engineers should consider when thinking about people management, what are the things that you feel like really separate, motivate, or feel like how success is different? What should engineers think about? Vibha, do you want to start?

Vibha Rathi: Yes. So in preparation to this, I was thinking what should one consider? And I think a lot of it is what I said in my intro, you have to enjoy succeeding through team. You should enjoy the people aspect of it a little bit. If you are an introvert and you really hate dealing with people, I don't think you would feel happy as a people manager or be very successful. And again, the desire to keep learning, keep teaching, keep coaching, and not having that mindset that I really just want to focus on this, please leave me alone. You have to be adaptable, be open to building any muscle. So it's kind of like doing whatever it takes as a manager and as a leader. And I tell this to my team, I say, everybody's a leader. You don't need a manager title to be a leader.

And in order to be a leader, you have to be adaptable, you have to be flexible, and you have to be always open to learning, and you have to enjoy the people aspect of it. You have to enjoy success through others. And my style, which I think a lot of people's style, is that it's really true...It's servant leadership, right? If your team doesn't succeed, there's no point, really. Your job is really to enable others, stay in the background almost, but deliver through your people. You are not delivering individually, I think.

And then another thing that I would like to call out is that you should be interested in the business and strategy as well. Because when you're a people manager, especially growing into maybe the second level, going away from frontline management, you sort of become like a CEO of your small team. So you have to understand how much money do I have? How many people can I hire? What skills do I need to hire for? How do I make more money so I can hire more people? Or how do I drive impact for my small team? I'm a little CEO trying to make my team a success. So I think having that maybe entrepreneurial mindset also helped.

Heidi Williams: Yeah, thank you. And Sri, anything to add there?

Sri Koneru: Yeah, I think we covered most of it. So I'll just add one different perspective to this. So as an individual contributor, I mean if you are in a senior engineering role, you are already a leader in different ways. You are doing influence without authority and influencing the technical charter and the engineers that you're working with.

Now, moving to people management is making a conscious choice that you want to play a more role of influence. Influence, not just on the technical charter, influence on the people and the process that enables this org charter and team to succeed. Now, one of the things as a engineer you want to consider is, have you built systems that you feel very proud of?

Because once you become a people leader, you always gravitate towards your core discipline of building things. So if you feel like you have done it and you want to explore something more challenging, definitely try it out.

The second one is, I tell this to engineers who reach out to me, people management is not always the glamorous role. A lot of people assume it is very glamorous. That's not the truth. It has a lot of responsibility because anything that touches people, it influences people's experience. It's not just contained to the job. It is you're impacting how people feel emotionally at home. It has an impact on many things.

So if you are a person, when you wake up, do you wake up with, you want to solve a technical problem or you want to gravitate, you feel very passionate about the technology, then continue being in the IC role. If you are a person who loves to solve problems, whatever it is, because a people manager, the buck stops at you. You own it, you figure it out, you can't pass the buck to someone else. So you enjoy problem-solving, and there are no boundaries. Definitely embrace it. It's worth trying. It's not an easy job, but it's very fulfilling if you do it right.

Heidi Williams: Yeah, I love that. It's funny, I was just reflecting that as I was putting together my profile for the conference, is sort of, what is a career highlight? And I actually think my career highlight is helping a particular person that I used to work with that was underappreciated, a little awkward, but helping them achieve their full potential, and just seeing the impact that they've had in their career, rising into a principal engineer and architect, and eventually getting the opportunity to share their amazing insights with others.

And I do think there's a very complementary skillset there between an engineering leader and a technical leader or an architect. There are a lot of things that are overlapping around influencing and leadership and things like that. But are there some other things that, and you sort of came at it, where technical leaders are coming at things maybe from a technical perspective, whereas managers might be coming from a people perspective? Anything either of you want to add about differences or maybe complementary skills that you see between technical leaders and engineering managers?

Sri Koneru: Maybe I'll take that first. Okay, so as you grow higher and higher in your career, the differences are very minimal because you are effectively playing a role of influence without direct authority over multiple things. So being good at what you are doing, having your core competencies is important, but at the same time, at a higher level, it is more about collaboration, bringing alignment.

If you look at one of the most significant or complex problems any organization has, it is about alignment. If you can, whether you are an individual contributor or a leader, how you can drive alignment is the most critical thing. And influence decision-making, being able to drive things. I think that is the primary thing. And they overlap as you grow higher in your career.

Heidi Williams: Yeah [cross-talk] go ahead.

Vibha Rathi: Yeah, I want to second that. You might think sometimes when we are junior in our careers, we think, I don't know what these people keep talking about, about strategy and decisions and all that, but as a leader, one wrong decision costs you big time because you are putting a team in charge of building something that is either not valuable or you are going to alienate maybe a good engineer who had a good idea, but the decision was not supportive of their idea. So decision-making and influencing so that the right decisions get taken have huge consequences to the team's productivity and happiness.

Heidi Williams: Yeah, I remember thinking when I sort of switched from an engineer to being a manager, that I was most excited not to just understand what are we building, but why are we building it? What is the context and the strategy and the reasoning behind it?

And then that helps you as an engineer be able to make better decisions on the ground, even if your manager's not there because they've told you, what is the reason that we're doing this? And you can think about, are we actually solving that problem successfully? And maybe thinking about that manager skillset, Vibha, what are some things that you feel like are necessary sort of skills or maybe temperament to really excel as an engineering manager?

Vibha Rathi: I think the same things that I mentioned earlier. Being flexible, being curious, always willing to learn, and acting as an owner. Really, the buck stops with you, what Sri said, and you can't point fingers. And it's really like if your startup fails, coming back to my semi-startup reference, like mini-startup reference, it's kind of on you. So the buck stops with you, and just being flexible, building relationships.

You can't do everything alone. But at the same time, I also love to be on the ground working in the weeds, stay technical because you might, again, if you are the decision-maker and you don't know the details, then you may make a wrong decision. So either cultivate a very trusted bench of people who can communicate with you and inform you, but at the same time, also keep your ear close to the ground. So those are the things that I think make an engineering manager successful.

Heidi Williams: Great. Anything to add, Sri?

Sri Koneru: Yeah, I mean, thank you for covering...I think you've touched a lot of important aspects around especially strategy and being able to make decisions. So to summarize, I mean, I'll just call out a few things.

I mean, it might help people who are looking at, what does it take to be successful as a manager? There are a couple of things. One is what do I look for in a manager? It is...execution is a given thing. As a manager, you've got to be good at execution, getting things done. It is more around, for example, conflict management. It's an important skill.

There is crisis management, how do you handle crisis? There is change management and being excellent at delegation. And obviously, I mean all these things, they don't happen overnight. It comes. Some of it is you build incrementally each of these things over a period of time.

So those are effectively a set of skills that differentiate leaders. Another one is if somebody is looking at what are the skills they have and how do they want to match with what they need to work on? So there are so many frameworks you can check your strengths using.

There's so many online tools like Clifton's Strength Finder, that's one. Another one is there are Lominger competencies. You have about 67 competencies and you can bucketize them into different things. Strategy is one thing that we back on called out. Another one is around your own personal skills, your communication skills, your operating skills. So definitely take a look at that and it's not like you have to check off everything. It is, see what you gravitate towards and build on those.

The second one is, I think, Heidi, you asked the question around temperament. So which, I think, I mean say, look, human beings, people in general are good. So we all have our own experiences in life that shape our different skills around patience and tolerance, the grit and things like that. So my input is as long as you can be yourself, and you can work towards those competencies that are needed, and you have the grit to deal with challenges, I think you'll be fine.

Heidi Williams: Great, thank you. Well, maybe switching gears a little bit and thinking about challenges and also strategies navigating the transition to being a manager. So maybe think back to when you first became a manager or if you've sort of managed managers and coached others on how to make this transition successfully. Maybe starting with what unique challenges and opportunities do you see arise when switching from coding to managing teams? What are some of the first difficulties? I dunno if, Sri, you want to start?

Sri Koneru: Sure, yeah. Okay. As a individual contributor, you are very focused on building things and developing. You're very hands-on, right?

Now, when you switch into a manager, it's no longer primarily about you and your coding skills. That is how you can, the first thing is, do you want to take control or give control, right? What I mean by that is you're working with a team of engineers. Now, as an engineer, how did you feel respected? Is your manager getting into your way of everything you are doing? Or did your manager trust you and give you that freedom?

So that is one thing. It is earn the permission to lead the team and which happens by how you build that trust and relationship. So I mean, I haven't been so perfect. When I switched gears from an IC into leadership, though I had all the right intent and the right wins early.

The First 90 Days is a great book if you want to follow that. And I followed that diligently to the dot. The thing is, a lot of this comes with experience, and one thing that is constant is change, and people, as much as they're very nice and very, there is enough things, the same person can be very different if somebody honked at them while they were driving to work. So you got to understand the dynamics. So it took me a while to learn that, and I feel like I have definitely gotten a lot better than what I was initially.

So these are things that I would say, some of the things initially stepping away from your primary duties and responsibilities as an IC and embracing it, what it takes to make your team successful.

Heidi Williams: Vibha, you had some great things, too, that were interesting challenges. Do you want to share those?

Vibha Rathi: Yeah, definitely. So I have a few, I think, and like Sri, I also, I think you fail and learn. So I don't know that my transition was entirely smooth, either. And that's okay. We have to jump in and learn, and we will fail. Hopefully, we won't fail with something big. So one of my first challenges was, so as an engineer, as an IC, you have a lot of agency. You can just go and write the code yourself, or you can just do it yourself. And there is this instinct that all first-time managers have to go and do it themselves.

So learning to delegate and teach others to do it, because that's not a scalable model where you can jump in and do it yourself. So learning to teach and drive accountability and step away, give up control, was a little bit hard. And then the second thing was something one of my previous managers taught me, he said, just like in real estate, you have location, location, location.

In engineering management, you have execution, execution, execution. And I always remember that because sometimes you have to step into project management. And again, coming back to just doing whatever it takes to ship the thing. And you might rub people a little bit the wrong way here and there, but when the team succeeds, everybody succeeds. So just staying laser-focused on execution.

And one more very good quote or philosophy that I learned at Microsoft is as a manager, the best way to improve execution is driving clarity and bringing energy. So those two things: have everybody understand exactly what they should be doing and then giving them full autonomy, agency, energy, kudos, whatever it takes to empower them. So driving clarity and bringing energy, those are two things that help with execution. And I had to learn this. It didn't come very naturally, as I said.

And I think on the personal front, I think we are all women in the room. One of my challenges was also how do I balance little young kids with moving into a people management role somehow? And it's confusing. You don't know. Does your work-life balance improve as a people manager, or does it get worse?

I wasn't sure what was going to happen, but the answer is it's very context-dependent. And in my experience, it kind of stays the same. And it depends on you, how you set your boundaries, how you plan your work. There is no simple statement that, oh, you want better work-life balance, become a manager, or I don't think it works like that, but I had to rethink my schedule a little bit in terms of, as a manager, your day is very meeting-heavy.

As an IC, you can get a lot of your individual work done during the day. So as a manager, sometimes you can find yourself that, oh, I have spent my whole day in meetings and now I need to put in three more hours at night to do my own work. So that's when you're forced to delegate, you're forced to become very strict about prioritization, becoming laser-focused. But it took me some time to strike the right balance. So that was another personal challenge that I had.

Heidi Williams: Yeah, so many interesting ones. Hopefully, we're not scaring people off with so many challenges. But I will say one that really resonated for me was, I do think empathy is my strength, but it's also my greatest weakness. And I think the book Radical Candor, that ruinous empathy, I have been there and it is exactly like you said, you have a job to do. You need to be driving impact. And as much as you want everyone to feel good, at the end of the day, you do need to execute. You need to get things done. And so doing it in an empathetic way, but not letting empathy drag you down to a point where actually all you're doing is just talking and not actually getting things done. So appreciate that.

Well, I would love for us to flip over to questions. We have so many great questions here. I know we didn't get through everything we prepared, but that's fantastic. I'm happy to get to what is top of mind for folks.

I'm going to hop around a little bit, so sorry, not going exactly in order, but one question here from Tina, how do you deal with the challenge of understanding your indirect impact? And I actually think, I know that Tina is a technical lead, so I know she's actually not a people manager, but I think it's an interesting question for both kinds of roles. How do you judge yourself when the actions of others are so interlinked with your direct reports, and the timelines for impact stretch longer? How do you measure your indirect impact?

Vibha Rathi: Sri, do you want to go? Or I can go, as well.

Sri Koneru: Yeah, I mean I can go first. So basically, I'm just trying to get the question right. It is basically while you're working on something, how do you make sure your impact or working with others, you are creating an impact? Is that the question? I'm just trying to....

Heidi Williams: Yeah, and I think, specifically, how do you measure it? How do you actually quantify the impact that you're having?

Sri Koneru: Okay, so first, whatever you are working on, whether it is a common project or something that is tied to a company objective or a key result. So you got to understand what is the role you are playing towards achieving that broader goal? And based on that, you have to extrapolate the impact at your level, what part of it you are playing in the bigger equation.

So first understanding what is the primary objective or the mission or the key result that we are all working towards, and what part of it do you own and what are the metrics that define that?

So let me give an example. Maybe there's a project that touches the customers at the end of the day. Your role, maybe if you're a technical lead on a certain subsystem, what is the role of that subsystem? And then what is the quality of that subsystem? What's the definition of done of that subsystem? Because how many issues did you have after you rolled into production? How well the performance are, the latency and the availability of the system, and just throwing some random examples, but basically understanding your role in that whole equation and extrapolating the metrics that you want to create for your system. That is how I would see it. I don't know if that answers the question, but that's one view.

Heidi Williams: Vibha, anything to add?

Vibha Rathi:

Yeah, I think it's hard to measure. It is intangible in a lot of ways, impact of a manager, but one proxy could be, the scope of your impact should grow over time. It could be that your team grows or the number of projects you deliver grows, or your contribution to the business bottom line grows, but the scope of your impact could be a good proxy for how much impact you're having.

And also people's careers, right? If your team grows, the people grow with you. So yeah, I think those are some of the proxies I use, at least, to measure myself.

Heidi Williams: I think that's great. Yeah. Thank you. And maybe one sort of related question, Shristi would love to hear examples of how people drive alignment across the organization. And this one always...you can certainly measure misalignment. And so maybe you sort of chalk up your successes to those moments where you think, ah, I got something back on track, or I got people on the same page, or whatnot. And so it's almost like the absence of awfulness is the measure of success, but do you have examples of helping people drive alignment or helping drive alignment across your organization? So it may not even be just within your team, but outside of your team as well.

Sri Koneru: Yeah, yeah. Okay. Let me, without getting into the actual details of the projects and things, I'll share an example. There was this large project, and there was this urgency to get it done. And initially, when I started looking at it, it was like there were some thousands of rows in a spreadsheet, and we have to get different teams....This is not just my org, my four teams. It is the whole maybe 20, 20-plus teams have to work together to make this happen.

So when I went in into that situation, suddenly I got pulled in to see what it takes. So it started with looking at that spreadsheet and then trying to comprehend what is it? What do we want to accomplish? What is the goal? What is the objective? And you get different kinds of input from different people you talk to, because if you look at it, the picture that you have on your mind might be very different from the picture on a different person's mind. So how do you bring that same picture and we align on that picture means that you need some framework to bring that together. So clarifying.

So in this case, it came down to what are the requirements that we can write down, and then how can we make sure all the different stakeholders that are involved across different orgs, the org leaders, everybody aligns on that.

And this takes a lot of effort. These don't happen in a meeting. These happen in your one-on-one conversations, and you align and you go forward because the cost of that meeting is very high. So you want to keep it to just making a binary decision: move forward or not? So that is what happened.

So we got the requirements clarified. So in this case, I had to spend multiple weeks to bring the right people, get the requirements solidified, as well as the scope for each one. And how do you create that visualization of things?

So the scope for getting this done came to be huge, and there is no way I can go and sell that and say we can get it done. So we had to trim down the requirements, narrow it down. So once we had that kind of analysis, clarity, and working with different people across the org, irrespective of titles, so that happened, that helped in driving that alignment.

So the other thing I want to add is, now in these conversations, you are talking to at least people two levels above you. So you have to be comfortable in having those communication with the leadership. And in those conversations, it's very important to be very crisp, to the point, and not get into all the details as well.

The second one there, is sometimes you do see the problems. Maybe I'm getting requirements from three different orgs. Maybe from the same org, you are getting requirements from multiple teams for the same project. Now in those cases, it's important to call out, to call the elephant in the room.

"Hey, I see problems here. How can we consolidate and bring it together?" So that...it took me a while to embrace those kind of traits, to be open, transparent, and really not worry about what happens to my [inaudible] things because I feel like if I do that right, I can sleep much more peacefully and my teams will be much more successful.

So I'm not telling anyone or recommending anyone to go pick up a conflict or a fight about something. It is more just be authentic and transparent in your communication. And at times it's also important to say no to certain things, but with enough validation and justifying why and what is the reason. These are things..I mean, I think I feel like those are some things that help in bringing alignment.

Heidi Williams: One thing I would just love to add, too, is I think, to your point, obviously a lot of great communication skills required here, lots of navigating different things. One of the things I find is super helpful is to understand if the other folks you're working for have different goals than you do, because sometimes you're asking them to put some work for this shared project above their own team's goals and projects.

And so understanding, do they actually have a goal that is sort of pulling them in this other direction because they think they're being measured on something differently than what you're asking them to do? And so understanding, what do they say? The road to hell is paved with good intentions.

People are trying to achieve a goal, and they see you as sort of being in the way of achieving that. And so the more you can ask them and understand what are they trying to do, and then sort of pull it back or figure out a way to make those goals more aligned, will ease it or sort of say, let's actually remove how you're being measured so that instead you can be measured on this, which is more important, et cetera, so....

I think we need to stop in one minute. We have a sponsored break from our sponsor. Confluent is sponsoring a coffee break. I encourage everyone to join that. I know we didn't get to all of the questions. The two that we will hopefully follow up on, and I will ask Vibha and Sri for their input, are the questions around books or frameworks that you would recommend to help folks on their management journey.

And then also the question about how do you transition, how do you put forward your interest into becoming a people manager? What are some maybe first steps that you can take along the way to sort of practice some skills, or maybe at least let your manager know that you're interested, they can create opportunities for you.

So, wanted to thank you, Vibha and Sri. It was awesome. So many great insights and encourage everyone to join the coffee chat. If you go back to the lobby, you can join from there. So thank you so much. Hope you all enjoy the rest of the day.

Sri Koneru: Thank you. Thank you, Heidi.