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 there. 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.
Hey everyone, my name is Henry Surya Virawan and you're listening to the Technically Juno Podcast, the show where I'll be bringing you the greatest technical leaders, practitioners, and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our journal. Hi everyone.
Welcome to The Technical Journal Podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great tall 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 techlijuna dot deaf slash tip or become a patron at techlijuna dot deaf slash patron. My guest for today's episode is Akansha Gupta. She is the author of Think Like a Software Engineering Manager. In this episode, Akansha 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 talk about the difference between engineering management and leadership. Hakansha then walk 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. Hakansha 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 5 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 Akansha after quick words from our sponsor. Are you looking for a new cool swag? Techlejuno now offers you some swags that you can purchase online. These swags are printed on demand based on your preference and will be delivered safely to you all over the world.
Where shipping is available, check out all the cool swags available by visiting Techlejuno dot dev shop. And don't forget to brag yourself once you receive any of those swags. Hey, everyone, it's good to be back here again with another new episode of the Technical Journal Podcast. Today I have with me Akansha Gupta. So today we'll be discussing how to think like a software engineering manager. So Akansha, thank you so much for your time. Looking forward for this conversation.
Thank you Henry for inviting me and I'm really looking forward for the next set of our. Right. So 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? Absolutely. So for me personally, my journey in computer science started when I was a kid, at the age of around 7:00 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 and 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, Launchpad 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 Masters 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 the United States, then followed by Robin Hood. And currently I'm with Amazon in their AWS organization as a Software Engineering Manager. So yeah, that's me in a
nutshell. 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 are always intrigued and that let 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 come 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? 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 Robin Hood. So as a software engineer, every time I was making a job change, there were tons and tons of
resources. You have hacker rank, you have lead code 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. I think it's interesting. It always started 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 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? 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? Maybe we can start from there.
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, makes sure they are on track. Not only that, we need someone with basic career development helping them guide and do like a cross check, 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 is you know performing to the best of its ability.
That is equally important. And obviously the third pillar or the 3rd 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. Right. I can see that you group them into these three pillars.
The 1st 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.
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 parts 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? Yep. So this is a great question just because being a software engineer myself I have done that transition to an engineering manager and 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 the engineers that any type moving to management, special 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 just to keep in mind and accept them before you're thinking about the transition. And I do cover this whole individual contributor to an EM transition in detail in my book. So yes.
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 want to go back to the IC, it's also not a demotion. Think that's a very, very first important thing that we should think about, right. So these transitions is not like one way journey you can always go back, doesn't mean that it's a promotion or the emotion, right.
So I think that's really key. And you also touch on a good point in my view is that the coding time, right, so many engineers started their career as an engineer, their 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. You also touch 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, 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 change. So basically at all levels really helping them, the 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 engineer's time to help coach and guide a road map 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 kind of 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 Okr's 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 to 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 stars 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-one, 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. Well, 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 companies or chaos into the team or chaos, making sure things get improved and. To bring value and communicator and I like also the EQ part, the emotional aspect. So sometimes you are frustrated, but you cannot show that to all the people in the team, right? Not to make everyone is 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.
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?
Yes, that's a great question, 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 tasks, making sure the projects reach the 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 in 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? So if I understand what you just now mentioned is that yes, there is 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? 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? 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 phase. 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 AM is more of a facilitator in terms of communication with the cross functional partners and the overall execution of the team. 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 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 want to give to them? Maybe some kind of advice for them to have to think about? Right, definitely.
You know, being a women 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 and 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 kinda 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 1 tip to dream big and don't let the whole idea of that this is a male dominated society to stop you from achieving what you really want to achieve. 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 Akansha mentioned just now and learn from them, right. So I think it's definitely possible. 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, OK, I can do it better myself. So maybe tell us more about the key of delegation, especially learning to let go. Yes, yeah. Delegation is one of the key skill set you have to learn as you move to any of the leadership roles and 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 tasky. 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 delegating 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, 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 there.
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. 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, OK, 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 things 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. So the other aspect of people that I want to discuss is about
managing performance. Again, for first time manager, sometimes they are not expecting to do this, especially if they come from 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. 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're responsible for. So the way I would say is that managing performance, the biggest tools that 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 mid year 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 we're using. The power of 1 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 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 gradient 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 or 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, 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 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 identify that then there are different strategies to handle high performer for which you know you would like to keep them challenged because they are 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 underperformers, 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 road map to kind of address those gaps is the key, 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 wave rates 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. 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. Really, 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. 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. So let's move on to the next pillar which is the project.
So one thing that I want to 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 or what would be some of your tips or insights for engineering managers here to think about when they collaborate cross functionally? 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 road map and at the same time helps you move the needle in your own road map.
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 Anima Washi. 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're
looking for. So I really found that concept interesting and I 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. Right. I haven't heard about this term animal washi, 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? The road map's not In Sync because they are 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 want to touch, which you mentioned in the beginning about the people aspect is the empathy of the emotional aspect. So expect that there will be tough negotiations, people pushing you about stars, 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. So let's move on to the next pillar, which is about the process.
I think here what is the most important thing I want to 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? 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 oneway 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 stand up. We brought up this whole problem statement and we decided that maybe what we can do is as part of stand up 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 stand up itself 2 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 going to 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 reviews. 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 2. 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.
So one part of the process that I always find interesting because many times engineering manager have to report to their leaders, right? So 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?
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. 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 risk late when it's close to being a disaster or an incident, right. So try to raise it earlier if
you can. 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, focused 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, 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 EMI 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 e-mail 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. And what I have found is I would start with you know, To Do List
over the day. I attend meetings and my school list just increases and the day just gets over and have not actually done work. So it's important to block some focus work hours for yourself during the week. I usually do like 2 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 XX 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 5 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 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. 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. I was intrigued when you mentioned in the beginning when you describe 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 will be your personal tips how to handle that? Because it cannot continue on and on, right for sure. So I think I'll 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. 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's so many productivity techniques and tips out there. Find something that resonate with you and that's really, really work well for you. 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 want to share with all of us here? 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 its 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 OK to dream big. You might not get 100% of it, but at least you will have a high level framework or a road map 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 kinda 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. 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. 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. She doesn't have to come all in one day, right? So I think thanks for sharing that piece of wisdom. So Akansha, 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? Absolutely.
So. I am an active LinkedIn user, so I can share my LinkedIn profile and people can reach out to me through LinkedIn. Thanks for that. I will put that in the show notes as well. So thank you so much, Akansha for your sharing today. So I really learned a lot about engineering management as well. So thank you for that. Yep. Thank you so much Henry, for having me. This was really insightful and you know, I loved our super candid discussion and all the best to everyone listening out.
And yeah. Thank you for listening to this episode and for staying right until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode and if you're new to the podcast. Make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page at Tech Lead journal dot dev website, including the full transcript, interesting quotes, and links to the resources mentioned from the conversation. And lastly, make sure to subscribe to the show's mailing list on tech lead journal dot def to get notified for any future episodes. Stay tuned for the next Technically Juno episode, and until then, goodbye.