This article was written exclusively for devinterrupted.com by Anand Safi
.
.
.
In my role as an engineering manager, I know making the leap from an individual contributor (IC) to engineering manager (EM) is not a promotion. Instead, it’s a different career track. What we are discussing here is a fundamental difference in terms of the responsibilities of the roles. What you do as an engineering manager versus what you do as a developer is fundamentally different. There is a possibility that you might not write code altogether. A promotion means continuing to do the same thing, while being paid more to do it. Becoming an engineering manager means transitioning to a different role with different responsibilities. In other words, a separate career track.
First, let’s break down our target audience into two groups. One group who is transitioning into engineering management. And then, the second, folks who have been made engineering managers recently. For those who are still considering, this decision could be made due to a couple of factors. It could be tenure-based, it happens in many companies where you are the senior-most engineer, or you have spent a fixed amount of time. The company or the team believes that you’re ready for managerial responsibilities, asking you to make the switch. This is a more traditional track that we see. Alternatively, there’s a more interest-based approach that you could be even at a mid to senior software engineer level.
An important clarification with this is when to use the term “tech lead” and “engineering manager” interchangeably. The Tech Lead is a system owner, and the Engineering Manager is more of a team/people manager equally. So the former is responsible for the overall success of the architecture while the latter is responsible for the team success, motivation and morale of the people they manage.
There are some key signals regarding both the tracks (IC & EM) to be aware about. They are:
1. Amount of coding time
Are you able to compromise on the technical output that you will end up with as an engineering manager versus a strong engineering IC? If you are coding 60 to 70% of your time currently, let’s say it’s going to reduce to 0 to 30% of the time. Yes! ZERO is a reality in this case. I have spent months where I’m literally not doing any coding in my role. There are EMs out there who would say they are able to still do coding and remain technical in terms of writing code day in, day out with an EM role. But, honestly, I don’t believe that is a scalable practice.
If you are still taking on critical hands-on development tasks as an engineering manager, you run the risk of becoming a bottleneck for your team. For instance, if you are not available during the week, you need to do a lot of performance reviews or you are in some strategy meeting.
2. Focus time vs meeting time
Are you okay with spending 50–75% of your time in meetings and tackling action items? If a company is in a hiring mode or if there is a performance review season, or if there is just any ad hoc conflict that comes up, or mentorship in your one-on-ones with direct reports, there are many meetings/commitments. This is especially true now with remote culture and distributed teams. The amount of context needed to succeed in this role is quite high.
3. Definition of success
Are you okay with the definition of success becoming vague? What I mean by that is, as an engineer and an individual contributor, there were days where my code would pass, I would complete the feature, the build was great, I would get a dopamine boost at the end of the day and I could say, “Wow, it’s a productive day!” Basically, I could see clear output as an engineer when I completed a task, or my work was released.
As an engineering manager, it’s difficult to define what success looks like for you personally, because there are no metrics which tie to individual engineering management. For an engineer, it is lines of code or the amount of work you completed, features you pushed, zero bugs introduced. All those things are great success indicators for a strong engineer.
For an engineering manager, you must find your own metric set of what success is, which is ‘maybe there was no conflict in the team this week’, ‘maybe there was no deadline that was missed this week’, ‘maybe there is no question in terms of the meeting’ that I had with the stakeholders, and everybody clearly understood the requirements that were there for that week. Overall, it becomes abstract, and you need to self-identify what success looks like.
4. Being an enabler, not a creator
Are you okay with the mindset of being an enabler versus a creator? As an engineer, an individual contributor, you have dedicated time to implement features. It’s your job to create things. However, as an engineering manager, you are responsible for enabling the creators to do their job. So, you are unblocking the team, you are giving clarity to the stakeholders, you are giving clarity to the team, you are providing updates to the leadership, you are sharing updates with other teams. Thus, you are enabling a lot of information sharing and removing bottlenecks for your teams and team members.
For me, it’s clear that the engineering management and leadership track is a parallel career ladder on a separate track. It is a lateral move in that sense. It’s not a vertical move and it’s important to know the difference. The good part? In my experience, it is worth attempting to become an engineering manager because if it doesn’t suit you, you can always go back to being an individual contributor.
If you haven't already heard, Dev Interrupted is partnering with Dzone to host INTERACT: An interactive, community-driven, digital conference on September 30th - by engineering leaders, for engineering leaders. 1 day, 10 speakers, 100s of engineers and engineering leaders, all free.
Register Now
Join the Dev Interrupted Community
If you haven’t already joined the best developer discord out there, WYD?
Look, I know we talk about it a lot but we love our developer discord community. With over 1600 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>
Originally published at https://devinterrupted.com on September 17, 2021.
Top comments (2)
I very much enjoy his point about being an enabler, not a creator. IMO one of the most difficult switches to management is lack of opportunity to create features. You just have to relent and let your team get to the business of actual creation.
I appreciate his candor. Management is a different beast altogether. Good on him for being open about it.