How to Stay Technical as an Engineer Manager

Problem

Can a manager stay hands-on and still move up the career ladder? The answer to the question is yes. Transitioning from an engineer to an engineering manager and now as the senior engineering manager was certainly not the easiest path. Dating back, I joined my most recent role as a technical lead, and I had the opportunity to step up and build my team from scratch. Soon I found myself shaking hands with a number of stakeholders who were quite different from my expertise. It was going smooth as we were learning a new trade, going with the flow while observing, but in parallel, I tried to do some self-assessment periodically.

During that time, I could sense myself as Team Blue while losing track, and my percentage on the hands was dropping from what it used to be. Besides, I was more on backend development, which means that building the team and transitioning into leadership roles would lead to full-stack development. I was in full-stack development a long time ago, but I was more into backend development midway through. I realized that my connection with my hands-on skills was getting out of touch with being a manager.

Actions taken

Advancing as a leader means spending more time strategizing, processing, and prioritizing other's tasks. However, I actively participated in the design reviews, particularly on the front-end development. I tried to timebox it and spend a few hours in areas that were new to me. I passively caught up on the code reviews happening on GitHub so that the exchanges happened between the frontend lead and the frontend developer.

It was a completely new experience that I was not comfortable with. However, I wanted to strengthen my skills and grow my leads, so instead, I started to restrict myself on architectures and on that layer but encouraged my backend leads to deal more with the codes. We initiated something on the coding guidelines and stack decisions, which was a place I capitalized on. The position gave me a lot of self-boost and floated around the new area.

I used Tomato Clock, a simple browser extension for managing productivity, for ensuring that I allocated my time correctly. I would be a technical reader on certain days, while on the other days, I would really work on those. It was about getting familiar with the tools and keeping oneself in the loop of learning. Also, since I was passionate about computing, I made sure to bring new DevTools into the team 一 for instance, my introduction of Tabnine into the team got influential among the team members. We needed to look at endless opportunities like this and further look into the multiplier effect.

We also embraced a new set of tools such as CLI tools, networking tools, and API client tools. Being in a suitable developer ecosystem, I started a small channel on Slack as a particular interest group for the Dev productivity tools. It was an attempt to make the engineer's life easier so that they could spend time on solving the core problem rather than the other conditions.

Not to forget that as a manager, another one of the prime responsibilities that we have is to make sure that the team members are getting good work. They should not be stuck up in routine stops. So, I bug bashed with my team members 一 trying to contribute and find the problem that lay within. In this way, I was as participative as them, helping them and keeping myself in the learning process. They were also able to find certain things faster and earlier as I guided them.

Lessons learned

• It is a wiser decision to be a generalist than a specialist when becoming a manager. Try to insulate your team members by being participative during the bug bashes.
• Try to explore the Dev production tools by yourself if you want to get an idea of what to bring to the table.
• Bring new things so that you can learn, and so can your team members.
• The bottom line is, make sure that you have time to learn while you grow.