BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage Podcasts Becoming a Great Engineering Manager is Hard

Becoming a Great Engineering Manager is Hard

Bookmarks

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Anand Safi about making the shift from being an individual contributor to an engineering manager

Key Takeaways

  • Moving from an individual contributor to an engineering manager leadership role is not a promotion
  • Engineering management means giving up on a lot of the things that you probably enjoy as an engineer.
  • Taking on an engineering management role should be a deliberate decision around being able to contribute in that role, rather than just length of tenure
  • Mentoring and coaching can help to build the skills needed to become a great engineering manager
  • Psychological safety is key to enabling a great engineering culture

Transcript

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. I'm sitting down today across the miles with Anand Safi. Anand, welcome. Thanks for taking the time to talk to us today.

Introductions [00:31]

Anand Safi: Pleasure is all mine, Shane. Thank you so much for having me on the InfoQ Podcast. As I was saying that, this is a wishlist item come true, so really happy to make this happen.

Shane Hastie: Thank you so much. So, who's Anand?

Anand Safi: Professionally I am an engineering leader as a title, but your question is definitely more beyond the titles, which everybody can see through various forums. I think I'm someone who's just passionate about helping people grow, and in turn that brings me growth. I do have a growth mindset in turn, but it's not about trying to just pick up the next best skill, or trying to make the next miracle career move actually. For me as a person it's trying to, at least if I have experienced something good or learning wise, constructive or positive, I'm going to make sure I can enable with those learnings, so they either succeed with those things, or tips in mind, or are aware of the common pitfalls and don't end up making the same mistakes I did. So, I'm a very, very, I would say, collaborative and communicative person in that sense, or as a personality.

Shane Hastie: One of the things that intrigued me when we were corresponding was a statement you made that moving from an individual contributor to an engineering manager leadership role is not a promotion. Why not?

Moving from an individual contributor to an engineering manager is not a promotion [01:48]

Anand Safi: Thank you for bringing that up actually, because I went through this journey myself a few years ago. And as I said, if I have some structuralization, the first thing is I feel comfortable that, okay. Do I probably understand why did I have that feeling? And if I do, then I absolutely want to share with folks. So, recently I think over the past decade, we have seen very commonly two separate tracks for technology centric roles, which is the technical track, and then the leadership and management track. Actually, that was not the case probably for most times. It simply meant that in a company, if you are doing reasonably solid as an engineer, or you are a great individual contributor, the next step meant, for maybe more compensation, more authority, more power dynamics, just having more influence. It meant you needed to be a manager actually.

And that just how influence comes along. But those are two different career paths that we are talking about. We are talking about a lateral move when we talk about going from an engineer to a manager, and it's not a promotion because you will probably do different sets of responsibilities. It's not a promotion because probably the topics that you had in mind, that being a manager you would get those outright, are not true. I, for a fact, know engineers that make much more than a manager would in their early career, because even within management track that are levels in that sense. So, just simply becoming a manager does not mean that you'll get paid more actually. It simply does not mean that you have the will to hire and fire people. I wish companies operated, or I don't wish that companies operated on the whims of just one individual's person, or likes and dislikes in the sense.

So, there's a very thoughtful and structured process. Engineering management means giving up on a lot of the things that you probably enjoy as an engineer. So, that is a big, big point there. I have three or four buckets which I can speak to as well, in terms of what is the day to day responsibilities that will end up looking different? And that hopefully translates to this not being a promotion as it did to me, when I realized those buckets.

Shane Hastie: So, let's explore what are those buckets? What are those areas?

The changes that moving to a management role entail [04:00]

Anand Safi: Sure. So, let me share the four buckets at a high level, and then we can go into any one in detail, depending on which one you find most interesting. So, the first one is simply the amount of coding time. As an engineer, the fact that you want to be or continue being an engineer is you get to code, at least 70, 80% of your time, other than team meetings or other things that come up. Becoming an engineering manager, you might not see that shift happen outright, but in six months, in a year's time, in three years time, it will happen. You cannot continue coding.

I have not coded probably for months now, which is zero, and zero is a real number here, which is pretty common depending on the situation or the teams or the charter you are leading actually. The amount of coding time is the first realization, in terms of this being completely different.

The second realization is the focus time versus meeting time. So, as an IC, as an Individual Contributor, you might still get, even with meetings and distractions, you might get an optional on a solid three to four hour window, for heads down time or focus time. As an engineering manager, this was true for me and I have talked with a lot of my peers and this is true for most is, you get those times in bits and pieces. You might have a meeting, you probably have 45 minutes off. You have another meeting, but throughout the day your pockets of meetings, which are important, I don't want to just simply dismiss that meetings are not important, because the meetings that you are on as an engineering manager, are different than the team's notion that, "Oh, we have too many meetings."

That is a different thing. Engineering manager's meeting could range anything from their one-on-ones with the direct reports, could be a team meeting, could be working with their leadership on some strategy, could be people or HR meeting about recruiting and hiring. Could be a collaboration meeting with their other stakeholders across the suppliers and partners actually, in terms of product and design. So, that is important to first seek clarity, and have the information needed, to pass down into actionable process or task-based roadmap to your team actually, in that sense. So, the whole focus time versus meeting time is important because your time will get fragmented.

The third is, and probably one of my favorites, is definition of success. So, when we talk about engineering, my engineering IC days, I would get a dopamine boost if my PR was approved, or if my build went green, and then if my code was merged, and, "Look. My feature is out. I have CI/CD. I completed three tickets." So, that was success to me as an engineer. My day ended on a high note actually. As a manager in that leadership and management track, success is abstract. There is no clear data points in terms of, because you had 50 codes committed or you completed 20 tickets, you are successful in your role today. You need to come up with your own set of metrics or evaluations. And it took me time to realize over time. I was doing a lot of things as an engineering manager, I continue to do it, but was not sure if those are making an impact or am I successful in the role actually?

So, for me then I was, "Oh, this week we did not have any customer P0P1 issues. This week none of my direct reports said that their morale is low or they don't have clarity, or they don't like working on this team or project. This week none of my product and design counterparts had said that they had a tough time collaborating with an engineer, or with engineering actually." And that was successful for me. No conflict, clarity, alignment, and high morale and those things in that sense. So, the whole success becoming more abstract, and you need to think in bets, is important actually. And then, the last thing is, you need to also be comfortable that you will move to an enabler model versus a creator model.

In terms of, as an engineer you will create software, you will create solutions. You might be able to roll up your sleeves so much more often and doing an implementation thing. As a manager, as much as you would like to show your promise technically, it's best that you don't solve for the team actually. You want to not become a bottleneck for the team, and I think that's why you need to enable others to take technical leadership and day to day responsibility, so you can continue to have a dual presence with the team and outside of the team as well. So, the whole creator versus enabler mindset is important actually in that sense.

Shane Hastie: So, these are, as you say, very, very different competencies and skills to what most of our engineers have been taught. We hear the stories. I mean, we take the best engineer and we make them the worst manager. How do we enable that transition for the people that want to go down that path?

What do we need to do to enable the transition for those who want it? [08:37]

Anand Safi: I think most companies approach this in two ways. One is tenure based, and the second is interest based. Tenure based is, "Oh, you have been here for 10 years, you probably are a tech leader or a senior engineer. It may be time for you to get a report or two." Fortunately we are seeing this not be the case, that people are being asked whether they would like to manage folks, rather than simply saying that you should take on more people management responsibilities because you are being here longer. And the second is interest space, which I think where interests lie, where engineers like myself actually, I knew from early on, I've always had some sort of leadership or collaboration aspect to my role actually, where I knew that I could definitely continue to become more technically solid, and become a principal staff engineer. But I thought I had much more to offer to the company than simply my coding abilities actually.

And it does not mean that, "Oh, you should not be a principal of staff engineer because you'll always end up coding." But the discussions that you will be in will be around technical architecture and roadmap, versus the discussions that I am in, are part those, part strategy, part hiring and recruiting, part people management and growth, in that sense, actually. So, that is important in terms of interest based enablement. I talk to numerous staff engineers. They said if I were to let go of somebody, if a situation ever came, that's terrible for them, they could not do it. Or that's one of the toughest conversations. How do you stand up in front of somebody and have that emotional strength to keep that emotions aside, that you have worked with this person for years or you're a colleague and a great peer, and you're to tell them times are tough or we are going through something and probably this is a misfit in that sense, actually?

The people and emotional aspects of the role are the hardest parts of being an engineering manager [10:23]

Anand Safi: So, that is the parts in terms of people are not showing interest, because there is a tough, tough people and emotional angle or spin to it actually, which is probably the most difficult part of engineering management. The engineering part is, I'm not going to say easy, but it's manageable because you do come from an engineering background and you do have that fundamental foundational knowledge, which probably is the most you need for most of your outside engineering conversations anyways, actually.

Shane Hastie: Where do we build those skills? How do we build those skills?

Identifying the interests and skills that lead to management [10:56]

Anand Safi: Another important point when you ask that question, now I realize I skipped upon, is mentorship and coaching in that sense. Which is you probably should start as a manager, or even if you are an engineer you should not feel hesitant to manage up. And manager does not just simply mean that you tell your manager that this is wrong, or you are not aligned with me, or you're not giving me enough time. Managing up means also advocating for your interests and goals actually. So, you should be having conversations with your managers as engineers, about where your interests lie. And that could be that my interests lie in seeing people grow, or my interests lie in mentoring junior folks actually, to give them the necessary knowledge. Or my interest lies in making sure that when the project or the product that I'm working on faces customers for the first time, or customers are going to look at it, it's technically stable.

I don't want to crash in my application because I cannot take it, because that is where my interests lie in terms of ensuring technical stability for the solution that I built or the product that I'm involved in. So, that is where the first indication will come, in terms of what skills do we need to nurture as managers in our engineers or in our direct reports in that sense? So, then it's on the manager to find you the right opportunities related to those skills actually. And at the same time, trying to evolve, because for early on in my career as a junior to mid engineer, I was telling these things, but I did not... That this basically means I'm probably better suited for the engineering leadership or management track, rather than simply being an engineer.

So, there's some mind mapping involved on the managers part actually, to make sure that I am hearing over time, that this person is more interested in how we are approaching the customer roadmap, or how we are building the product, how we are trying to connect with our stakeholders, how I am trying to ensure that there is a morale high. So, they're interested in probably much beyond our technical stability, that this person is not coming into one on ones and asking me in terms of about that AWS outage, or the war room incident last week, what was technical issue actually? Or what was the root cause? They probably could do it if asked to, but that is not where their curiosity lies. Their curiosity lies in terms of what are we doing from a product development perspective? Are we going to hire two more engineers? Are we going to train our people, or are we going to have a mentoring system in place actually? So, over time it's a two part system.

As engineers you need to be... Or you probably don't need to be, but over time you staff need to get clarity in terms of things you like doing, and probably might not like doing actually. And at the same time as managers, you need to be able to nurture somebody’s strengths and find opportunities. But at the same time, also seeing if there's a way to have them build their less stronger points as well, because you don't need to always play to everyone's strengths. That's how people build winning teams, as I say, just bring everyone's strengths on board actually. But then you have a team of specialists and you don't have smart generalists. Some teams do need smart generalists, so you need to make sure that people are also going out of their comfort zone or challenging themselves to an extent.

Shane Hastie: You mentioned mentoring. Let's explore that, because we know it's a good idea, we hear all sorts of things about mentoring is a great way to help people grow. But what does it look like in practice, and how can somebody in a team, one, choose or request mentoring and also offer to be a mentor?

The value of mentoring [14:44]

Anand Safi: It's interesting. I was actually just in a conversation doing an interview, and one of the leadership candidates mentioned mentoring, coaching and training. Training is something simply learning and educational, so we'll not talk about that. Mentoring and coaching are two main buckets where people, or even I make the mistake of, depending on the time and mood of the day, I might use them interchangeably, which is not the right thing to do actually. But what I have come to understand is coaching is probably where you get specialized assistance or help, in terms of a specific goal. That is maybe over time, you need to get better or you need to work gradually towards that thing. Like if I am getting a life coach because I need to fundamentally change my habit or my mindset as a person, or I am now getting a leadership coach because over time I want to make sure that I am one of the most empathetic leaders. It'll not happen overnight.

While mentorship, fortunately, can be short-lived, and it is a little bit task-based in that sense. So, that is the layman definition of mentorship. How do we put it into practice? The wonderful thing about mentorship is that there is no formal leadership or management title involved around mentorship. We see that very common in engineering teams, that the senior engineer who onboards a junior engineer is around there to ask them questions. People call them assigning a mentor, having a buddy system in place, trying to just have someone be of a label, that you have a mentor who has lived through your experience in some form, and has something of value to offer. That something of value to offer does not mean a clear way of doing that thing, but they can walk with you, in terms of getting you through that challenge that you're going through. They will simply not say, "Oh, yes. I had that same thing as well. It's the build issue. Just run this command and you are done."

That's simply just giving the answer, or just talked down in the sense. Mentoring is working with you just like, "Let's tie right in. What's happening? Probably it's a thing like this. Maybe let's check something." So, trying to be a little bit more collaborative in that sense, that is trying to walk with someone, rather than just pointing them the way, like this is where you need to go, just go, and it's done. That's one aspect. And the second is, as I said, that was simply when it's more reactive mentoring. But the proactive mentoring is when somebody has a short term goal identified. "In three months, I want to change job." Or, "In a year I want to pick up on the next front end technology that is upcoming." Then mentoring is really useful in terms of you can work with your mentor, because they probably have gone through the same kind of thought, or professional transformation, and they can offer ideas on how you might approach it, in that sense.

Shane Hastie: What does it take to be a good mentor?

What it takes to be a good mentor [17:43]

Anand Safi: Excellent question. I think I'm continuing to realize actually that the first thing is the art of listening, and also then actual listening, because there are two pieces. First, the art of listening, simply because as a mentor, you just might want to be, for lack of a better word, be preachy and start imparting knowledge that, "You should do this. You should do that." Before the mentee even finishes the problem, or even who knows that might not be the problem, that might be a symptom. The underlying problem might be something totally different. It might be a cause and effect situation. So, before that, I've seen, or I used to say, "Oh, yes. I've seen that before. These are the three things you can do. Let's dive right in." And then I realize over time, they will come back after 10 minutes. "Wow. All of you that said, I respect you. That makes sense." But probably what I was trying to say is something different actually, in that sense. And that is the art of listening.

And the second thing also I said, just immediately following is active listener, because trying to understand what they're trying to convey and not having the need to just answer back, because you probably, when you sit through their problem statement, as mentees... I continue to be a mentee and I have trouble when somebody is asking me, "So, what exactly is going on with you?" What problem do I say? Maybe it's a low morale thing. Maybe I don't like my project, maybe I have an imposter syndrome. Maybe I have some personal thing going on. How do I structure it into one sentence? So, you need to have an active listening, in terms of, are there split tracks? Are they trying to say two different things as a part of a problem? Are they trying to imply something much more deeper, or are they trying to simply be too self-critical?

Oftentimes that happens. People set so much higher bars for themselves, and at times you need tell them, "I don't think that's a problem, which you think is a problem. In terms of, I think you're doing well. You're probably being over self-critical, and let's talk about it in terms of why do you feel so strongly about that?" So, trying to play back their question so that you have understood correctly, and trying to identify if there are any split tracks, multiple topics, or if they're trying to have strong, emotional connections with the problem. Or it's simply where they feel that everyone around them is growing and they are not growing, and those things. So, listening is important as a mentor.

And then, I'll end my answer by saying the second and most important thing is, Kent Beck put it wonderfully actually at a conference couple of months back, that the secret part about mentorship is where the mentor gets more out of it than the mentee, because I have been in situations where every time I have to try to use my past experience, it does not fit the parameters or the context of the situation that this person is facing. So, trying to bring a fresh perspective, open mind, trying to work together on brainstorming ideas, that is critical thinking for myself. I probably get to do that, but to a finite amount in my team and role. So, as a mentor, you will experience actually much more, I would say, food for thought and just regeneration, if you probably didn't let your past success or failures follow through. And they're good indicators, but they should not be the solutions to each and every new problem that comes up.

Shane Hastie: Thank you for that. So, mentoring is part of an engineering culture. What does a good engineering culture look like? What are some of the things that we need to have in place and that, one, individual contributors, but also as leaders, that we can do to nurture that effective culture?

What contributes to a great engineering culture [21:29]

Anand Safi: I think my umbrella answer in two words for that entire thing would be psychological safety and trying to go deep into that would mean that, as leaders and as managers, you need to give the psychological safety to folks that churn might come at times. Change of management is common at times. Chaos is common at times, especially in these times where companies are securing series ABCDE fundings, day in, day out. Companies go into hypergrowth more overnight, but then with growth comes growing pains, and they don't realize how to live with it. So, I would say that a good engineering culture sticks to three things in any given curve ball that is thrown to them, and that really has psychological safety as the umbrella. But those three things are sticking to its original mission. With each new situation you don't need to pivot.

There are engineering teams which see that their competitor is doing something, and we need to go do that. As an engineering organization, it's good to have some form of competitive awareness, but you need to understand what your mission is. Or if you are trying to make some different impact in your industry, then you need to stick to your mission, which is really important. It's not that you are rigid or stubborn, but your core guiding policies need to more or less stay the same. The second is the people, that you need to continue believing in people, and that's important for leadership and management. That if a company's going through a rough patch, the last thing leadership should do is finger pointing downwards, in terms of, "Well, it looks like the ICs are not pulling their weight. Or probably people are taking it too easy and we have so many issues," or something.

It's a team win and a team failure in that sense. So, they really need to pull it together in the sense that there is no sentiment or negativity around finger pointing or the blame-shifting, those kinds of things. As engineering culture is core DNA in our fabric. So, that's the people in the sense.

And the third is probably similar, that is values. If, as a culture, you value transparency, then because there was some leadership change, then you should not say that, "Well, now we are going to have behind the curtain meetings only. We should not make this thing public with the engineers." The engineers, or people who are there, should have the psychological safety to be vocal about any incoming leadership process change. Especially when it feels that it's out of context, or it's being pushed onto them without getting their input. So, the value set in engineering team lives by the people that it supports, nurtures and relies upon. And the mission that it continues to have as their North Star goal in mind, is what makes a good culture overall, and I think as a recipe of success.

Shane Hastie: Anand, thanks for that. Some really interesting points and things for us to ponder. If the audience want to continue the conversation, where do they find you?

Anand Safi: Currently, it keeps on changing. But my number one source probably for the foreseeable future is LinkedIn. I love connecting with people, meeting with people, so definitely send me a message on LinkedIn or a request. It's Anand Safi. Would love to connect there. I also have a Medium page, a Twitter account, a GitHub profile, a Linktree account, many, many things to just supplement it. But I think that will simply be looking at the work that I've done, and maybe more of a highlight, but connecting with me is definitely LinkedIn.

Shane Hastie: Wonderful. Well, thanks so much for joining us today.

Anand Safi: Thank you so much, Shane, again for having me. And it was great to speak to you on a number of different topics. That leaves food for thought for the next logical step or just something to think about.

Mentioned

Learn how to solve complex software engineering and leadership challenges. Attend in-person at QCon London, (April 4-6) or attend online at QCon Plus (May 10-20).

QCon brings together the world's most innovative senior software engineers across multiple domains to share their real-world implementation of emerging trends and practices. Find practical inspiration (not product pitches) from software leaders deep in the trenches creating software, scaling architectures and fine-tuning their technical leadership to help you make the right decisions. Save your spot now!

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT