Prepare yourself for the transition first
Several years ago, an opportunity opened up to become a manager on my team.
The team had grown to a point where my manager needed additional help, and he would split off some of his direct reports.
The search for a new manager on the team was relatively sudden, and while I had previously spoken with my manager about potentially taking the management track, I had not given it much serious thought.
At that time, I was working as a senior engineer in big tech and debated whether I should take the time to go through the interviewing process with other senior managers in the org.
Of the two senior managers interviewing me, I had worked with one before (he was the manager of the PM on my team) and not the other. Ultimately, I went through the process and learned much about the expectations of the role.
For example, one of the managers highlighted how important the people aspect of the manager role was. The importance of people is obvious now, but not necessarily at the time. I felt that my manager then spent most of his time coordinating with other teams and changing the team’s processes.
Looking back, I am sure he had to deal with many issues behind the scenes regarding personnel. As I learned by talking to other managers, this is one area that surprises many new managers.
Regarding learning from other managers, I spoke with other managers that had recently transitioned from engineers. They gave me insight into their new roles and how they handle them; I will incorporate these insights into my learnings below.
After debriefing with my manager about the feedback from the senior managers, he and I decided that this was not the right time to transition.
Looking back, I am glad I did not jump at this opportunity. I could have been slightly less honest about my hesitation with the two senior managers I was interviewing and potentially landed the new manager position.
However, I knew I could count on the manager I had previously worked with to understand my concerns and provide guidance.
Instead, I took the time to understand the different aspects that would be different for the engineering manager role. Depending on your company, this could be slightly different or have little overlapping responsibility between engineer and manager.
I also have the power of hindsight because I have since worked as an engineering manager at a startup for over a year. From my experience, I found three areas that I had to focus on as an engineering manager: technical guidance, project (and sometimes product) management, and people management.
Most importantly, the approach to these areas differed significantly from when I was an engineer. Again, depending on your company, the engineering manager role may contain all three or other responsibilities.
Many engineering managers were technical at one point in their career, usually at the beginning. However, the expertise of these managers differ greatly, and rarely did they have the expertise of a staff engineer.
At a large company, it is easy to lose sight of what the engineers’ struggles might be if the manager is new to the company and is never expected to contribute to the code base.
From my experience, the engineering manager does not need to be as technical as the tech lead but enough to empathize with or question the team if things are not going as planned. In a pinch, the engineering manager should be able to debug issues with the team.
The engineering manager should also understand the team’s technical direction and work with the technology lead to balance the business requirements if the two are in contention.
On some teams, the engineering manager is also the most technical, but in my experience, this only works at smaller companies as there are too many things that “come up” in a larger (public) company, and the bottlenecks need to be split up.
Regarding project management, I have seen very different approaches. Some companies have designated Scrum Masters, and others may have project managers. They often go through a CSM or PMP course and get certified for these roles.
From my experience, these certifications do little to improve the team’s process. Many of these professionals’ recommendations are too theoretical and often fall short of the group’s needs.
Instead, I found that the engineering manager or an engineer passionate about the process of working with an agile coach can generate an agile approach most suited for the team. This also includes how to work with other teams, both within and outside the organization.
I was glad I took the time in my last few years as an engineer to go through the task of setting up the agile process for a brand-new team, along with continuing to work on cross-team projects.
Setting up these processes helped me become an experienced Scrum Master without needing to get certified, and I could transfer different parts of this learning to new teams.
Often, the engineering manager would have the insight to know what agile processes work on their team. Forcing the team into agile “best practices” when it doesn’t work causes friction and frustration in the group. For smaller companies without a designated product team, helping shape the product with the CEO, sales, etc., can also fall under the engineering manager.
The importance of people is obvious now, but not necessarily at the time [when I first considered a manager role].
The people aspect is the last area, which for most is also the most challenging. In this article, I will include coaching/mentoring, team alignment, resolving people conflicts, and morale.
A good start is to understand your management style. Discovering this is why many new manager training sessions and MBA programs go through different personality tests, hoping to find a blueprint for different management styles.
However, in my experience, it goes much deeper than that; the manager has to figure out their strengths and weaknesses in relation to their reports. For myself, I was prepared to take on the coaching and mentoring aspect. I was a mentor for several years at my alma mater mentoring two students per year.
I also took on the responsibility of coaching more junior engineers, setting up regular 1:1s, and working through problems together. I often would not know the solution or even the code, as different team members might work on various projects.
These situations helped my ability to coach without knowing the answer, which is essential when giving guidance when dealing with many reports. There are no silver bullets for people’s conflicts, but thinking about different solutions and consulting your manager will help get to the most appropriate solution for the situation.
The area I found most difficult was aligning the team. Often, this issue is compounded when team members like to jump on the thing that most recently came from senior management, whether it is urgent or not. One way to get around this is to find a way to set stricter processes around what goes into your agile board during a sprint.
Other times it is reminding the team what the sprint goal is during stand-up more often. A team that is not aligned reflects poorly on everyone as velocity slows and features always get delayed.
Still, the person most expected to solve this is usually the engineering manager. Reducing the work in progress also helps, as suggested by the kanban methodology, but this may not be possible depending on the company’s priorities and the number of ongoing fires.
I found three areas that I had to focus on as an engineering manager: technical guidance, project (and sometimes product) management, and people management.
If the next time you consider becoming a manager is your first time, take the opportunity to observe what your manager does day to day. Talk to other managers (preferably in your organization) that are relatively new in their role, and see their pros and cons.
The most challenging aspect of being a new manager will be different for everyone. One of the first goals should be to figure out what that could be for you, and there are plenty of management books for that. Another way is to see if your company offers training for new managers and see if you can take those training before making a final decision to transition or not.
Many individual contributors (IC) in tech do not get promoted to the next level until they are already performing at that level. However, the transition to manager rarely uses the same approach; Many high-performing engineers are thrown into the deep end with minimal guidance.
It’s no wonder that many managers who were strong engineers transitioned back to ICs within a year. The help provided to transition at many companies is improving, but you still have to do the work yourself to put yourself in the best position to succeed. I am glad my transition was gradual, and it put me in a position to learn as I took over more managerial tasks without feeling disoriented or overwhelmed.
This transition worked for me, and I hope you find one that works for you.