Episode 15
Software Engineering Managers - Akanksha Gupta - HS#15
Think Like a Software Engineering Manager - insights with Akanksha Gupta
Get her book 45% OFF with code hockeystick24 here: https://mng.bz/v8va
Join Miko Pawlikowski on this episode of HockeyStick as he delves into the world of software engineering management with Akanksha Gupta, author of "Think Like a Software Engineering Manager". Explore Akanksha's journey from software engineer to engineering manager and gather valuable insights on making the transition, thriving in the role, and avoiding common pitfalls. Learn about essential skills such as delegation, career discussions, and maintaining team morale, along with practical strategies for hiring, managing attrition, and personal growth.
0:00 Intro
0:24 Meet Akanksha Gupta: Author and Engineering Manager
1:09 The Journey from Engineer to Manager
1:34 Writing the Book: Inspiration and Challenges
4:31 Deciding to Transition: Promotion vs. Lateral Move
9:09 Navigating the People Aspect of Management
15:19 Key Traits of a Good Engineering Manager
34:52 Continuous Learning and Self-Growth
40:00 Final Advice for Aspiring Engineering Managers
Transcript
I'm Miko Pawlikowski and this is HockeyStick.
Speaker:Today we're talking about the role of software engineering
Speaker:manager, something close to home for virtually everyone in tech.
Speaker:Whether you're considering becoming one, trying to get better at being
Speaker:one, or complaining about one to your significant other, there are
Speaker:good and bad ways of doing it.
Speaker:And we'll talk about both.
Speaker:I'm joined by Akanksha Gupta, the author of "Think Like a Software Engineering
Speaker:Manager", Manning, Engineering Manager at Amazon AWS, and Amazon Bar Raiser,
Speaker:and a huge advocate of women in tech.
Speaker:Akanksha previously worked at Robinhood, Audible, and Microsoft.
Speaker:Welcome to this episode, and thank you for flying HockeyStick.
Speaker:Akanksha, how are you doing today?
Speaker:I'm doing great and thank you Miko for inviting me for this podcast.
Speaker:I'm very excited to talk about your book and to meet the author behind.
Speaker:"Think like a software engineering manager" is a catchy title.
Speaker:the moment I saw that I knew I needed to read the book.
Speaker:Who came up with the title?
Speaker:Was that yours or is
Speaker:that the editing team?
Speaker:so I did come up with the title so I am a software engineering manager,
Speaker:and, I've been a software engineer.
Speaker:That's where I started my career.
Speaker:I was always passionate about moving to management.
Speaker:this is, a few of my learnings and experiences coming out live,
Speaker:especially from that, transition from a software engineer to a
Speaker:software engineering manager.
Speaker:Definitely.
Speaker:And it's a catchy title for sure.
Speaker:Would you like to tell us a little bit about why you decided to
Speaker:write a whole book about that?
Speaker:Was it traumatic enough of an experience that you figured let's help
Speaker:others Make it a little bit smoother.
Speaker:What's the story behind the book?
Speaker:Yes.
Speaker:absolutely.
Speaker:the story behind the book is that, my career started as a software engineer.
Speaker:anytime I change jobs as a software engineer, there were multiple resources,
Speaker:out there, that can help you with coding and, things around that, for
Speaker:example, a few top of my mind are lead code and hacker rank, which are
Speaker:still, very relevant in today's world.
Speaker:with few years as a software engineer, when I finally decided that my technical
Speaker:foundation is strong and I want to, make the move to engineering management.
Speaker:I struggled to find the right set of resources to help me
Speaker:with, interview preparation.
Speaker:And also, once I'm in the role, thrive in that role.
Speaker:there are books around there, like "the manager's path" and, "extreme ownership".
Speaker:So I won't deny that, there aren't any.
Speaker:books or blogs out there.
Speaker:but I really felt that they still, miss that, practical experience, or,
Speaker:I would want someone to, tell me, what to really expect if I'm in that role.
Speaker:so all my, struggles and anxieties, were really the driving force,
Speaker:behind putting this book together.
Speaker:so this also, covers some of my interview preparation notes and, how I went about
Speaker:really using my experience from one job and translating it to, the other
Speaker:job really, helping others out there, who are in a similar situation like
Speaker:me, first of all, thinking whether, this is the right move for them.
Speaker:and, how do you treat it?
Speaker:you don't want it to be a one way decision, not everybody's
Speaker:going to be successful.
Speaker:from a software engineer to a software engineering manager.
Speaker:So really understanding that differences, doing that introspection: will I be good
Speaker:at that role if I were to take it, right?
Speaker:So it's more targeted at people who consider making the jump, rather
Speaker:than the people who already have?
Speaker:Is that a correct assessment?
Speaker:so it covers both aspects of it, but yeah, it definitely, helps people who
Speaker:are also, thinking about that move and that's exactly, what chapter two is all
Speaker:about, understanding, that transition and making sure, that's good for you.
Speaker:Once you are in the role, it also provides, all the experiences
Speaker:and nuggets of how you should be thriving at that role.
Speaker:the target audiences, software engineers thinking about that role.
Speaker:pretty new, engineering managers in the role and, trying to navigate, all
Speaker:the complexities around it and also the experienced EMS, you know, who want to
Speaker:learn new and, grow to their next level.
Speaker:So it covers all the aspects of it.
Speaker:let's uncover some of that.
Speaker:I think for a lot of people who listen to this, there's going to be a healthy,
Speaker:good chunk who are actually software engineers or some kind of related
Speaker:field, doing as a day job day to day.
Speaker:So I think what you just described, that decision of whether to make that move
Speaker:or the perception of that being seen maybe as the only career progression
Speaker:route, is definitely something that a lot of the audience will be familiar
Speaker:with and will really hit close to home.
Speaker:So maybe let's start there.
Speaker:I was happy to see that you addressed the question of promotion versus
Speaker:lateral move, for engineering managers.
Speaker:And I think this is this perennial question of the career progression to
Speaker:maybe staff versus, engineering manager.
Speaker:Can you talk a little bit about how you thought about this when
Speaker:you were writing the book and what advice you were given around that?
Speaker:So I think this is, like moving from software engineer to a software
Speaker:engineer manager, this being treated as a promotion is like a very common
Speaker:misconception, fortunately in all the, big firms and even the, medium sized
Speaker:tech firms that I have worked with, there are always two career ladders.
Speaker:One where as an individual contributor slash software
Speaker:engineer, you can grow in that role.
Speaker:focus on technology without worrying about, managing people, and taking care
Speaker:of the people aspect and, if you really want a combination of both, which is
Speaker:technology and people, you can, move to an engineering management role.
Speaker:obviously you start your career as a, initial entry level or
Speaker:a junior software engineer.
Speaker:And as you grow up on the role, there's always a chance to, laterally move
Speaker:to a subsequent, position where you can start managing people for those,
Speaker:who, would like to continue as a software engineer and, continue on
Speaker:that individual contributor track as you, definitely said there's positions
Speaker:like, software engineer or principal engineer, that we commonly have in Amazon.
Speaker:So you definitely have a track for it.
Speaker:And, if someone feels like, Hey, I want to move to the people aspect,
Speaker:then you have the engineering manager, a senior director, VP, like
Speaker:that sort of a career trajectory.
Speaker:So in my opinion,
Speaker:doing that lateral move is not at all a promotion.
Speaker:And that's what I have seen in, the tech firms, It's more of
Speaker:what motivates you and, what will make you successful and happy?
Speaker:another thing I'll call out is that again, it's not a one way door.
Speaker:I have personally seen in my friend circle, people who moved from an engineer
Speaker:to a engineering manager, did not like the role or maybe did not thrive and then
Speaker:moved back as a individual contributor.
Speaker:So I've definitely seen that happen.
Speaker:it's easy to do at a level which is closer to where you do the lateral move
Speaker:versus, someone like very senior VP trying to, move as an individual contributor.
Speaker:those can also happen, but rare situations, it's mostly, closer to a
Speaker:senior software engineer moving to a, senior software engineering manager role.
Speaker:I think it's interesting what you just mentioned about being able to go back
Speaker:and I'm trying to scan my memory how many times I've actually seen this
Speaker:in action and I can count it on one hand only, people who, stayed at the
Speaker:same time, made, an impact as a people person as a manager and also kept
Speaker:themselves, sharp enough and up to date enough for long enough period that
Speaker:they could go and do something without feeling a bit too embarrassed about it.
Speaker:but I think like you said, it's possible, but it's definitely not easy.
Speaker:And, I think it's more of an exception than a rule, to be honest with you.
Speaker:So you mentioned that in the ideal world, and from your experience in AWS, this are
Speaker:two paths that are more or less equivalent in terms of prestige, and I guess money
Speaker:really is the quiet part set out loud.
Speaker:which is, a motivation for a lot of people understandably, but is it
Speaker:really true for the majority of time?
Speaker:Or is it more of an idea world situation and a few places get it right.
Speaker:But on average, it's probably not a hundred percent true.
Speaker:What would you say to that?
Speaker:it's not a universal rule for sure.
Speaker:the tech firms are definitely following it, right?
Speaker:If you talk about, Fangmula, there are still, few, I would say, government
Speaker:agencies and things around that, that definitely don't follow this
Speaker:universal rule, where, having that manager in your title can be more
Speaker:of a prestige, as you said, right?
Speaker:even though, the pay might be similar.
Speaker:but yeah, In the software tech sector, I'm definitely seeing these to be, pretty
Speaker:much at par in terms of, the prestige and obviously the money aspect of it.
Speaker:That's great to hear.
Speaker:So let's move to what happens once you take the plunge, right?
Speaker:You've succeeded so far as an individual contributor.
Speaker:You were selected.
Speaker:you were the junior person.
Speaker:Eventually became senior person.
Speaker:And at some point you decide to take the dive and become a manager.
Speaker:And that's a big change.
Speaker:Why is it such a big change?
Speaker:So the biggest change, the moment you take that role, obviously
Speaker:technology will continue, right?
Speaker:You have to be, very close to, the code itself and the product.
Speaker:what changes, overnight is the people aspect of it, right?
Speaker:You are now managing people.
Speaker:your success is the success of your team and your team members, right?
Speaker:you have to be very much, vested in not just your career growth, but the career
Speaker:growth of people reporting to you.
Speaker:You will be, on day to day Basis or weekly basis would be, doing
Speaker:one on one conversations, career discussions, helping a junior engineer
Speaker:grow to a senior software engineer.
Speaker:that entire people aspect that, comes with the engineering manager role is something,
Speaker:that, any new engineering manager has to learn, grow and really hone that skill.
Speaker:Yeah, and on top of that, you have the added problem that yesterday
Speaker:you were all peers on the same team and all of a sudden now people are
Speaker:supposed to report to you, right?
Speaker:Which is also not easy.
Speaker:what does your book offer in terms of advice for dealing
Speaker:with that particular problem?
Speaker:going back in my time at Audible, I was a senior software engineer and
Speaker:that's where I made the transition to a software engineering manager.
Speaker:And, I became the manager for a team where I was myself a software engineer.
Speaker:So obviously, as you said, my peers were someone who were asked to
Speaker:report to me in the coming few days.
Speaker:so one strategy, that worked was, Taking it slow, it wasn't like a
Speaker:cold turkey change immediately.
Speaker:so I worked with my manager to have a good transition period where,
Speaker:Instead of they directly reporting to me on the first day.
Speaker:I tried to build relationships, obviously I had relationships as peers
Speaker:working with them together in a team.
Speaker:I started spending more time doing one on one conversations with them,
Speaker:trying to understand, what works for them, what doesn't work for them.
Speaker:any type of things we can change in the team just to make sure, that
Speaker:we are more productive as a team.
Speaker:So just, building that relationship one on one, with the team
Speaker:members, was very helpful.
Speaker:and again, you're not taking that transition slow, right?
Speaker:So I think I definitely use good 3 months or so before my actual transition
Speaker:to, use that time to just understand, people's motivations, how I can help them.
Speaker:another, thing that I kept in mind was being a patient listener, right?
Speaker:this is also something that I learned that, as a software engineer, you can be
Speaker:absolutely vocal and, share your opinions.
Speaker:But as an engineering manager, you want to hear others, right?
Speaker:You want to understand where is it that you can go and help them, right?
Speaker:that sort of a skill set was something that took time to, get used to,
Speaker:but, observing from the side and, making sure you're not jumping on
Speaker:anything and everything, right?
Speaker:so that's what, that's the strategy.
Speaker:And that's, on similar lines is what I cover in the book that, small nuggets
Speaker:that you need to change that can really help, others believe in you, trust you
Speaker:as a leader will take you a long way.
Speaker:Yeah, I think that definitely helps with that discomfort.
Speaker:Another thing that I think I've seen in basically everybody I know that made this
Speaker:transition is that Until then, you had a very concrete way of demonstrating,
Speaker:that you've delivered what you said you would, of criteria of success, and
Speaker:you deliver your tests, they all pass, it's all, checklist, and then all of
Speaker:a sudden, you got much more fluffy goals, oh, is the team doing okay?
Speaker:Is the morality nice?
Speaker:And it's much harder to have automated unit tests to verify your team morality.
Speaker:Okay.
Speaker:absolutely right.
Speaker:is that also something that you cover in the book?
Speaker:Are there any hints that you can give to people on that?
Speaker:If
Speaker:Yes, your entire success metrics change, right?
Speaker:As an individual contributor, your success metrics could be, you leading
Speaker:the projects, making sure, that we are hitting the deadlines, obviously the
Speaker:code quality for which, we have a lot of automated tools to, kind of test that.
Speaker:The moment you become a software engineering manager,
Speaker:your success metrics change.
Speaker:As I said earlier, your success is literally your team success.
Speaker:so not only are you responsible for making sure the projects, hit
Speaker:the timeline in the right way.
Speaker:the teams were all should be high.
Speaker:One thing I can say is that, it's not completely fluff, right?
Speaker:at least I've seen that a lot of it can, be clearly objectified.
Speaker:so few forums could be, doing.
Speaker:frequent, surveys to just check off, how the people are doing.
Speaker:And this is pretty much a practice that I'm seeing, majority of
Speaker:the tech firms that follow.
Speaker:so yeah, making sure that, how's the work in general?
Speaker:Are they happy?
Speaker:This also helps, not just an immediate engineering manager to
Speaker:know how the team is doing, but also like the HR to understand, how
Speaker:are the benefits and compensation, everything is, at the industry bar.
Speaker:So I think, it helps in multiple ways.
Speaker:all those factors are very difficult but there are ways
Speaker:where, you can objectify, all that.
Speaker:so I also covered the aspect of, as an engineering manager, it's also important
Speaker:to focus on engineering and operational excellence in your team, right?
Speaker:your team members cannot just be like, pushing code like it has
Speaker:to be good quality code that is, logical, maintainable for the future.
Speaker:people are making sure that there is stress on documentation so that, tomorrow
Speaker:if you have a new hire in the team, it's not spending, months and months just
Speaker:to train them and bring them on board.
Speaker:yeah, definitely, covering all that aspects.
Speaker:Okay.
Speaker:So let's spend a few minutes now to try to paint the picture of what a
Speaker:good software engineering manager actually looks like in practice.
Speaker:we already gave some hints and we talked about the early, transition details.
Speaker:But if we go back to first principles, what are the most crucial things that
Speaker:make a good software engineering manager?
Speaker:And what are the bad ones that make a terrible one?
Speaker:as a good engineering manager, of course, you have to be a people person,
Speaker:You have to put others, before you.
Speaker:so any good engineering manager in my head would be, Driving career
Speaker:discussions, doing frequent one on ones.
Speaker:And when I say frequent, obviously, weekly or bi weekly, depending on the team size,
Speaker:mentoring and coaching people, right?
Speaker:so this would be really, important for me and, having that, emotional, intelligence,
Speaker:the empathy towards, the team members.
Speaker:So I think that's one.
Speaker:the second would be you walk the talk as an engineering manager.
Speaker:I personally would not ask anyone in my team to do something
Speaker:that, I wouldn't do myself.
Speaker:So really leading by example, there was a point, at Amazon where, there was a
Speaker:lot of focus on using AWS technologies in our day to day, work and, focusing
Speaker:on, what's the latest and the greatest.
Speaker:So I knew, and I could see that, in the technical roadmap coming six
Speaker:months, we would be using some new AWS technologies, which obviously
Speaker:my team doesn't have expertise and even I don't have expertise on.
Speaker:So my goal was to get my team members, AWS certified, to make sure we are,
Speaker:geared ahead of time, before we get into the real practical projects.
Speaker:what I did was I went ahead, started exploring about the various
Speaker:certifications, myself took the time to study, get AWS certified, and then
Speaker:use that example in one of my team meeting to really motivate the team to,
Speaker:learn and get to, get AWS certified.
Speaker:leading by example, really help my team members to understand, the importance.
Speaker:I could share my learnings and what new, knowledge that I gained
Speaker:as part of the entire process.
Speaker:I could also, point them to a lot of learning resources.
Speaker:And then, out of the eight engineers, like five of them, really Did
Speaker:pursue the AWS certification.
Speaker:a good software engineering manager should definitely, lead by example.
Speaker:I think that these are the main things that I think from the people
Speaker:aspect of it, and then, Jumping to the project aspect, right?
Speaker:they should be, organized and should definitely understand the value of time.
Speaker:because once they are in the role, they will be like the main point of contact to,
Speaker:ensure a successful delivery of a project.
Speaker:taking care of like things like resourcing, making sure, you are,
Speaker:connecting the right dots, someone who's understanding the motivations
Speaker:of their engineers and, tagging them to the right set of projects.
Speaker:that comes as part of, the whole project delivery execution.
Speaker:and in this process, you're building relationships, not just with
Speaker:your team members, but also your cross functional partners, right?
Speaker:You would be working with product managers, technical program
Speaker:managers, QA, UX resources.
Speaker:thinking holistically about that team, is something, that a good engineering
Speaker:manager will always keep in mind, keep people on track, recognize everyone,
Speaker:of the work that they are doing, and it doesn't have to be always,
Speaker:a compensation based, recognition, which is not, always, possible.
Speaker:So just, thanking people for all their work and acknowledging
Speaker:that, we value them as an asset.
Speaker:So that's really important.
Speaker:and I think, the next aspect would be the whole process, right?
Speaker:doing it the right way.
Speaker:As I said, you are thinking about engineering excellence.
Speaker:You're thinking operationally that the code is of high quality and maintainable.
Speaker:tomorrow, if you know a particular service that you own has to
Speaker:be transitioned to a new team.
Speaker:That transition should be as seamless as possible.
Speaker:So I think, these would be the main skill sets, or things that a good
Speaker:engineering manager would keep in mind.
Speaker:yeah, I definitely missed, the whole hiring and attrition piece in the people
Speaker:aspect where, you have to make sure you're hiring, the greatest people,
Speaker:you're maintaining a hiring bar, you're not always thinking about, Oh,
Speaker:I'm hiring this person for my team.
Speaker:You're hiring it for the company.
Speaker:So it should be a skill set match for your team, but also
Speaker:a culture fit for your company.
Speaker:what else?
Speaker:Yeah.
Speaker:Attrition, that is something that will happen.
Speaker:gearing up and being proactive about it, are the important things, or,
Speaker:Definitely that distinguishes a good engineering manager from a bad.
Speaker:Okay.
Speaker:I think we can go back to basically hiring attrition and performance
Speaker:management, maybe in a little bit.
Speaker:I'm curious as you are researching the book and preparing, what were some of
Speaker:the worst examples of what you've seen people do as engineering managers?
Speaker:What's the most, important to avoid things and mistakes that people do?
Speaker:the biggest mistake I saw was people using, the career discussions to be
Speaker:more of project check-in, those 30 minutes or so are for, you to connect
Speaker:with your team member, focus on their, motivations, opportunities and, have an
Speaker:actionable item for their career growth.
Speaker:I myself have, sometimes, given the project timeline.
Speaker:brought like project discussions as part of one on ones.
Speaker:But, obviously taking a step back from that.
Speaker:So I think, the worst mistake and engineering manager could do is use,
Speaker:career discussions or the one on one meetings to make it more of a
Speaker:project check in and, use the entire time for that sort of a discussion
Speaker:versus, focusing on the real piece of it, which is helping someone grow.
Speaker:Okay, I'll take that.
Speaker:I've seen a fair share of that being done and I agree.
Speaker:That's probably a pretty bad newbie mistake.
Speaker:What about some good examples.
Speaker:Can you think of anybody who inspired you and from whom you learned a lot, that
Speaker:ended up being the foundation for what you think about software engineering manager?
Speaker:These
Speaker:yes.
Speaker:So I think, in my years, I've always observed, my managers and my leaders,
Speaker:with different, leadership styles, to see, like what, what would make a
Speaker:good engineering manager versus bad.
Speaker:the way someone executes, that also helped me, make my set of, principles, right?
Speaker:Okay.
Speaker:these are the things I should be doing.
Speaker:And these are the things I shouldn't be doing.
Speaker:no particular person in mind, but, Having observed multiple leaders, and it's
Speaker:not just, people up in the hierarchy, like also some of my peers, there have
Speaker:been instances where I have learned from, my peer software engineering
Speaker:managers, personally, delegation is one thing that comes, top of mind, right?
Speaker:that's another unique skill set that you as an engineering
Speaker:manager have to, learn and hone.
Speaker:and I can, definitely, I feel comfortable saying that every new software engineering
Speaker:manager, like that's one thing that majority of them struggle with.
Speaker:At least, from my experiences as I mentor other, engineering managers.
Speaker:So delegation is something, where people struggle with and in my head is
Speaker:a very important skill set to learn.
Speaker:Why do you think people struggle so much with delegation?
Speaker:it's just a human psychology, right?
Speaker:you have that, 'I would do everything myself' mindset, right?
Speaker:Especially for folks, who were a software engineer, they might
Speaker:think, 'Oh, if I do this task, I can definitely do this faster', right?
Speaker:Versus, trying to teach someone, spending that, knowledge transfer
Speaker:time and getting them up to speed.
Speaker:What people, definitely, miss in that is that as you are teaching someone
Speaker:else, you are definitely removing yourself as a bottleneck and also
Speaker:having that multiplier effect, right?
Speaker:Going back to your question, having that mindset of, I want
Speaker:to do everything myself, and be like that sole knowledge bearer.
Speaker:And the other aspect that I've also seen, which is very interesting is, people who
Speaker:are super hardworking, they can sometimes.
Speaker:Feel guilty about, offloading work to others, and that's
Speaker:also another aspect where, they might struggle with delegation.
Speaker:Have you seen this scenario?
Speaker:Imagine, you're an IC.
Speaker:You are very good at what you're doing.
Speaker:You continue doing some work.
Speaker:And then one day, You're told,' okay, now you're supposed to delegate that'
Speaker:and you delegate that and all of a sudden you realize, okay, I'm not that special.
Speaker:Someone else just can learn this and can also do that.
Speaker:Is that also part of the equation that I guess selfish, 'I want
Speaker:that recognition from doing that'.
Speaker:And now how do I justify me being here if someone else is doing that?
Speaker:that's exactly what I covered in the first one.
Speaker:you want to be the sole knowledge bearer, to, continue to keep your
Speaker:prestige and, like that special aspect.
Speaker:but in my opinion, as you are growing in the role, a junior engineer having
Speaker:that mindset might be okay, but, anyone who's senior in the role, should
Speaker:definitely, use the power of delegation and stay away from that mindset.
Speaker:You can be good at doing a particular job.
Speaker:you would be, till six months, one year.
Speaker:You can be a rock star.
Speaker:you're absolutely good at it, but there would be a point where you also need to
Speaker:start growing to the next level, right?
Speaker:And what got you here will not take you further.
Speaker:So that's exactly where.
Speaker:you need to prepare someone else in your role so that you can step up and,
Speaker:pick bigger challenges, Maybe you were thinking about like a team wide problem
Speaker:all this while and now you want to, scale yourself, think about something
Speaker:across team or across organization.
Speaker:until you free yourself up from the usual tasks that you've done, and
Speaker:you've been good at you cannot scale and have that, multiplier effect.
Speaker:What else is crucial?
Speaker:I think you hinted previously at shaping the team by hiring and
Speaker:managing attrition and delivering performance management and all of that.
Speaker:So maybe let's jump into that now.
Speaker:What's the most important in all of that?
Speaker:where do you usually start, when you mentor some new,
Speaker:software engineering managers?
Speaker:I think in the hiring aspect of it, the first, principle in my head is to start
Speaker:with, why do you need to hire, right?
Speaker:You need to understand, what is the motivation, Why can't the
Speaker:individual, workforce continue to, deliver, what you're expecting?
Speaker:is it like new set of work or, someone left the team and you
Speaker:want to, fill that position?
Speaker:is there a shortage of a particular skill set in your team?
Speaker:So really understanding the why behind hiring, is step one.
Speaker:and something, I ask every, software engineer to think
Speaker:about, as the first step.
Speaker:Once you know the why, you can absolutely decide how do you want to go about hiring?
Speaker:and that can also help you understand, what are the forums
Speaker:or the portals that you should be, reaching out, to, do that hiding.
Speaker:So that's like the first, principle in my head, like understanding
Speaker:the reasoning behind it.
Speaker:and that also helps you justify to the leadership in case you're asking for,
Speaker:more, open head count rules, right?
Speaker:what's the justification behind that role?
Speaker:once you have that, the second step is to figure out, are you always going to
Speaker:focus on, the external hiring, which is hiring folks from inside, or, you want to
Speaker:grow someone internally into that role?
Speaker:just throwing out an example, let's say you have an engineer in
Speaker:the team who's, Always been very interested in the product side of it.
Speaker:And, focusing on the product success metrics.
Speaker:and you don't have a product manager think about can you help this person grow
Speaker:knowing their long term, motivations to be in a product manager role, into that role.
Speaker:these sort of things to keep in mind where, it's not always like
Speaker:the de facto, external hiring, but also keeping in mind the internal,
Speaker:career motivations of internal folks.
Speaker:so that's another, key skill set and something that, people
Speaker:miss as they think about hiring.
Speaker:then, as you are hiring.
Speaker:Also understanding, are you hiring, for an existing team, which can
Speaker:be, obviously your team, or are you trying to set up a team from scratch?
Speaker:Because these two scenarios will completely be different, right?
Speaker:If you're trying to, hire someone for your existing team, you need to keep, the
Speaker:existing skill set of the team members in mind, the team culture, because this
Speaker:new person is going to join and, they need to gel up with the existing set of
Speaker:employees, on the contrary, if you're trying to, hire for a team that you're
Speaker:building from scratch, you need to be very clear with the tenets or mission of
Speaker:this new team, because that's what you're going to use to, sell to the new set
Speaker:of, members that you're going to hire.
Speaker:and also understand, that you want to hire a mix of junior and software engineer.
Speaker:balancing all that skill set, and then these are the new set of people who
Speaker:are going to define the team culture.
Speaker:I think, in both ways, there's like a, Pros and cons, so you have to, keep
Speaker:all these factors proactively in mind, as you are thinking about hiring.
Speaker:So these are the fundamentals that I also cover as part of my book.
Speaker:And there's an entire chapter that talks about hiring, that
Speaker:goes into these level of details.
Speaker:another common thing is that, you want to be focused on the diversity and inclusion
Speaker:piece, At least something that, I have learned in my recent years is make sure
Speaker:that, the job description you're having should use gender neutral language, right?
Speaker:the job description should be inviting, you're trying to make
Speaker:it as inclusive as possible.
Speaker:So yeah, these are some, good tips that I have learned in my, recent years
Speaker:and something that, I apply and, I'm sharing with everyone through my book.
Speaker:What advice do you give for those situations
Speaker:as important as hiring, attrition is also something that any engineering
Speaker:manager should, proactively think about.
Speaker:I feel it's totally inevitable.
Speaker:especially in given times where, we have, with the whole pandemic, people
Speaker:started working from home and now the companies are asking members to come
Speaker:back with the whole return to office.
Speaker:so when I think about attrition, It, it can be driven by, two motivations, right?
Speaker:One could be voluntary, one could be involuntary.
Speaker:voluntary reasons would be, yes, you have family reasons, one of your
Speaker:family member is moving or you want to pursue some, higher education.
Speaker:or you're just not happy with the role, right?
Speaker:Your company's mission is to do something and you're totally opposite.
Speaker:you don't have any beliefs.
Speaker:So there can be a lot of, voluntary reasons, that can, cause attrition.
Speaker:Compensation is not good.
Speaker:and then there can be involuntary reasons, Which we've all seen in the
Speaker:recent times, there can be layoffs or, there's more of a merger and acquisition.
Speaker:And that also, causes, some of the positions to be, removed.
Speaker:there's always a combination of these two.
Speaker:when we think about attrition now, as a software engineering manager, you can be.
Speaker:proactive about it, or you can be reactive about it.
Speaker:in terms of being proactive, you can always, maintain a hiring pipeline.
Speaker:one thing that I usually do is, I'm trying to, continue to,
Speaker:invest in my professional network.
Speaker:Let's say you, you are attending conferences, right?
Speaker:Definitely, advertise about your company, share more about, what exactly you do.
Speaker:So you are, generating that awareness about that.
Speaker:And then, there might be in future people interested in the role.
Speaker:so this is more of a proactive measure where you are thinking about the
Speaker:hiring pipeline, keeping that word out.
Speaker:Another key aspect that I would call out is, thinking
Speaker:about internal mobility, right?
Speaker:You have a set of people you are managing, using those one on ones,
Speaker:which I brought up earlier to, understand their career motivations.
Speaker:And if you think that, someone is at a risk of, moving away, because, maybe
Speaker:their career aspirations are not being met, try to be proactive about it.
Speaker:If someone wants to move to a particular role, see if you can, provide that
Speaker:internal mobility and support that move, so that, you're not losing the
Speaker:person, because obviously there's a very high, backfill and hiring cost
Speaker:involved every time you lose an employee.
Speaker:So I think, that these are some of the proactive measures you can take.
Speaker:Now, on the flip side, let's say, your employee has taken the decision, then,
Speaker:you get into the mode where you're trying to take any reactive measures, right?
Speaker:So the first and foremost should be.
Speaker:trying to see, how you can save that situation if it's like a compensation
Speaker:thing, then, maybe engage with HR and, your manager just to see if there's
Speaker:anything you can, do to still keep the employee, obviously making sure
Speaker:that, looking at their, how big of an asset, then that way you can pull some
Speaker:levers and, try to, save the situation.
Speaker:or if it's more of an, again, internal motivation to move to a different role
Speaker:or, a different technology, then you can try to find a fit within the company.
Speaker:So this is again, a reactive measure.
Speaker:Now, this is not always true.
Speaker:Sometimes people have already made up their mind, and it's like, a situation
Speaker:from where there's no going back, right?
Speaker:So in that situation, it's important to, just acknowledge what is in front of you,
Speaker:and then making sure that transition, of this employee out is as seamless as
Speaker:possible, so in such situations, you can focus on making sure that there's a
Speaker:proper, off boarding checklist, right?
Speaker:Where This person does no knowledge that is lost in this transition.
Speaker:So making sure you have all the knowledge transfer sessions
Speaker:with the existing team members.
Speaker:there's good set of documentation.
Speaker:Once this person leaves, thanking this person for whatever they've done, till the
Speaker:time they were in the team, they've been an asset and you never know when, they
Speaker:might come back and join back your team.
Speaker:And I'll tell you, I've seen that multiple times, especially in my
Speaker:Amazon culture, where people have, left a particular team and, tried a
Speaker:different gig in an internal team and have come back to the previous team.
Speaker:Never think that door is shut.
Speaker:So always, that whole, transition should be seamless, because anyone leaving,
Speaker:also impacts the morale of your team, just making sure that, that morale is
Speaker:high is also something that you have to keep in mind as part of attrition.
Speaker:this is basically the ultimate test of how well you've done as a manager.
Speaker:If a person is leaving, and let's say that this is a situation when they have
Speaker:a good reason to leave and you stop supporting them, then at that stage you
Speaker:don't act anymore in their best interest and don't support them to go and get
Speaker:that better for their situation job.
Speaker:It's okay, so you've, made me feel that you cared for me and you were
Speaker:in my corner this entire time.
Speaker:And now that I'm leaving, all of a sudden that changes, right?
Speaker:But it's hard.
Speaker:I remember the first person who quit on me, the initial
Speaker:reaction was like, Oh, wow.
Speaker:I invested so much in you and I thought we were doing great.
Speaker:Why are you going?
Speaker:this is awful.
Speaker:But then when you think about it for a little bit, then you
Speaker:understand, okay, this genuinely is a better opportunity for them.
Speaker:And it allows them to do X and Y, that's when you show them the
Speaker:support and you help them because this is the right thing to do.
Speaker:So yeah, I can definitely relate to what you just described and I feel like this
Speaker:is this, weird test at the end of that, that dynamic that's waiting for you.
Speaker:as you gain more experience, you accept that and you'll be
Speaker:more, mature in your approach.
Speaker:your first experience of someone quitting on you, definitely take the learnings,
Speaker:and then when it happens again, and as I said, attrition is inevitable, right?
Speaker:you can do a better and better job and learn from those experiences.
Speaker:So I think we've covered a lot of good stuff now, and what comes to mind is
Speaker:In this new position, you've taken the plunge, you focused on all this
Speaker:other things, and you spent most of the day now resolving people's problems
Speaker:and listening to them and trying to get the project to go in the right
Speaker:direction and for everybody to grow.
Speaker:And the question then becomes: how do you.
Speaker:Make sure that you don't get left behind in terms of growing
Speaker:yourself in the entire process.
Speaker:What advice do you offer, in that respect?
Speaker:you have to invest in your team members and you have to invest in yourself.
Speaker:as an engineering manager, and even, perhaps any role, growing and
Speaker:investing in yourself is a continuous, you know, iterative process, right?
Speaker:There's never enough.
Speaker:with engineering manager, any manager, it's an important aspect because it's
Speaker:not a coding language where you can go, debug the code straight away.
Speaker:understanding people is, always a difficult task.
Speaker:what may work for one person might not work for the other person.
Speaker:I definitely feel that, it's a continuous learning and, growing process.
Speaker:You have to invest in, growing yourself, in terms of, okay, technology people,
Speaker:but you also have to, spend time.
Speaker:I feel like just to, regulate your mental temperament, just because, sometimes
Speaker:as a software engineering managers, you can be in really tough situation.
Speaker:So I think, like balancing that is really important.
Speaker:something that has worked well for me as well as, the first one being, having
Speaker:like mentors or, sponsors in your life.
Speaker:having people who you look up to, who can be your sounding board, who can,
Speaker:definitely guide you toward, when you are facing any difficult situations.
Speaker:having them is really important.
Speaker:obviously your manager, in the organization can also be a really
Speaker:good mentor, but I strongly believe in having someone, who's outside your
Speaker:immediate leadership chain, that way you can be as transparent to them.
Speaker:And, also get that outsider perspective.
Speaker:Sometimes you're pretty bogged into, what you're working on.
Speaker:there are, definitely several platforms out there, within an organization, I've
Speaker:seen a lot of, mentoring circles that these companies have, outside, LinkedIn
Speaker:is a huge community and something that,
Speaker:I'm very active at, there are also platforms like Plato HQ, growth, mentor,
Speaker:mentor crews that I've seen, and, I've also been part of, so definitely,
Speaker:would recommend people to check out if they've not heard about them.
Speaker:mentorship is one big thing.
Speaker:second would be, as an engineering manager, as I said, you have to be close
Speaker:to the technology, engineers should feel that their manager is sound and, they
Speaker:can go to approach them whether it's a technical problem or a people problem.
Speaker:one thing that I definitely recommend engineering managers to do is
Speaker:to, be in touch with technology.
Speaker:This can be through basic, pet projects that they can do on their side.
Speaker:For example, I myself was trying to, with this whole Jenny, I like
Speaker:trying to do like a quick chatbot one of the week and just, get, get
Speaker:understanding of, what it's all about.
Speaker:also, reactively reading code reviews for the team.
Speaker:I think that also helps, you exactly know what people are working on and
Speaker:don't have to, waste your one on ones asking that, plus at the same time,
Speaker:it keeps you closer to the code.
Speaker:that's another, way to keep, continuously invest and grow
Speaker:yourself, especially technically.
Speaker:Apart from reading, technical blogs or the books, that are, there are,
Speaker:plethora of resources out there for that.
Speaker:what else?
Speaker:there are some really good books, of course, and there's "think like a software
Speaker:engineering manager", but then there are also, other good books that one can learn.
Speaker:I especially find the Harvard Business Review, articles and books
Speaker:to be very useful when I think about, engineering management.
Speaker:that's, another thing.
Speaker:and, 1 thing that.
Speaker:The, is also important just to focus on the soft skills, right?
Speaker:you have to be a good, communicator and a facilitator when it
Speaker:comes to discussions, right?
Speaker:you have to get your points across to the team and, be able to, comprehend others.
Speaker:So I think the communication and then, if you're managing a team,
Speaker:conflicts are also inevitable.
Speaker:being a good facilitator when it comes to that, is also something that's important.
Speaker:So for that, there are some good, LinkedIn learning resources
Speaker:can really help to grow.
Speaker:in my book, I cover, another concept where I've spoken to many people and
Speaker:find it a little controversial so I suggest people to also interview
Speaker:frequently, and then, it's not a very embracable idea, I would say.
Speaker:in my opinion, if you interview frequently, you know what exactly, is
Speaker:the industry standard, what's going on, what do you need to be, continuously
Speaker:prepped up for if you were to, change the role at any point in time.
Speaker:yeah.
Speaker:So that's another interesting concept, for people to think about.
Speaker:Awesome.
Speaker:So yes, in case you missed it, the book is called "think like
Speaker:a software engineering manager".
Speaker:It's available at manning.
Speaker:com.
Speaker:and, we're going to put a link in at the show descriptions.
Speaker:Words for anybody who's now listened to this and is wondering, maybe is in a
Speaker:situation when they have to decide which way to go, whether to go into engineering
Speaker:management or try to stay, I see any last advice to leave our listeners with.
Speaker:Yep.
Speaker:be patient.
Speaker:a lot of people that I know are, trying to make that move.
Speaker:one of the question I usually get when I'm, mentoring them is
Speaker:okay, when is the right time?
Speaker:How soon can I move?
Speaker:it's a typical example of, grass looks greener on the other side, right?
Speaker:be patient, take your time to, research about the role, really gauge
Speaker:your interest in terms of, what's your motivation to move to the role,
Speaker:assess your skillset, talk to people who have, done the, walk the talk.
Speaker:also try to, find people who have thrived in the role as a, senior stuff,
Speaker:staff engineer, principal engineer, you want to know both aspects of the
Speaker:role, before you take the decision.
Speaker:This is not the defacto or, promotion route.
Speaker:make sure that you're very clear with your motivation of moving and whether,
Speaker:that's the right skill set because you don't want to survive in the role.
Speaker:You want to thrive in the role.
Speaker:be very, careful about your move.
Speaker:take your time, assess the situation.
Speaker:And then when the time is right, obviously, take the plunge.
Speaker:Awesome.
Speaker:Thank you very much.
Speaker:That is good advice.
Speaker:And hopefully it will help some of our listeners.
Speaker:Thank you.
Speaker:And I'll see you next time.
Speaker:Thank you for having me.
