How do you transition from being a strong Engineering Manager to an effective VP of Engineering? What challenges do leaders face as they scale their impact from team execution to organizational strategy?
In this episode of the groCTO Podcast, host Kovid Batra speaks with C S Sriram, VP of Engineering at Betterworks, about his career journey from an engineering manager to a VP role. He shares the hard-earned lessons, leadership principles, and mindset shifts that helped him navigate this transition.
✅ From IC to Leadership: How Sriram overcame early challenges as a new engineering manager and grew into an executive role.
✅ Building a High-Performing Engineering Culture: The principles and frameworks he uses to drive accountability, innovation, and efficiency.
✅ Balancing Business Goals & Technical Excellence: Strategies to prioritize impact, make trade-offs, and maintain quality at scale.
✅ The Role of Mentorship & Coaching: How investing in people accelerates engineering success.
✅ Scaling Leadership with Dashboards & Skip-Level 1:1s: How structured communication helps VPs and Directors manage growing teams effectively.
✅ Closing with Inspiration: Sriram shares a poem he wrote, reflecting on the inner strength and vision required to succeed in leadership.
Kovid Batra: Hi everyone, this is Kovid, back with another episode of groCTO by Typo. Today with us, we have a very special guest. He's VP of Engineering at Betterworks, comes with 20+ years of engineering and leadership experience. Welcome to the show, Sriram.
C S Sriram: Thanks. Thanks so much for having me over, Kovid, and thanks for the opportunity. I really appreciate it.
Kovid Batra: No, it's our pleasure. So, Sriram, uh, today, I think we have a lot to talk about, about your engineering and leadership experience, your journey from an engineering manager to engineering leader. But before we get started on that, there is a small ritual that we follow on this podcast. To know you a little more, we would like to ask you one question. Tell us something about yourself from your childhood, from your teenage that defines you, who you are today. So you have to share something from the past, so that we get to know the real Sriram.
C S Sriram: Sure. Yes. Uh, uh, I think the one thing that I can recall is something that happened when I was in my seventh standard. My then school principal, her name is Mrs. Anjana Rajsekar. I'm still in touch with her. She's a big inspiration for me. She founded and she was running the school that I was studying in. She nudged me towards two things which I think have defined my life. The first thing that she nudged me towards was computers. Until then I hadn't really touched a real computer. That school was the first place where I wrote my very first logo and basic programs. Uh, so that was the first thing. And the second thing that she nudged me towards was just writing in general. And that gave me an interest towards, uh, languages, towards, uh, writing, reading, uh, poetry, short stories, novels, all of that. I think that she kind of created those two very crucial parts of my identity and that's what I would like to share.
Kovid Batra: That's really inspiring actually. Teachers are always great in that sense. Uh, and I think you had one, so I really appreciate that. Thanks for sharing. And, Sriram, is there anything from your writing piece that you would like to share with us? Anything that you find really interesting or that you wrote sometime in the past, which you think would be good to share here?
C S Sriram: Oh, I wasn't prepared for that. Uh..
Kovid Batra: No, that's fine.
C S Sriram: Maybe, maybe towards the end. I'll try and see if I can find something towards the end.
Kovid Batra: Sure, no problem. All right. So getting started with the main section, just to iterate this again, we are going to talk about your engineering leadership journey, specifically from an Engineering Manager to a VP of Engineering at Betterworks. I think the landscape changes, the perspective changes, and there are a lot of aspiring engineering managers engineering leaders who are actually looking towards that career path. So I think this podcast would be really helpful for them to learn and to understand what exactly needs to be there in a person to go through that journey and what challenges, what opportunities come on the way, how to tackle them. So, to start with, I think tell us about your first engineering management experience when you moved in, uh, from, uh, from, uh, let's say a tech lead or an individual contributor role to an EM role and how things changed at that point. How was that experience for you? Was that overwhelming or that came in very easily to you and you were there when you, when you actually arrived in that particular role or responsibility?
C S Sriram: I was a programmer once. So I'll start from index 0 instead of index 1. So I had a, uh, index 0 programmer, uh, engineering management experience where I was given the designation of Engineering Manager for about a month. And I ran back to my CEO and said that I'm not doing management. Uh, take the designation away from me, take the people away from me. I'm not doing it anymore. Uh, that was the index 0 and index 1 was when I started my own software consultancy, roughly about 10 years ago.
Kovid Batra: Okay.
C S Sriram: And then I didn't realize I would have to do management. I just wanted that thrill of running my own business. I guess to paraphrase Shakespeare, you know, "Some people are born managers. Some people are made managers. Some people have management thrust on them." So it was thrust on me. It was my necessity that I got into management and for the first five years, I really messed it up. Because I was running a business, I was also trying to get some coding done for the business. I was also trying to win sales. I was trying to manage the people, recruit them and all of it. I didn't do a great job of it at all. And then when I joined Betterworks was where I think I really did something meaningful with, uh, engineering management. I took the time to study some first principles, understood where I went wrong and corrected. So yeah, that's how I got into management. And it was, uh, it wasn't scary the first time because I didn't know I was doing it. Uh, so I didn't know I was doing a lot of things wrong, so there was no fear there. Uh, but the second time around, when I started in Betterworks, I was very scared that, uh, of a lot of things. There were a lot of insecurities. The fact that I was letting go of control and most of the time intentionally, that was a very scary thing. But yeah, it's, it's comfortable at the moment.
Kovid Batra: Perfect. Perfect. But I'm sure that experience of running a business would have brought a lot of aspects which you could have not learned if you were in a trivial journey of a job where you were a software engineer and then moved into, let's say a tech lead or a management role. I'm sure that piece of your entrepreneurship would have taught you a lot more about bringing more value or bringing more business aspect to the engineering. Was it so?
C S Sriram: A 100% yes. I think the main thing that I learned through that was that software doesn't exist in isolation. A team doesn't exist in isolation. You building the most beautiful user experience or design, you building the most beautiful software, uh, most beautiful piece of code that you've ever written, uh, means nothing if it doesn't generate some sort of business value. I think that was the biggest lesson that I took away from that, because we did a lot of work that I would call as very good engineering work, but extremely poor from the business side. I understood that importance that, you know, it is, it always has to be connected to some business outcome.
Kovid Batra: Great. I think there must be some good examples, some real life examples that you would like to share from your engineering management stint that might revolve around having a good culture, that might revolve around building more or better processes in the team. So could you share something from your start of the journey or maybe something that you're doing today?
C S Sriram: Definitely. Yes, I can. I think I'll start with, uh, the Betterworks/Hyphen journey. So when I joined, it was called Hyphen. We were an employee engagement, uh, SaaS platform. We had a team of really talented engineers and a very capable, uh, Director of Product, uh, and an inspirational CEO. All the ingredients were there to deliver success. But when I joined the team, they hadn't completed even a single story. Forget about a feature, a complete, uh, you know, product; they hadn't completed, uh, a single story in over two quarters. What I had to do in that case was just prioritize shipping over everything else. Like there were a lot of distractions, right? The team was talking about a lot of things. There was recruitment. There was the team culture, process, et cetera, et cetera. I think the first thing that I did there was after a month of observation, I decided that, okay, sprint one, somebody has to ship some things. And just setting that one finish line that people have to cross, that built up the momentum that was required, uh, and it kept pushing things forward. And I got, uh, hands-on in a way that I wouldn't have got hands-on before. Like usually I would've jumped into the code and started writing code myself. That was my usual approach until then. This time I got hands-on on the product side. Uh, I worked with the, uh, director of the product, uh, to prioritize the stories, to refine acceptance criteria, uh, give a sprint goal and then tell everybody that, okay, this is the goal. This is what is included. This is what is not included. Get it done. And it happened. Uh, so that's how that got started.
Kovid Batra: Perfect. So I think when you're sharing this, this is from your initial phase when you actually start working as an Engineering Manager and working directly with the product, uh, managing the team, uh, getting into that real engineering management role, bridging that gap. What exactly led you or made you understand that priority? Like, you went in, saw a lot of things distracting you, people and culture changes. So, initially when you moved into such a space, which is completely new, right? What exactly made you realize, okay, one thing is of course, they didn't ship anything for, let's say a good amount of time, so you had to prioritize that and you went in with that goal. But if you just focus on one thing, do not take people along, there is a lot of resistance that you get. So when you were deciding to do this, uh, you cannot be ruthless when you are joining in new. So was there any friction? How did you deal with it? How did you bring everyone on the same page? Is there anything specific you would like to share from that part?
C S Sriram: Yeah, yeah. See, the diagnosis was actually pretty straightforward because I had a very supportive CEO at that time. Orno, that was his name. So he was very supportive. When I told him that, okay, I'm going to take a month to just observe. Don't expect any changes from me. Uh, in the first month, uh, I don't want to just start applying changes. He was very supportive of that, and I was given a month to just observe and make my own notes. Once I diagnosed the problem, the application of solution took a bit of time. The first thing was to build culture. Uh, now a lot of people talk a lot of things about, uh, culture. Uh, to me, or what culture means is what are the negotiable and non-negotiable policies within your team? Uh, like what is acceptable? What is not acceptable? Uh, and even in acceptable, what are the gray areas? That there may be some areas where you have a bit of negotiation that is allowed. Uh, so that was the first thing that I wanted to sort out. The way I did that first was, like I said, I spent a month studying the team and then I proposed a set of working rules. I talked about working hours. Uh, that was the time when we were all in office. So presence in, uh, office, the work, how do we do work handoff? How do we make decisions? All of those things. Uh, and these, uh, I presented some of them saying that, see, I am tasked with getting some things done. So these are non-negotiable for me. Uh, like you are doing this, uh, you don't have the space to negotiate and say that you are not going to be in office for two weeks, for example. Or you're not going to say that, uh, I won't write automated tests. Those are my, uh, you know, addition areas. I'm owning them. But you can say that, uh, I will be 10 to 15 minutes late because of Bangalore traffic. So we had that kind of agreement that was made and we had an open discussion about it. That was the first presentation that I made to the team saying that these are our working rules and this is how we'll proceed. And I need explicit agreement from all of you. If anybody is not going to agree, you let me know, we'll negotiate and we'll see where we can get to. Now, once that happened, uh, there was a question of enforcing the policy. And I think this is where I failed in my previous attempt at management. I had a set of policies, but I wasn't very consistent in enforcing them. And this time I had a system where I said that, okay, if someone strayed from a policy, someone said that they'll do something, but they haven't done it, my usual reaction would have been either if I thought it wasn't so important, ignore it. Or if it was important, you know, just go ballistic, go lose your temper and ask questions and, uh, you know, do that boss kind of stuff. This time I took a different approach, which was curiosity over trying to being, uh, you know, trying to be right. So I spent a bit of time to understand why did, you know, this miss happen? Why did this person stray from the agreed policy? Was it because the policy itself wasn't well-defined? Uh, or did they agree to the policy without fully understanding it? Or was it just a, you know, human error that can be corrected? Or is it an attitude issue that I can't tolerate? Now in most cases, what happened is once I started putting these curious questions and I started sharing them, people started aligning themselves automatically because nobody wants to be in that uncomfortable position of having to explain themselves. It's just human nature to, you know, avoid that and correct themselves. So that itself gave me the results most of the time. In a few cases, uh, the policy wasn't well-defined or it wasn't well-understood, in which case I had to refine it and make sure it is explained very clearly. And the last thing was, uh, in a few cases where despite repeated feedback, they couldn't really correct themselves. I had to make the decision saying that, okay, this person is not suited for what I want and I'll have to let them go. And we've made some decisions like that also.
Kovid Batra: I think setting those ground rules becomes very important because when you go out and just explicitly do something, assuming that, okay, this is, uh, this is something that should be followed and people are not aligned on that, that creates more friction than, uh, if they're beforehand aware of what needs to be done, how need, how it needs to be done. So I think stepping into that role and taking up that responsibility, it's a good start to first diagnose, understand what's there, and then setting some ground rules with negotiables and non-negotiables. I think it makes a lot of sense. And when you're sharing those specific details, it all the way more aligns with my thought of how one should go out and take up this responsibility. But Sriram, uh, when you jump into that role there are a lot of things that come into your mind that you need to do as an Engineering Manager. What are those top 3-4 things that you think you need to consistently deliver on? I mean, this could be something very simple, related to how fast your teams are shipping. It could be something related to what's the quality of the work that is coming out. So, anything. But, in your scenario, what were your business priorities? According to that, you as an engineering manager, what were your KPIs or what were those things that you mostly aligned with and tried to deliver consistently?
C S Sriram: Yeah, so two things mattered most. And I think it still matters even today for me. The first is what business value is a team delivering. A lot of people get confused where they say they have high-performing teams when actually the teams are just shipping features very regularly, uh, instead of creating business value, uh, like, that's something that I ask my managers a lot as well. Like, what is the business problem that your team is solving? Not just what is the feature that they are shipping next? So that is the first thing. So, um, having a very clear sprint goal, if you're doing a sprint goal, a quarterly goal that says that this is the business outcome that we are achieving. Maybe you're trying to increase the signups. Maybe you're trying to increase the revenue. You're trying to increase the retention. You're trying to solve a specific problem for a customer. A customer is struggling with a particular business outcome at their end, and that is what your software is solving. And once you set, set that as the priority, then adjusting your scope, adjusting what you want to deliver to meet that outcome becomes very easier, very easy. Like I've seen cases where we thought we will have to deliver like 10 or 15 use cases for a feature, but narrowing it down to five, uh, gave us more results because we've been solving what was most valuable for the customer rather than shipping everything that we thought we have to ship. So that is one of the biggest metrics that I try to use. Like, what final business outcome can I connect this team's output to?
Kovid Batra: Makes sense. Almost every day we deal with this situation when, so when I say 'we,' people who are into those position where they have to take some decisions that would impact the business directly. Of course, a developer also writes code and it impacts the business. But I hope you understand where I'm coming from. Like you are in that position where you're taking decisions and you are managing the team as well. So there is a lot of hustle bustle going on on a day-to-day basis. How did you make space for doing this? Uh, that prioritizing even more, highlighting those five things out of those 15 that needs to be done. What kind of drive you need or what kind of process setting you need for yourself to come to that point? Because I strongly believe I have talked to so many engineering leaders and engineering managers, this one quality has always stood out in all high-performing, uh, engineering leaders and engineering managers. They value the value delivery. Like, anything else comes second. They are so focused on delivering value, which makes sense, but how do you make that space? How do you stay focused on that part?
C S Sriram: Uh, see, I think anybody who makes a transition to management from engineering has a big advantage over there. If you are a good engineer you would have learned to define the problem well before you solve it. Uh, you would have learned to design systems. You would have learned to visualize you know, the problem and the solution before you even implement it. Like, a good engineer is going to draw a high-level and a low-level system diagram before they write the first line of code. They will write tests before they write the first line of code. It is just about transposing that into management. This means that before your team starts working on anything crucial, you spend that focus time, and that's where I think a lot of engineering managers get confused as well. I see a lot of engineering managers talking about, Oh, I'm always in meetings. Uh, I don't know what to do. I'm always running around. Uh, having that focus time for yourself, where you are in deep work, trying to define a problem and to define its solution, that makes a huge difference. And when people try to define a problem, I think it always helps to use some sort of standard frameworks. Like right now, uh, as an engineering leader, most of my problem definitions are strategy definitions. Uh, like what policies you know, should the team pursue for the next one to two quarters? What policies drive things like recruitment, uh, promotion, compensation, management, et cetera, et cetera? Now I try to follow some sort of framework. Like I try to follow a policy diagnosis, risk and actions framework. That is how I define my you know, uh, policies. And for each of those problems that you're trying to define, there are usually standard frameworks that are available so that you don't have to break your head trying to come up with some way of defining them. I think leaning on that sort of structure helps as well.
Kovid Batra: Got it.
C S Sriram: And over time, that structure itself becomes reusable. You will tweak it. You will see that some parts of the structure are useful, some parts are not, and it gets better over time.
Kovid Batra: Makes sense. For an engineering manager, I think these are some really good lessons and coming with specific examples that you have taken, I think it becomes even more valuable. One thing that I want to always understand, how much you prioritize quality over fast shipping or fast shipping over quality?
C S Sriram: Yeah. Uh, okay. So I had, uh, an ex, uh, manager who is my current mentor as well, and he keeps saying that he says that 'slow is smooth and smooth is fast.'
Kovid Batra: Yeah, yeah.
C S Sriram: Okay, so I don't aim for just shipping things fast, but I aim to create systems that enable both speed and quality. I think a lot of engineering managers, they always try to improve immediate speed and that's almost an impossibility. Like you can't fix a pipeline while things are running through it already, uh, you need to step away from the pipeline and you're going to get speed results, you know, speed outcomes. Over time, quality outcomes over time. I think that is the first step towards speed and quality. You need to accept that any improvement will take a little bit of time. Now, once you accept that, then defining these things also, again, makes a huge difference. If it's speed, what is speed for you? Is it just shipping features out or is it creating value faster? The best way of increasing speed I've seen is just measuring team cycle time. Like you don't even have to put in any solutions in place, just measuring and reporting the cycle time to the team automatically starts moving things forward because nobody likes to see that it takes two weeks to move a ticket to 'done' in there. And people start getting curious and they start finding out, okay, I'm not moving that fast. I'm actually working a lot more than at that speed, but I've moved only one ticket in two weeks. That's not acceptable. Then you see things changing over there. Same thing with quality also. I like to define what quality clearly means. Like what is a P0, P1 test case that you cannot afford to miss? What are acceptable non-functional requirements? Like, well, you know, uh, not every team has to build the most performant solution. There may be a team that might say that, okay, a one second latency is acceptable for us. A hundred requests per second throughput is more than sufficient for us. So building with that in mind also makes a huge difference. And once you do that, for quality, I would always say the best thing to do is to shift quality left. The earlier you enforce quality in your process, the better it is. And there are standard techniques to do that. You can use mind maps, you can use the three Amigo calls, automated tests, et cetera, et cetera. One example that I can think of is that when I was working with Hyphen, uh, there were a set of data reporting screens, a set of reports which all had very similar kind of charts, grouping and filters. So I spent time with QA to develop some mind maps where we listed all the use cases for all the reports, that were common to all the reports. And we kind of had these mind maps put up during these print review calls during the QA review calls and all of it. If a developer is going to start development, they have it on their screen before they start developing. The developer develops to match those quality requirements rather than trying to catch up with the quality later on. Uh, and this is another example that I like, uh, analogy that I like using as well. Developers, when they write code, they should write as if they are writing an exam where the answers are already available to you and you should really try to score the highest marks possible. Uh, no need to keep anything secret or anything. I think that's an approach that testers should also adopt. You write the exam with every answer available and you score the maximum marks.
Kovid Batra: Makes sense. So I think in your EM journey, if you have to sum it up for us, when was the point when you felt that, okay, uh, you're doing good and these are the top 2-3 things which you did as an EM that really made you that visible, made you that accomplished in a team that you were ready for the next role?
C S Sriram: Got it. I think it took me about a year at Hyphen. So that would be about six years after I started engineering management. So 1 in 5 years running my own consultancy and then 1 year at Hyphen. the outcome that made me feel that okay, I've done something with engineering management was that we ship the entire product. It was a migration from JavaScript to TypeScript, from an old UI to a new UI, a complete migration of a product that was already in use. We hit $2 million ARR and we got acquired by Betterworks. So those were good, uh, you know, outcomes that I could actually claim as victory for myself and for the team. And that was, uh, what I thought was success at that time. But what really feels like success right now is that engineers from that time call me and tell me that you know, working with me during that time was really good and they are yet to find that kind of culture, that kind of clarity. So that is, you know, that turned out to be a good success.
Kovid Batra: Makes sense. Okay, so now moving from that point of engineering management to a leader, how has your perspective changed? I think the company altogether changed because now you are part of Betterworks, which is a bigger organization. You're working with global teams who are situated across different countries. How your perspective, how your approach to the overall delivery, value delivery has changed, I would like to hear that.
C S Sriram: Yeah. So, Betterworks, I would split it into two halves, two and a half years, two and a half years, uh, you know, at Betterworks, uh, leaving that first year at Hyphen. The first two and a half years I was working towards more of a directorship kind of role where I wanted to own complete execution. That was a time I learned how to manage managers, how to get a few other things done as well, like, uh, tie that, uh, you know, the engineering teams outcome, uh, output to the business outcome. The first principle that I learned through that, uh, and the second two and a half years was really about strategy, about executive management. Now, the first principle that I learned that was your first team changes once you start getting on this journey. Until you're an engineering manager, the team that you manage is your team. You belong to that team. That's kind of the outcome that you always look at. Once you start this journey towards engineering leader, that is not your first team anymore. Your first team is the team that you work with, which is your Co-Directors, Co-VPs, your, you know, immediate boss. That leadership team is the core team. You're creating value for that team. And the team that you manage is a "tool" that you use to get those results. Uh, and I would, you know, put a quotation mark around the "tool" because you still need to be respectful and empathetic towards people. It's not just using them, but that's, that's kind of the mindset that you need to adopt. The side effects of this mindset is that you have to learn to be alone, right? At least when I was an Engineering Manager and all of it, uh, there were these moments when you could gossip and complain about what's happening and all of it, the higher up you go, the lesser, uh, you know, you have space for all of that. Um, uh, you, like, who can you go and complain when you have all the power to, you know, do anything. You have the power to do everything that you want. So you have to learn to be alone and to operate by yourself. So that is the second side effect of that. The next principle that I learned was to give up what you take or built. Luckily, it came on, came easily to me at that point. I'm really thankful for that. Like I had built this whole product and, you know, we completed the migration and we got acquired by Betterworks and all of it was something that I was really proud off. But the moment the first opportunity came, I delegated it to someone else. Now, if I had held on to that product because it was my baby, I wouldn't have had the opportunity to scale Betterworks India. We went from I think around five or six engineers, today we are almost 45+, uh, engineers in India. That sort of a 5x scale, 7x scale would have been very difficult to achieve if I had held on to any of the babies that I was building at that time. So that sort of giving up things, uh, is something that's very important. And the next thing that I learned was to coach engineering managers. You basically have to repeat what you did with your developers. Like with, once you manage developers, you don't develop. You delegate. You try to ask them questions. You nudge them and you guide them. You need to repeat the same process with managers as well. That's another thing that I had to learn. And the last thing that I had to learn was setting up teams for success. This was a big challenge because most of my managers were first-time managers at that time. So the potential for failure was huge. So I had to take my time to make sure I set boundaries within which they can make mistakes, fail, and learn. And that was a balance because I couldn't set boundaries that were so safe that they'll never make a mistake.
Kovid Batra: Yeah, that makes sense.
C S Sriram: And at the same time, I, yeah, yeah.. Because it has to be that space. I think you know that, uh. And at the same time, the boundaries can't be so open that they can, they make mistakes that can turn into disasters. And luckily I had good leaders at Betterworks, uh, who guided me through that. So that worked very well. And I also had to spend a lot of time sharing these success stories and learnings with peers and with leadership. Uh, that was something that I didn't invest a lot of time in as a manager. That sort of story building, narrative building both within the team and outside the team, that was another skill that I had to learn.
Kovid Batra: Perfect. So when you talk about the story building and bringing up those stories to your team, which is the leadership, what exactly would you tell them, can you give some example? Like in, for someone who's listening to you right now, what kind of situations, and how those situations should be portrayed to the leadership team would bring a better visibility of your work as an engineering director to the overall leadership?
C S Sriram: Sure. Yes. I think a classic example would be compensation. So I can go back to that just around the COVID time where suddenly investment was booming. The job market was booming. Every candidate that we were trying to hire had three to four offers. We were not assured of the candidate joining us even after they came on board and people were coaching our engineers left, right, and center as well. So that was a crazy time. Betterworks is a very prudent business. That's something that I'm always thankful for. We don't go and spend money like water just because we've got investment. And this means that now as an Engineering Manager, if I'm going to go and talk about compensation, about business planning and all of it with my leadership team, most of the time, I'm just going to say that, hey, this person is demanding so much. That person is demanding so much. I don't know what to do. That is an Engineering Manager approach, and it is justified because an Engineering Manager, depending on what sort of company and what sort of scale you are in has limited scope on what they can actually do in these cases. But the story that you take as an engineering director is you spend time collecting data from the market to see what is the market compensation rate. You see how many exits have happened in your team. How many of those exits are because of compensation, what percentages have those people been offered outside in the market. You collect all that data. You can't even stop at saying that, okay, I'll put all this data in front of management and I'll tell them that see, we are losing people because we are not able to match requirements. We need to change our, uh, you know, numbers. Even that is not sufficient because that is still a director-level, uh, you know, solution that you can offer. If you want to offer a truly executive-level, you are going to look at costs in the business. You're going to look at optimizations that you can do. You're going to come up with a system saying that this is how compensation can be managed. Again, most of the stories that I tell to my executive team come to the point where it's like, there is a problem there is potential solutions, and usually I even recommend one solution out of the solutions that I'm already suggesting. Uh, and this really helps the leadership team as well, because when I think of my boss or my CEO, they are possibly dealing with 20 things that are more complex than I've ever seen in my life.
Kovid Batra: Right.
C S Sriram: So how can I ensure that A, I get the decision that I think is right. And at the same time, I give them enough information so that they can correct me if my decision is wrong. Uh, both are crucial. You know, one of the scariest things that can happen to me is that I get a decision that I want and the decision turns out to be wrong. So giving myself..
Kovid Batra: That's a balanced approach where you are giving the person an option, an opportunity to at least make your decision even better if it is possible and if you're missing out on something. So that totally makes sense. And putting out things to the leadership in such way and how you're solving them would be really good. But one thing that I could understand from your EM to an EL transition you start becoming more cost and budget kind of things being, start coming in more as compared to an EM position. Is it right?
C S Sriram: 100% yes. That's what I've seen with all the great engineering leaders that I've worked with as well. Yes, they love engineering. They get into, uh, engineering, architecture and development at whatever, all levels of interest and time that they have. But there is always a question of how much value am I getting for the money that I'm spending? And I think that is a question that any manager who wants to become a leader should learn to ask like, uh, I think about two and a half years ago when I was asking my then manager, how do I get into leadership? That was the first thing that he said, "Follow the money. Try to understand how the business works. Try to understand where sales comes from. Try to understand where outflow goes." That made a huge difference.
Kovid Batra: Totally. Makes sense. I think this is something that you realize more when you get into this position. But going back to an EM role also, if you start seeing that picture and you emphasize more on that part, automatically your visibility, the kind of work that you're doing becomes even better. Like you're able to deliver what business is asking. So, totally agree. But one thing always surprises me and I ask this multiple times because everyone has a different approach to this problem, which is now you have a layer of managers who are actually dealing with developers, right? And there are situations you would want to really understand what's exactly going on, how things are quality-wise, speed-wise, and you really don't have that much time that you go out and talk to 45 engineering leaders , engineering managers, engineers, to understand what's exactly going on with them. So, there must be some approach that you are following to have that visibility because you can't just go blind and just say, "Okay, whatever engineering managers are doing, how I'm coaching them would work out wonders." You have to like trust them, but then you have to have a check. You have to understand what exactly is going on. So how do you manage that piece as a director here at Betterworks?
C S Sriram: Yeah, no, that was a very interesting coaching experience for me, where I worked with each of my managers for almost over six months to help them build that discipline. Like any good software engineer will tell you, pulling is never a good idea. If you think of your manager as a software service, you don't want to ask them every half an hour or one hour 'what's the update?' Uh, I like push-based updates. So I help them set up dashboards. So you know, dashboards that talk to them about their team's delivery, their team's quality, uh, their team's motivation and general status and all of it. Uh, and I work with them to design it for their purpose. Uh, I think that was the first thing that I was very clear about. This is not a dashboard that I'm designing so that they can present a story to me, but it's a dashboard that they are using to solve their problems and I'm just peeking in to see what's happening. So that made it very usable. I use those dashboards to inform myself. I ask the questions that I would expect a manager to ask from them. And over time, you know, they got into the habit of asking it themselves because in every 1-on-1 we'd spend 10-15 minutes discussing those numbers. By the time we did it for three to six months, it had become internalized. They knew to look for, you know, signs, they knew to look for challenges. So that became quite natural from there on. And I again want to emphasize on that one part that these were dashboards that were designed to solve their problems. If there was a dashboard or information that I had to design to relay some information or story to a leadership team or to some other team or something like that, that would be something very different. But this is primarily a dashboard that a team uses to run itself. And I was just peeking into that. I was just looking at it to gather some information for myself. So that made a big difference. The second thing that I also did was skip-level 1-on-1s. It took me, I think, almost six months to learn how to do skip-level 1-on-1s, uh, because the two challenges that I faced with skip-level 1-on-1s was it turned out to be another project status update session initially. I was getting the same information from 2-3 places, which was inefficient. It was also a waste of time for the engineers to come and report what they've already done. And the second thing also was, there were a lot of complaints coming in my skip-level 1-on-1s initially as well. And especially more so because many of the engineers that I was doing skip-level 1-on-1s with were engineers who I managed earlier. So I had to slowly cut that relationship and just connect them to their new managers. And I started turning the skip-level 1-on-1s into sessions where I can coach and I can give people some guidance. And I can also use it to get the pulse of the team. Like, is the team generally positive or is the team generally frustrated? And who are the second-level leaders that I need to be aware of? Whose stories I have to carry on? Who I think can become the core of the business after my first-level leaders? So I changed the purpose of the skip-level 1-on-1s and over time that also developed into a good thing.
Kovid Batra: Great. Great. there is a lot that we can go in and talk about this, but we are running out of time. So I will put a pause to this session here, but before we end this session for us, I would love for you to share one of those best learnings that you think as an engineering leader made you an accomplished one, and you think that can drive real growth for someone who is in that position and looking for the next job.
C S Sriram: Got it. Yeah. The one thing that, uh, was a breakthrough learning for me was mentorship and coaching. My then boss, uh, who moved on to another company, I spoke with him and I turned him into a mentor. His name is Chris Lanier. Uh, he's an exceptional executive. I connect with him very regularly to discuss a lot of challenges that I face. It helps me in two ways. The first thing it helps me is I get an outsider's perspective to solve certain problems that, uh, I can't even take to my leaders because those are problems that I am expecting no answers for. So that is the first thing that I get. And the second thing is the more you grow in this career, the bigger the imposter syndrome gets. So that reassurance that someone with the kind of experience and the success that he has, still goes through all of those things; that's quite reassuring. You know, you steady yourself and then you move forward. The next thing that I would also recommend for anybody who is looking at going into this role is to get a coach. A coach is different from a mentor. A coach is going to diagnose challenges that you have and work on specific areas. Like I had two specific challenges, uh, about two years ago. Betterworks was really generous enough to give me a coach at that time. Challenge number one was that my peer-to-peer relationships were terrible. Like, I didn't have a relationship at all. It's not even that, you know, they were poor relationships. There's no relationships at all. Uh, an introvert like me, I didn't see the value of doing it as well. The second thing was public speaking skills. Almost 40% of my speaking was filler words. So I worked on both of those with the help of a coach and got those two addressed and they made a huge difference. So I would highly, and at this level, you can't afford unknown unknowns, like you can afford it at an engineer level. You can afford it at a manager level. If you don't know what you're missing, that can turn into a disaster for both the business and for you at the executive level. So a mentor and a coach are two things that I would highly recommend.
Kovid Batra: Makes sense. And I think I can't agree more on that front because we as humans have this tendency to be in our zones and think that, okay, whatever we are doing is fine and we are doing the right things. But when a third person perspective comes in, it humbles you down, gives you more perspective to look at things and improve way faster than you could have done from your own journey on or your own mistakes that you make. So I totally agree on that. And with that, I think, thanks a lot, Sriram. This was a really good experience.
C S Sriram: Yeah, sorry to, sorry to interrupt you. If you've got a minute, I did pick something to read. You asked at the beginning, something from my writing, do we have a minute for that?
Kovid Batra: Yes, for sure. Please go ahead.
C S Sriram: Cool. Perfect. Okay. This is something that I wrote in 2020. Uh, it's a poem called "No Magic". This is how it goes:
There is no magic in this world.
No magical letter shall arrive
to grant us freedom from the cupboard under the stairs,
and the tyrants who put us there.
No wizard shall scratch our door
with his mischievous staff
and pack us off unwilling on an adventure
that will draw forth our hidden courage.
No peddler shall sell us a flying horse
made of the darkest ebony
to exile us away to mystic lands
and there to find love and friendship.
No letters, no wizards, no winged horses.
In our lives of facts, laws, and immovable rules,
where trees don’t walk, beasts don’t talk,
and we don’t fly.
Except…
when we close our eyes and dream some dreams,
of magic missiles that bring us freedom,
of wily wizards that thrust us into danger,
of soaring speeds that lead us to destiny.
And thence we fly from life to hope and back again.
Birds that fly from the nest to sky and back again.
There is no magic in the world
but in the void of the nests of our mind.
The bird with its hollow bones,
where will it fly, if not in the unreachable sky?
Kovid Batra: Amazing! I mean, I could get like 60% of it, but I could feel what you are trying to say here. And I think it's within us that makes us go far, makes us go everywhere. It's not the magic, but we need to believe the magic that we have in us. So I think, a really inspiring one.
C S Sriram: Thanks. Thank you so much.
Kovid Batra: Great, Sriram, this session was really amazing. We would love to connect with you once again. Talk more about your current role, more into leadership. But for today, I think this is our time. Thank you so much. Thank you for joining.
C S Sriram: Absolutely. Thanks for having me, Kovid. I really enjoyed it.
Implement engineering metrics, gather SDLC insights & set continuous improvement goals in your dev teams.
Try Live Demo
