video • 11MIN

Why going from Dev to Engineering Manager is NOT a promotion

Anand Safi - engineering leader, mentor and coach - discusses the transition from individual contributor to engineering manager and why this transition should not be considered a promotion.

 

Transcription:

Conor Bronsdon:
Today I'm joined by Anand Safi. Anand, thank you so much for
coming on today for a quick lightning talk with us.

Anand Safi:
Thank you for having me on, Conor. Really excited for this one.

Conor:
Absolutely. We love having engineering leaders on Dev Interrupted,
and I think today we're talking about the transition from individual contributor manager, something that I know you have a strong viewpoint and experience on. Can you fill us in?

Anand:
Yeah, so I wanted to talk about how going from an
individual contributor to engineering manager is not a promotion. It's a different career track. And what we'll be discussing or touching on some of  today is just a fundamental difference in terms of the roles and responsibilities so folks have a better idea when they evaluate for their own career path.

Conor:
And this is something you have personal experience on, correct?

Anand:
Absolutely. I've spent around a decade
in individual contributor roles, and then over the past three years or so I have been in the engineering leadership track. So this is more so a reflection in my take on my personal journey and what I see in the industry around some misconceptions going on.

Conor:
Yeah. It's such an important key point that this
is something we have to consider as like a different track. You can move up as an individual contributor in the engineering world and say, okay, I'm trying to be a senior dev, want to be like a true focus point person for what I'm trying to work on, or you can say, hey, I want to expand my impact to helping manage these teams. And for those looking to move from an IC role into a leadership role with responsibility for more direct reports, can you take us through a bit more in depth exactly how you see this difference between the two tracks?

Anand:
Yeah. So first, as a precursor,
I would like to just talk about what could trigger this kind of transition formal. So the two main ways could be interest based and tenure based. So interest based is somebody who is in a senior engineering role, naturally, a good mentor, coach or just kind of acts as that kind of just glue for the team and is interested to also take on formal people management responsibilities, actually. So that is just where you as a senior engineer are feeling ready to go into more formal people manager track or role. The other is tenure based where you are naturally kind of in your senior engineer tenure for 3+ years, 5+ years, depending on the company and the team or the company feels you are now well positioned to take upon a couple of direct reports. You might be doing a lot of that informally. Just being a mentor unblocking the team as a senior engineer, and it's just trying to see based on your tenure and expertise, you can also be a formal kind of people manager. One key difference to call out here is the kind of overlap between tech lead and engineering manager terms. Actually, there are still companies which will kind of go from a senior engineer to being a team tech lead, but then also they expect the folks take up a lot of that people manager responsibilities. And as we dive into more details in the next few minutes, we'll understand how that EM or the manager track is definitely different. And it's difficult to ask a tech lead or just kind of think that a tech lead role, which is pure and strong focused on delivering scalable software and working technical systems, has some stark differences from the engineering manager track, which is the oral, team morale, productivity and delivering on commitments at a high level.

Conor:
Could you go a bit more depth about some of those differentiation points between
that tech lead track and that engineering management track?

Anand:
Absolutely. So I'll present around four signals in terms of how
I have come to think of it and realize. So the first kind of key signal of differentiation is the ability to compromise your amount of technical outputs. So as a tech leader, as a senior engineer, you still might be able to code 60, 70% of your time, excluding any meetings or other kind of admin work related stuff. But as a manager, that could come down really quickly from 0 to 30 and 0 is a real practical possibility. There have been months that I have not been able to code at all just because I'm doing something more critical in terms of collaboration, clarity, alignment, all those strategic exercises and working with the team hands on. So that's the first difference in terms of your direct technical output will be affected. There's a difference in terms of writing code over versus staying technical. You can stay technical. So this is not to discourage folks. You can do peer reviews, participate in mentorship, coaching, technical hurdles, architecture brainstorm sessions. There's a lot you can do in terms of your technical output, but it's not simply that is writing lines of code actually. The other second key signal difference is, are you okay to spend probably half of your time in meetings? Especially in this remote world. Really important in terms of you don't have those hallway conversations, bumping into the kitchen over coffee stuff. So you need to have that meeting time. Again, there are some core meetings that you just simply cannot skip as an engineering manager. And that is just because the more context you get and the more context you provide to cross discipline stake holders, it will keep the team aligned and also moving towards a common goal, actually. So that is that key important difference. Actually, as engineers, you could skip a meeting or two if it's not critical in terms of implementation. But as managers, it's definitely rare. Key stark difference is the definition of success becoming more abstract. It took some time for me to get used to that in terms of, as an engineer, merging my PRA and putting a code solution out, getting something to production, get the dopamine boost at the end of the day. Productivity, success. As a manager, how do I exactly define success? Because I'm not directly doing anything so that's just, in terms of success, is more just there was no conflict this week. Everyone was able to get to their goal and they were not blocked. Actually, there was no questions that came up around, what exactly are we doing or what is our goal for the week? Or all my one on ones are kind of just high morale tracking towards happiness just in these things, for example.

The last key signal difference is around the mindset shift, which is that, to build a point, kind of the last point, that is being a creator, which is an enabler. As a manager, you are probably an enabler that is unblocking the team and your reports actually. So you are enabling the creators on the team. You might not directly be a creator for doing non IC work, actually, and that mindset shift is important in that sense. So these are just kind of really practical signals to help evaluate someone that these should be your motivation factors to go on that track versus the misconception that this is a promotion. This will give me more compensation. I get the authority to hire and fire people. This whole power dynamics thing is probably very traditional orthodox that does not work in today's fast-moving, agile, high-performing teams. So these are kind of the ground realities of these two tracks.

Conor:
I think those are great points because you really have to understand
if you're going to move into an engineering management role, that your entire job is going to change. The topic that you're working on, the code that you're trying to build up, the product you're trying to launch. Those may be the same, but your role is entirely different, and I think it's a great point that this is not like a direct promotion of saying here's the next step. We want you to do something different within that team, we want you to facilitate, we want you to help make other people better instead of trying to be that superstar or goes in and coats everything on your own. What are some of the key things that as a new engineering manager who is trying to make that transition, that mindset change, what should they do or focus on?

Anand:
Yeah, I think as an industry we are making a ton of progress and making training
and peer learning available for new engineering managers. Dev Interrupted and INTERACT is a great example for that. But at the same time, just making sure that you are kind of just being self critical, that your first 90 days are a little make or break situation. The good thing or the upside is you can try this and always go back to being an IC, but at least making sure what are you evaluating or trying against. So I would say two things. Just first, keep in mind in the first 90 days or the first one being building trust and rapport with the team. And this team term is important. As an engineering IC, I had to care about probably the engineers on my team or my engineering division for the most part. Now it is engineering as 50%, QA, DevOps, People Ops, recruiting, product, design. So there are a lot of people that you'll talk to day to day and having that trust on rapport built early on will be super critical. So just work on that kind of relationship and trust equation. Actually, there are some great content out there around that.

The second thing to keep in mind is just trying to be more structured in terms of how you process and share information. So again, in this kind of post-pandemic kind of world with the hybrid culture, it's not that you will be able to have a lot of face time or just kind of go over to someone's desk and see the information. When you are in a meeting in real time, your subconscious mind should work, okay, this information is being discussed. Should I just keep it with me? Should I share it with one person? With the team? In what form? Can I put as an extra item at end of the day? There's just a lot of kind of ad hoc decision making or just kind of that. So just put up method that madness so that it keeps you sane at the end of the day. And it's not that you're always just trying to do little action items in between meetings. So just structure is important in the sense. I think that's probably really it in terms of the two things to keep in mind.

Conor:
I think you're completely on track, though, with the structure, especially, w
here I find that it if there's a lot going on with my team and I'm unable to build that structure in, it's really easy for things to get lost or for me to leave something by the wayside that is potentially crucial, that's key information. Could you maybe give our listeners a checklist of things that engineering managers should be doing during the ironboarding period to make sure that they succeed in that building that structure and the key points?

Anand:
Yeah, I think when we are talking, a lot of these things
that will definitely... Our role will change. The things you need to take care of. It can seem overwhelming. But I think at a high level, things that you could do is, first, is just observe and adapt versus being rigid and imposing. The second thing I would say is build connections and gain trust early on, as we said. And probably the final third thing would be stay technical, but do not spend a lot of time trying to implement technical solutions or be a bottleneck in that sense.

Conor:
Awesome, those are all fantastic learnings.
This has been fantastic. Thank you so much for taking the time to talk with us today and share some of your personal experience and industry learnings. I know there are a lot of folks who are making that transition to engineering manager. They're going to get a lot of value out of this and I'm excited to have you continue to show up in our community and engage with you more in the coming weeks and months.

Anand:
Awesome. Thank you for having me, Conor.
I'm glad we could connect on this topic and I look forward to INTERACT about similar topics and then much more.

Conor:
Look forward to having you back again soon.

Anad:
Absolutely, Conor. It was a pleasure. A
nd it's just so relevant and I'm so happy we're talking about this.

Explore your dev team's metrics in less than 3 mins!

I'm interested