#143 - How to Think Like a Software Engineering Manager - Akanksha Gupta

[00:01:04] Episode Introduction

Henry Suryawirawan: Hi, everyone. Welcome to the Tech Lead Journal podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening, please subscribe on your podcast app, and social media on LinkedIn, Twitter, and Instagram, and also on YouTube and TikTok for video contents. And to support my work in producing this podcast, you can either buy me a coffee at techleadjournal.dev/tip or become a patron at techleadjournal.dev/patron.

My guest for today’s episode is Akanksha Gupta. She is the author of “Think Like a Software Engineering Manager”. In this episode, Akanksha described the role of an engineering manager and the key traits of being a good engineering manager. She gave advice on how one can transition to the EM role and talked about the difference between engineering management and leadership.

Akanksha then walked us through the three key pillars of engineering management, which are people, process, and projects. Throughout the conversation, we discussed topics, such as delegation, performance management, cross-functional collaboration, and time management. Akasha also shared her practical advice for women in technology who are also interested in becoming an engineering manager, that includes tips based on her own personal journey.

I hope you enjoy listening to this episode and learn various aspects of an engineering manager. If you find it useful, please help share this with your colleagues, your friends and communities, and leave a five-star rating and review on Apple Podcasts and Spotify. It will help me a lot in getting more people discover and listen to this podcast. And I really appreciate it. Let’s go to my conversation with Akanksha after quick words from our sponsor.

[00:03:17] Introduction

Henry Suryawirawan: Hey, everyone. It’s good to be back here again with another new episode of the Tech Lead Journal podcast. Today, I have with me Akanksha Gupta. So today, we’ll be discussing how to think like a software engineering manager. So Akanksha, thank you so much for your time. Looking forward for this conversation.

Akanksha Gupta: Thank you, Henry, for inviting me, and I’m really looking forward for the next set of hour.

[00:03:38] Career Journey

Henry Suryawirawan: Right. So, Akanksha. I always love to ask my guests, inviting you to share more about yourself, maybe any career highlights or turning points that you think are interesting to share for the audience here to learn from you.

Akanksha Gupta: Absolutely. So for me personally, my journey in computer science started when I was a kid at the age of around seven when my dad got a computer for the first time in the house. So obviously as every other child, my first instinct was to use it to, you know, play games and that was the only purpose for me for that computer. Eventually, I took up some computer science courses in my school and I was fortunate enough that they had that opportunity early in the school itself. And that obviously turned my head into using the power of computers.

And my dad always wanted me to be a doctor. But I always dreaded that profession, so hats off to all the doctors out there. And so I decided to pursue computer science as my undergrad course. So it was a fun time, obviously, with more male engineers in the room. It is always a fascinating field.

And then the biggest turning point for me was getting an internship with Microsoft, as part of my third year internship program. And that was the first time when I actually got like some sort of industry experience working with professionals, thinking more other than the academia itself. And I think that was the biggest, you know, launch pad for my career growth. I later on joined Microsoft as a full-time employee. Worked for a few years back in India. That’s where originally I am from.

And then I decided to pursue my Master’s in Computer Science. At that time, obviously I applied to some of the dream colleges in United States and I was fortunate to join Columbia University in the city of New York where I pursued my masters in computer science with specialization in software engineering.

And after that, one after the other, I joined Audible as my first full-time job in United States, then followed by Robinhood. And currently, I’m with Amazon in their AWS organization as a software engineering manager. So, yeah, that’s me in a nutshell.

[00:05:54] Writing the Book

Henry Suryawirawan: Thank you so much for sharing your story. I think it’s really interesting what got you, like so many guests that I have as well. So the first time they got computer, they were always intrigued and that led them into this industry, right? You recently published a book titled “Think Like a Software Engineering Manager”. Maybe looking back, what were the story behind how you came up with this book? Is it something like a collection of learning lessons from your journey or is it something else that brought you into writing the book?

Akanksha Gupta: Yeah, so getting the book out has been one of my most interesting journey, as well as like the proudest achievement I would say so far. So this was basically an idea in my head when I was changing my jobs from Audible to Robinhood. So as a software engineer, every time I was making a job change, there were tons and tons of resources. You have HackerRank, you have LeetCode and whatnot to go ahead, practice questions and, obviously, you know, coding in different languages. As an engineering manager, I found very limited resources. There were like a lot of Harvard Business Review books that I could refer to, but nothing concrete in form of like actually strategizing that job change or, you know, helping me with that career move.

And I did obviously struggle, reached out to, you know, some of the awesome mentors and sponsors I’ve had in my life to help me guide through that process. And all my experiences, you know, my notes really intrigued me with the idea of whatever I struggled with, why not get something out for everybody that can help the community? And that was the main motivation behind getting the book out. Now, obviously this was a thought to begin with.

The next step was to reach out to my friend circle and my network to see if somebody has published a book. And again, being an international student, this is not something that a lot of us think through. And so that again, was another journey and a struggle to actually go ahead, pitch your idea, look out for publishers who would be able to vouch for your book and get you published. So that was another interesting journey going through it. And finally, I was able to decide on one publisher and then go ahead with the book. Yes.

Henry Suryawirawan: I think it’s interesting. It always started like to solve your own problems, right? And I can say, there are limited resources, like you said about engineering management. Many of them actually come in a blog post. There are a few EM books, EM related books. But I think still your kind will be helpful to the industry for people who are new to this role, right.

[00:08:25] Engineering Manager (EM) Role

Henry Suryawirawan: Which bring us to the first question that I’d like to ask from you is what is the definition of engineering manager role? And what is the role and responsibility of engineering manager? And maybe we can start from there.

Akanksha Gupta: Yes. So I think in my opinion, and again, you know, it’s personal opinion, the engineering manager role really, in layman terms, it’s basically you are an engineer and you can also do management. So, you know, engineering manager. Overall, I feel that this role is sometimes undervalued but comprises of a lot of important roles and responsibilities to help you manage a team. So let’s say you are 10 engineers. Obviously each individually provides great output. But there needs to be a single thread that kind of consolidates all of them. Make sure they are on track. Not only that, we need someone with basic career development, helping them guide and do like a crosscheck, “Hey, what’s going well? What could be improved? What are the future opportunities?”

And I think that’s where the engineering manager role really comes into the picture, where they cut across the three pillars of the people, the processes, and, obviously, the projects in the industry. So from the people aspect, as I mentioned, helping people with one-on-one conversations, career development, and all those opportunities. From the processes and making sure that the team and the organization is working well, like a well-oiled machine and as you know, performing to the best of its ability. That is equally important. And obviously the third pillar or the third component, which is the projects, where, you know, we are as a company, we are continuously delivering value to our customers and making sure what we are building is actually used by the end customers.

So that’s how I kind of look at the whole engineering manager role. And you know how it plays against the three pillars.

Henry Suryawirawan: Right. I can see that you group them into these three pillars. The first is like people, and then the project, and then also the process, right? Which can be overwhelming. So I can see so many engineering managers feeling overwhelmed with this role itself. And you can see it touches so many different aspects. And not to mention, probably, also the technical aspects because you mentioned in the beginning, it is like a combination of the engineer plus also management, right? So there could be some technical aspects that are also demanded from this role.

[00:10:48] Transitioning to an EM Role

Henry Suryawirawan: So, for people who are contemplating, maybe they are just software engineers, now they are getting into the senior level and looking into two different paths, which is common in most of the big tech companies. What would be some of the thinking process that if you can advise them to think whether this engineering management role is suitable for them?

Akanksha Gupta: Yep. So this is a great question, just because, being a software engineer myself, I have done that transition to an engineering manager. And a few years back, this was exactly the question that was in my head. So I think, first of all, I would like to suggest to all engineers that any type moving to management, especially engineering management, is not a promotion. I know some of the people think like that, or you know, it is promoted in that way. It’s like a lateral move in all the big tech companies, where obviously you can continue to be an individual contributor and go on in that path or make that lateral move to engineering management. So I think that’s the first piece of caution I would give to everybody who’s contemplating about that.

And I think the next way you should be thinking about is what is that I’m looking out from that role. Is it just the title that impresses me like, hey, you know, I’ll be a manager. What is the motivation behind thinking about engineering management? Now if your answer is that, yes, I love coaching people, people’s growth really motivates me, inspires me. I love to see projects going end to end, then yes, that’s the right role for you. But, as I said, you know, if you’re going behind the title and just the perks that come with it like being able to manage a team, I would definitely ask you to rethink your ideas of whether you want to actually pursue engineering management. So I think that’s the first thing that comes on top of my mind.

Another piece of advice would be that, eventually, you would have to take a step back from coding. I know that sounds sometimes contradictory that, yes, you are an engineering manager, but with the role comes other set of responsibilities. And if you continue to be a full fledged engineer plus manager, obviously, you know, you are moving towards like burnout stage, right? In the end, you have those X number of hours, which are your work hours. Now, I’m not saying that you have to not have that technical acumen, but you need to change your responsibilities, maybe from active coding to reviewing code or more participation in design discussions versus actually implementing the design.

So those are the things, you know, just to keep in mind, and accept them before you are thinking about that transition. And I do cover this whole, you know, individual contributor to an EM transition in detail in my book. So, um, yes.

Henry Suryawirawan: Yeah, it’s always the questions on top of your mind when you are thinking of this transition, right? So like you said in the beginning, it’s not a promotion. And likewise, if you try, but you dislike the role and you wanna go back to the IC, it’s also not a demotion. I think that’s the very, very first important thing that we should think about, right? So this transition is not like one way journey. You can always go back. Doesn’t mean that it’s a promotion or demotion, right? So I think that’s really key.

And you also touched on a good point in my view is that the coding time, right? So many engineers started their career as an engineer. They love coding. They love building things. But as you go into management, more of your responsibilities should change, right? Instead of the hands-on coding, could be something more like a review or maybe just validating, reviewing, and things like that.

[00:14:17] Traits of a Good EM

Henry Suryawirawan: You also touched on a few things that many people would be classifying them as soft skills. In your book, you cover a few traits of how someone could become a good EM, right. So maybe looking from the traits aspect, what are some of the key traits or the soft skills that you think will be really crucial if someone wants to be a good EM?

Akanksha Gupta: Yes. So some of the key traits that I feel, you know, kind of differentiate good EM from not so good EM would be, first of all, the people aspect, right? You really have to care for your people, whether it’s people who are reporting to you, whether it’s your peers or people above you in the leadership chain, so, basically, at all levels. Really helping them with career development. For example, you know, a lot of people ask me, “Hey, how do you structure your one-on-ones?” So one-on-ones are for the people. It’s not about asking for project updates, or looking at, “Hey, did you, you know, finish that task, right?” It’s really the engineers time to help coach and guide a roadmap for their career. So caring for people is the first thing.

Second, I see an EM as more of a visionary. Someone who’s there to kinda look at the overall organization strategy, their mission statement, and condense it to what it translates to at the team level or the organization level that they are managing. So really making sure that the company’s OKRs are translated to a team level OKR (Objective, Key and Results). That’s how they should be able to give that vision to the team and make them understand, if you are a team, why you are a team. You know, we all are in this together.

And overall, you know, you need to be an effective communicator. You should be able to communicate and comprehend the ideas and share it with the broader team. And, obviously, it’s not a one-way communication, like keeping that door open where you are approachable by your team members and they can knock on the door anytime and be like, hey, this is, you know, this is where we need your help. Or this is a roadblocker where you can help.

So those are the things to definitely keep in mind. I think these are like the top traits and, obviously, keeping like the EQ factor, as it is said, emotional intelligence and the empathy. I think that is equally important.

And the last thing I would say is leading your team by example. So a lot of times you need to make sure that what you’re asking your team members is something you would do. You’re not having unrealistic expectations from your team members. So leading through example, I feel, you know, is very important.

Sharing my own one personal example. There was a time when in the next quarter my team was tasked to work on a new set of AWS services. And at that time, our team was not very well versed with the AWS set of technology. So what I made sure is that since we had a heads up on what’s coming in the next quarter, I dived into, you know, understanding the AWS certifications. Played a little bit, hands-on with the AWS suite itself. Got myself certified and then obviously I had the story to share. And next, you know, I went into the one-on-ones, shared it with my team, was able to also share my resources and get them ready for what was coming in. So this was like an example where I didn’t go and expect the team to like, hey, go get yourself AWS certified. It was more of like, if I could do it as an EM, then let’s together get into this journey and take it to the finish line.

Henry Suryawirawan: Wow. Thanks for sharing that personal story. So if I can summarize the few key traits that you mentioned just now. The first is the people aspect, right? You really need to care and you really need to kind of like, like working with people, right? It’s not like super like, but you have to deal with people, and hence you need to be able to be comfortable working with people, right? And then the second thing is about visionary, right? Trying to translate company’s OKRs into the team OKRs, making sure things get improved and delivering value and communicator. And I like also the EQ part, the emotional aspect. So sometimes you’re frustrated, but you cannot show that to all the people in the team, right. Not to make everyone frustrated as well, and also the empathy part. Some people may have their own personal challenges and you need to exercise that empathy to help them instead of making them worse.

[00:18:31] Engineering Manager vs Engineering Leader

Henry Suryawirawan: And I think the last one, always leading by example. As a manager, I think you are not the boss all the time, right? You also need to lead by, maybe, working with the people, showing by example. Which kind of like brings me to the next question. Some people think, or confuse the term engineering manager and engineering leaders, right. Is there any kind of a distinction in your view, and if there’s any, what is the distinction here?

Akanksha Gupta: Yes, that’s a great question, you know, something that even I have got confused in my life early on in the career. So I would say that leadership is more of a mindset or an approach, while management is more of like a title or a position that you hold. So what I mean by that is that as an engineering leader, you are kind of there to inspire your team, coach your team. You are more setting the culture for the organization and the company as a whole. While the way I look at management is more of the executional aspect of it, which can be obviously doing the admin task, making sure the projects reach their delivery time, and so forth.

So, I know that these two terms, engineering manager and engineering leader, are kind of used interchangeably. But it is important to understand the key difference that management is more of like a role and position, while leadership is a mindset. And what is the key is all of us to be like great engineering leaders and do you really help move the needle and, you know, get towards the success.

[00:20:01] Boss Mindset

Henry Suryawirawan: So if I understand what you just now mentioned is that, yes, there is a difference, right? The leadership is all about mindset. The management part is basically getting things done, is the critical aspect to it. And I think one key challenge that I see some people think is like, manager here is become the boss like I said in the beginning, right? And they always have to decide many, many things. Do you have some tips for people who think like that or trying to be the go-to person, always deciding about things, right? Always making decisions. Is that a good indicator of a good engineering manager?

Akanksha Gupta: Great question, Henry. So I don’t think so, and especially, you know, it kind of boils down to the earlier idea that moving to engineering management is not a promotion. So that person can be someone who’s an engineering manager, but maybe from the company’s leveling guidelines is at the same level as you. So they are not your boss, but the way I would think is thinking the EM role is more of a facilitator and a career coach. So they are there for you in terms of helping you succeed in your career. At the same time, looking into the team’s execution, but not necessarily someone who’s a boss. Now, at the same time, I would not say, it can be a completely informal friend relationship because obviously in the end you need to take things seriously both ways.

And that’s another interesting topic I touch in the book, that you cannot be completely informal or be fully friends, you know, as a software engineer, be fully friends with your engineering manager. But it’s more of like a partnership that needs to be done together. And EM is more of a facilitator in terms of communication with the cross-functional partners and the overall execution of the team.

Henry Suryawirawan: I like the term facilitator that you bring up here, so I think that’s really crucial, right? So you are not there to always make decisions, sometimes you facilitate. Yes, sometimes you make tough decisions. Sometimes you also care about people. And I think it’s really, really key.

[00:21:56] Advice for Women to Become EMs

Henry Suryawirawan: Speaking about the industry these days, you mentioned in the beginning, right, so it is a male dominated career. So any kind of interesting insights from your own journey to become an engineering manager for female, right? So for those women in tech, is there anything that you wanna give to them? Maybe some kind of advice for them to, yeah, to think about?

Akanksha Gupta: Right. Definitely, you know, being a woman of color, and obviously coming from India, this is an industry that is currently male dominated. But one thing I can tell you is that, with the evolving world, there are so many, you know, different programs, even within the companies and outside that are really helping get more and more women into the industry. So just thinking from the internal company perspective, I’ve seen multiple mentorship programs where you can get mentors or sponsors to help you in your journey if you would like to get into a leadership role.

Outside the company, there are several platforms that one can look at. Some of the platforms where I myself am a mentor are things like, Plato HQ, Growth Mentor, First Round Fast Track, which accepts applications and one can apply and you can mention what sort of a mentor are you looking for. So there is a fact that it’s a male dominated industry, but at the same time, there are a lot of resources where you can break that bar and actually succeed.

Another thing I would say is that we need to, as women, we need to build a community, right? Get together, like basically hand in hand we can actually really change the whole industry landscape. So really find mentors or sponsors who have done that journey and they can help you guide how they navigated through those challenges. It’s not just the professional challenges, but at the same time, balancing a family, your own personal goals and career aspirations. So kind of, you know, I always look at female leaders and how they have gone through that journey. I try to connect with them either through LinkedIn or through these different mentorship platforms.

So that would be my one tip. Dream big and don’t let the whole idea that this is a male dominated society to stop you from achieving what you really want to achieve.

Henry Suryawirawan: I think that’s a really beautiful message, right? For those women who are thinking about doing the career of engineering management. So I think it is possible, definitely, even though you think it’s a male dominated thing, I can also see in the industry there are so many female in the engineering leadership roles. So don’t hesitate, right? Build communities, find mentors, like Akanksha mentioned just now, and learn from them, right? So I think it’s definitely possible.

[00:24:30] Delegation - Learn to Let Go

Henry Suryawirawan: So let’s go to the three key pillars that you mentioned in your book. Again, People, Project and Process. So let’s start with the People aspect. We won’t be covering all of the People things, but I think there are two things that I want to cover in this conversation. The first one is about delegation. Why it is important for me to ask this question is because many of these first time transition kind of engineer, the first challenge is always to delegate, especially about coding, right? Because you always think that, okay, I can do it better myself. So maybe tell us more about the key of delegation, especially learning to let go.

Akanksha Gupta: Yes. Yeah. Delegation is one of the key skillset you have to learn as you move to any of the leadership roles, especially engineering management. So I think first and foremost, I would say delegation is not about just assigning or allocating the task to someone. A lot of people, you know, kind of confuse it with that, that let’s say I’m supposed to do task A, I can just ask a person B to go and perform that task. No, delegation is not that. Delegation in my head is a journey that you do together with the person that is the delegatee or you know, whoever has been assigned that task. And if you are the delegator, you need to make sure that the task is clearly communicated in terms of what is expected and what is the outcome that you’re looking for.

At the same time, as I say, it’s a partnership. You have to provide them the right resources and the training material to put them up for success. Because in the end, you are equally responsible for the outcome. It’s not that once delegated the outcome is no more related to you. So that’s where it’s a key distinction between just allocating a task versus actually delegating a task. And a lot of times, Henry, the term comes, right, like, hey, you know, effective delegation. And that is what we are aiming for.

So yeah, so that’s what I would say. And the biggest thing is to think about delegation as more of a coaching mindset instead of the doer mentality that most of the fresh engineers have, where as you mentioned like, hey, I can do this code faster and so why not, you know, just do it myself. So it’s not the idea about looking at that immediate task in hand, it’s about teaching that to others. That way you can have like more of a multiplier effect for future.

Henry Suryawirawan: So yeah, I think that’s a very, very important things that you mentioned just now, right? I like the way that you mentioned, it’s not just assigning tasks, right? Delegating it’s not just about, okay, I give you this task and please report back when you have done or finish your work. So I think it’s more about setting the expectations. That’s the first thing, I think the outcomes, right? Not necessarily the how, so the people can figure out the how. Maybe they can do it better, maybe they can do it in a more creative way. But if you set the expectation and the outcome, right, I think that’s really, really crucial for the effective delegation. And I think, yeah, you mentioned a very good important point that as a leader you are still accountable. You are not delegating that responsibility of the outcome to the person itself as well. So I think I really love that.

[00:27:33] Managing Performance

Henry Suryawirawan: So the other aspect of people that I wanna discuss is about managing performance. Again, for first time manager, sometimes they are not expecting to do this, especially if they come from like the same team. The people that they lead are previously friends or peers, and now they have to manage people’s performance. So maybe if you can touch on a little bit of important points about managing performance, especially for high performers and low performers and things like that.

Akanksha Gupta: Yes. And I think managing performance is a very critical role as an engineering manager, and it really touches upon the whole people aspect that you are responsible for. So the way I would say is that managing performance, the biggest toolset you have in your hand is the one-on-one conversations that you have with your team members. So use those conversations to the fullest where your motivation as an EM should be to figure out what are their strengths, and I won’t say weaknesses, but more of like opportunities for growth and the aspirations they have in their career.

Once you have that foundational knowledge, you can work with them to set up actionable goals. I usually use the SMART criteria, which stands for Specific, Measurable, Actionable, Relevant, and Time-bound tasks. So using that SMART framework to set up goals with your team members. And obviously doing checkpoints to have like a constructive feedback mechanism. And that’s most of the companies as we’ve heard, you know, like performance reviews or midyear check-in, to kind of help and make sure everybody is on the right track. And there’s like a bidirectional communication between both parties. So that’s the key where using the power of one-on-ones is really, really crucial as an EM.

The other point in terms of how do I identify whether it’s a high performer or a low performer, I think the main art here is to actually identify, you know, whether a particular performer is a high performer or a low performer. And this is definitely a grey area and can be sometimes subjective, and that is what we have to caution against. Now the biggest thing that we can use in this is the company’s leveling guides, which is what is a standard that is followed across your company. So that way there’s no bias or favoritism happening in a particular organization versus a different organization within the same company.

And for those who don’t know what exactly is a company leveling guide, it could be more of like the competencies in a particular job role that are essential or that kind of differentiate software developer one versus a senior software developer two. So something on those lines where it can be as simple as these are the technical competencies, you know, dealing with ambiguity and having more experience with designs, technical designs. Such a matrix can really help you understand where you are actually in that job role level and what is the gap that, you know, needs to be addressed for you to move to the next level. And that can really help differentiate whether someone is a high performer versus a low performer.

And, obviously, once you identified that, then there are different strategies to handle high performer for which, you know, you would like to keep them challenged, because they’re always craving for newer tasks and ambiguous tasks, I would say. So providing them those opportunities, and that is something you need for high performers. And at the same time, for low performers or under performers, we really need to provide them the training resources to help them address that gap. Figure out what’s the blocker. Is it some personal reasons that is keeping away from performing to the full potential? Or something at the work, which obviously is in your hand and something you can change? So really acknowledging and identifying those and then working towards a roadmap to kind of address those gaps is the key.

Henry Suryawirawan: Right. I really like the portion where you mentioned remove the bias, especially when you rate people’s performance, right? So if you have leveling guide in your organization, please use that. Don’t use your subjective opinions. Or maybe you have a better relationship. Sometimes it works like that, right? So you have some favorites in your team, right? You always go to this person. But try not to do that because it can create a very bad vibe within the team, right? And try to use the leveling guide. If you don’t have leveling guide in your organization, I think it’s important to maybe ask the question and try to raise the importance of having this leveling guide within the organization.

Akanksha Gupta: Yeah, absolutely. Like having a leveling guide, and you know, I know some of the small startups which do not have one. If you are a new EM in that company, it’s a great opportunity for you to shine by helping set up something for your company. And another key point, you know, I would just call out here is the whole concept of adjusted expectations, which I feel that is not something that is very well or openly talked about.

Obviously, as an EM, you’re setting these expectations with your engineers. You’re following the leveling guide, but at the same time, you can’t expect someone who, let’s say just had a baby, missing for four months on maternity leave to end of the year, have the same set of outcome or output as somebody who was here for the 12 months. So, you know, just a nuance that we don’t openly talk about it, and only some of the companies acknowledge this concept. But if you are setting up something for your company, definitely keep these adjusted expectations in mind. In the end, we are all human and you know, the whole idea of having that empathy is really important.

Henry Suryawirawan: Thanks for the plug. So I think this is a good concept, right? Adjusted expectation. Don’t treat everyone the same, especially if they have breaks in between, maybe because of maternity or paternity, right? Or maybe because of sick leave or something like that. So, try to adjust the expectations as well.

[00:33:27] Cross-Functional Collaboration

Henry Suryawirawan: So let’s move on to the next pillar, which is the Project. So one thing that I wanna discuss here is about cross-functional kind of a collaboration, because most of the times when you work in software engineering teams, It’s not often that you will work just by your own team, right, within your own team. So you always have to collaborate and cooperate with other teams. I found one important quote that I think you took it from HBR, right? It’s like, there’s a statistic saying that 75% of cross-functional teams are dysfunctional. Knowing about this fact, what would be some of your tips or insights for engineering managers here to think about when they collaborate cross-functionally?

Akanksha Gupta: Yes. great point, Henry. And, you know, something that I have faced myself working as being part of different organizations. When it comes to collaborating with the cross-functional partners, of course you need to acknowledge what is important for them, right? Sometimes, we forget that if we were in their shoes, how would we react? So that is really important to understand where is the other person coming from. Now, whether you’re talking to your project manager or whether you’re talking to your technical program manager. So effective communication and coordination is the key here, where you need to be very clear with what are your goals. Obviously, when I say your, it’s like your team’s goals, and you know, what is the expectation there.

A lot of times, you will face competing priorities in any organization where roadmap for your team might not be in sync with the roadmap of the other team. And that’s where the power of negotiations come into picture. Where obviously you go ahead, you negotiate, you figure out if, you know, maybe sending your engineer on a loan to another team could help them with their roadmap. And at the same time helps you move the needle in your own roadmap. So being open to those negotiations and having that candid conversation kind of really helps.

Another thing is to be really really transparent about what is expected. Don’t assume things. It’s always good to have that discussion and clear out any ambiguous thoughts that one might have. I read about this concept called a Nemawashi. As far as I remember, it’s like a Japanese term that kind of talks about that as you work with cross-functional partners, sometimes it is important to set the foundation of what is expected. So maybe individually talking to the different stakeholders and ensuring that we are all on the same page in terms of, these are the resources we have, these are the time constraints, and this is the outcome that we are looking for. So I really found that concept interesting. And just mentioning for those who want to read about it. But yeah, I think that’s the key in terms of working with cross-functional partners is to acknowledge the competing priorities, be open to negotiations, and being, you know, an effective communicator and collaborator.

Henry Suryawirawan: Right. I haven’t heard about this term Nemawashi, so I’ll make sure to put in the show notes, so maybe I will learn myself as well and for people to learn more about this concept. And I think it’s very important. Yeah, you mentioned a few challenges that I can see, right? Roadmaps not in sync because they’re two different teams and sometimes, you know, either the priorities are not in sync or just the timeline is not sync, right?

Because work in parallel, you always have these kind of challenges. And sometimes, you also have crunch time, right, where you are busy delivering something, but hey, somebody just comes asking you to help them do something. And it’s always clear to make it transparent, like you want to help them. But sometimes, there are issues that you couldn’t, for example, prioritize their ask versus what you have to deliver, right?

And I think the last point that I wanna touch, which you mentioned in the beginning about the People aspect, is the empathy, the emotional aspect. So expect that there will be tough negotiations, people pushing you about stuffs, right? And always keep that in a positive manner, I would say, rather than make it like a tension. So I think that’s really, really important.

[00:37:20] Setting Up Processes

Henry Suryawirawan: So let’s move on to the next pillar, which is about the Process. I think here, what is the most important thing I wanna ask is how can an engineering manager set up a good process within their team. Especially knowing that there are so many best practices, there are so many things, right? Maybe unique within the team themselves. Is there any kind of, I don’t know, like a best recipe of how they should set up a process within their team?

Akanksha Gupta: Yes. I think the best recipe is, first of all, to understand what’s the problem in the team, right? You cannot find a solution until you, you know, identify what is it that’s going wrong. So I think, first and foremost, it’s important to understand where the gap is. And once you identify that, I’m a big believer in getting your team together. So more of like a democratic leadership style where you get everybody in the team together, have those open brainstorming sessions in terms of, hey, this is how we’ve been working so far, this is the output. What are the ways we can try. And mind you that nothing is a one way door. You can always pilot few things within the team and try them out and see what works and what doesn’t work.

At one point in my team, we used to have a lot of code reviews that would stay in pending for quite long. So I got the team together in one of the standup, we brought up this whole problem statement and we decided that, maybe, what we can do is as part of standup, call out like, hey, I have this code review pending, and any volunteers for it. So in that way, you’re not sitting open-ended. Let’s say you need a ship-it or a acceptance from two people. You’re not sitting in ambiguity. Who are the two people looking at it? Within the standup itself, two volunteers have stepped up, or maybe, you know, have been forced volunteer to kind of look into those code reviews. And that way there is more targeted thing in terms of, you know, what’s gonna happen. Eventually, the team learned it and no more. We had to kind of do it. This wasn’t a big process as such, but something that really helped us set a good habit of making sure we are on top of our code review.

So I would say starting with identifying the problem, getting the people together to solve the problem because that way they feel they are more heard and are part of the process. And then, obviously, evaluating if it worked or not. And you can always, you know, iterate back and brainstorm again to step two.

Henry Suryawirawan: Yeah, it’s always important to include the people to come up with the solutions, right? Find the problems together and also come up with the solutions together, right? Again, the manager here doesn’t mean the only person who can come up with solutions and try to improve the process, right? Everyone should be responsible to improve the process within the team.

[00:40:00] Managing Up

Henry Suryawirawan: So one part of the process that I always find interesting, because many times, engineering manager have to report to their leaders, right? So it could be CTO, could be VP of Engineers, and so on and so forth. So what will be some of the good things about the process aspect that you think will be good for them to report back to the top leaders, top management?

Akanksha Gupta: Yes. Obviously, you know, what have to be reported kind of depends, right, whether it’s like some sort of team metrics versus visibility into the progress of a project. But I think the key tenets here is to maintain that level of transparency with the leadership in terms of what’s happening. And even if there’s a risk or a blocker, call that out early so that you can get help on it in a timely manner. And, whether it’s like you need more resources or a change in the strategy. So I think transparency is the biggest.

When it comes to transparency, the idea is to make sure you have the right reporting in place or some dashboards. You cannot go and dump a lot of technical knowledge to the leadership team. Now, I’m not saying that our leaders are not technically sound. It’s just that they are into way too many things, so we need to be cognizant of their time. And so, keeping it at a high level and if they want to drill down further, they can always do that. But keeping a high level reports that kind of give them a 360 degree purview of what’s happening, what’s working well, and where are the blockers. I think that would really help them to not just gain the visibility, but also help your team if you need any support from the leadership. So yes, transparency, I would think is the biggest. And you know, how you bring that transparency is the key.

Henry Suryawirawan: Right. Thanks for including that transparency aspect. Again, I think it’s very important, right? Set the expectations right, knowing what the leaders want as well, and try to deliver the reports and all the dashboards that you think best will give them the information. And raise the risk early. It’s always a very, very important right? Don’t raise late when it’s close to beginning a disaster or an incident, right? So try to raise it earlier if you can.

[00:42:02] Time Management

Henry Suryawirawan: So another part about process that I think many, maybe, first time manager also struggle a lot is about time management. And especially, if they started from engineer role, where most of the day they are just coding, right? Spending time alone and doing a lot of productive work, focus time. But now in management role, they need to do a lot of meetings, a lot of communication, maybe writing stuff. What is the key for effective time management? I think this is also something that many people want to learn.

Akanksha Gupta: Yes. And I think time management is such a puzzle that I would not say that even after, working for these years, I have still mastered that, so I’m still learning. But what I can share are the few things that I have been trying to do to manage my time effectively.

First and foremost is like decluttering my calendar. Being an EM, I get tons and tons of meeting invites. So it is really important for me to segregate, see if it’s more of like a physical presence that this meeting has versus more of like how can I actually contribute if I have to attend that meeting. And if it’s of no use, then like politely responding to the email and keeping the calendar neat and clean, I would say.

And as a EM, you do need time to do your tasks right. A lot of times what I have found is I would start with, you know, a to-do list. Over the day I attend meetings and my to-do list just increases. And the day just gets over and I’ve not actually done work. So it’s important to block some focus work hours for yourself during the week. I usually do like two hour blocks whenever possible and, you know, obviously try to reject meetings if they fall into that. So, yeah, keeping time for yourself to actually do work is really important.

Another practice that I have tried to follow in my teams is the meeting bill of rights where, don’t entertain a meeting, which is just like sync up or project status, right? Really someone who is sending out an invite should give you some sort of agenda in terms of, you know, what is expected out of that meeting? What’s the input that we are going with and what is the expected outcome? And that also ties well to the first point, which is for you to take an informed decision whether you are actually needed in that meeting or not. So following this habit really helped also remove some of the duplicate meetings that we had, where we found out that while we were setting the agenda, you know, it’s kind of the same thing that we are repeating with a different set of audience. So that’s one.

And another nugget that I will throw out is the Pomodoro technique, if people have heard about it. Basically, you know, in simple terms it just says you work for X, X minutes and then you kind of take break, recharge, and then work again. So a subset of that, what I have followed in my teams is instead of setting a 30 minute meeting, send a 25 minute meeting invite so that people always have a five minute breather to catch, to take a restroom break, grab some water or like just, you know, even stretch at their seat. So that’s another concept that can really help you manage your time and at least feel better physically and from that health perspective as well.

So I think that these are the key nuggets. But at the same time, you know this, I do acknowledge that there is no silver bullet solution to time management as an EM. Keep a priority list and always make sure. And yeah, you know, we discussed about delegation. Use the power of delegation wherever possible where someone from your team is better suited to go attend a meeting. You can always, you know, do that.

Henry Suryawirawan: Yeah, the key is always prioritization, right? Sometimes also saying no, so if you’re invited to multiple meetings, sometimes you are asked to help, right? Sometimes you have to maybe assess yourself, whether you have the capacity or maybe you have some people to delegate to, right? If not, then maybe you can politely say no.

[00:45:50] A Growing Todo List

Henry Suryawirawan: I was intrigued when you mentioned in the beginning when you described about this time management is that you have a to-do list that is growing and ever growing, right? It can never finish. So what would be your personal tips how to handle that, because it cannot continue on and on, right?

Akanksha Gupta: For sure. So I think, yeah, like as you mentioned, you know, the priority. Obviously, every day, the priority might change. So keeping that to-do list in a priority manner could really help. And if there is something that needs immediate attention, so obviously you look into that and then use delegation to move some of the tasks which others can do. And at the same time, you know, we need to keep a mindset that those are also growth opportunities for others. It’s not like you are just moving things out of your plate to others. You are actually providing those growth opportunities to other members in your team. So, you know, it’s a win-win situation both ends. Keeping those things in mind can really help you effectively manage your to-do list.

But yeah, I will be very candid that there have been times where, you know, on a Friday, I would log in two hours earlier just to get through that to-do list. So yeah, I’m still learning. And if you or others who are listening to us have some tips, would love to hear their tips as well, how they manage time.

Henry Suryawirawan: Right. I think this is a topic that is always an evergreen, right? So I think nobody can find a perfect solution. And I think it’s also contextual, right? Different people have different preference. Sometimes you have a productivity technique that work for one person, may not work for the others. So I think my key tips will be find something that works for you, right? There are so many productivity techniques and tips out there. Find something that resonate with you and that’s really, really worked well for you.

[00:47:28] 3 Tech Lead Wisdom

Henry Suryawirawan: So I think we cover a lot, right? From the basics of an EM and the three key pillars. And as we wrap up the conversation, I have one last question that I want to ask you, especially related to this engineering management discussion that we just had. So my question is called the three technical leadership wisdom. You can think of it just like an advice, maybe from your experience, your expertise, right? So what will be the three key wisdom that you wanna share with all of us here?

Akanksha Gupta: Sure. So I think the first would be dream big. I feel that that is really important, right? We get into this rat race sometimes, and it’s more of like what others are doing. And we try to mimic that. It is really important to understand where do we, you know, a lot of people ask that in interview question, where do you want to see yourself in five years? You should be the one defining that. And it’s okay to dream big. You might not get 100% of it, but at least you will have a high level framework or a roadmap to kind of try towards it. So I think that would be my first advice.

My second would be find a mentor or a sponsor. Now, I know a lot of people shy away from this thing. At least, in my personal life, I feel like having the mentors has really helped me all the way, when I was a freshman all the way, even now I have mentors within the organization and outside organization to kind of help guide me in my career, suggest me resources that can help upskill me. So having that mentor is really important. So I think that would be my second piece of advice.

And my third piece of advice would be, don’t shy away from this whole concept of delegation. I feel it’s really, really important. You know, as you grow in your career, you really want to scale yourself and your teams. So getting that art earlier in your hand and honing that can really help you to scale well.

Henry Suryawirawan: I think spoken just like a true EM, right. Delegate well, delegate effectively. But don’t forget to dream big as well, right. I think sometimes we shy away from trying to achieve what we always dream about. But I think the key thing is maybe setting a direction where you want to go and try to achieve that milestone over milestone. It doesn’t have to come all in one day, right. So I think thanks for sharing that piece of wisdom.

So, Akanksha, thank you so much for this discussion. If people love the conversation and want to reach out and ask you about stuff, about engineering management maybe, is there a place where they can find you online?

Akanksha Gupta: Absolutely. So I am an active LinkedIn user. So I can share my LinkedIn profile and people can reach out to me through LinkedIn.

Henry Suryawirawan: Thanks for that. I will put that in the show notes as well. So thank you so much, Akanksha, for your sharing today. So I really learned a lot about engineering management as well, so thank you for that.

Akanksha Gupta: Yep. Thank you so much, Henry, for having me. This was really insightful. And, you know, I love our super candid discussion. And all the best to everyone listening out. And, yeah.

– End –