Exploring the transition from Developer to Engineering Manager
Having begun as an Engineer with my company, Seerene, I transitioned from this role to a position as Engineering Manager some two months ago. This switch came as a welcome change: I had been looking forward to this transition for a while, and I was really excited about taking on the new role.
Just as any individual would when they’re about to start in a new position, I started familiarising myself with blog posts and other literature written by seasoned managers. This quickly reveals a wide range of excellent blog posts waiting to be read, all of which are written by informed individuals, but which also often contradict one other. Oftentimes they’re also just too abstract for my liking. As I embarked upon my role, I came to understand the reasons for the contradictions and abstract accounts, as I noticed the way that the role has a pretty complex set of demands, which different people will embrace in different ways. To add to the discussion, here’s my account of the experience.
Reconciling difference
Developers’ personalities tend to get stereotyped pretty often, and it’s of no great surprise that you often see the words ‘Develop Empathy’ at the top of the list in blog posts discussing the qualities of good engineering managers. Thankfully, this has never been a problem for me, and I find that most of the developers in my team defy the common perception that developers prefer to work in a basement with as little social interaction as humanly possible and also tend to thrive in social situations. However, the stereotype can hold some truth, and reflecting upon it helped me understand something valuable: the vast diaspora of developers’ personalities also means that we have vastly different strengths and weaknesses. Putting together a successful team means balancing between modes of thinking, interests, and levels of skill, and I now find myself keeping this well in mind as I pursue my role.
Defining influence
One of the more difficult aspects of the transition came with the actual issues that I had to address, as being a manager presents a new variety of problems to those that you tend to face as an engineer. I tend to find that solving a complex issue is one of the main ways that good engineers derive satisfaction from their job, where you move through a process of fighting with the tools being used, understanding the code, and finally getting that pull request approved and merged. The cherry on top is being able to move that ticket(s) to Approved, and then, finally, Done.
As with any profession, there always needs to be a sense of accomplishment for an individual to get joy from the work; one of the most tangible ways for an engineer to gain this feeling is to move that task to Completed and check it off, a feeling that can even become quite addictive. The story is a little different for managers, who often deal with on-going tasks and issues without a tangible end. This has been quite difficult for me to get used to, as not only do I miss that sense of accomplishment, but I miss being able to pick apart and explain every single technical detail of a project. Moving beyond this frustration tends to come with being in a position that allows you to see how every single of the completed tasks comes together to form a coherent whole, which ultimately grants success for the team.
Social awareness
Being a good manager also has a strong social element to it, and it’s essential to spend time with your developers both individually and as a team. This could be as one-on-ones, as technical discussions, or having a relaxed beer together at the end of the day. Having had my fair share of bad managers, I was very cognizant of one my managerial pet peeves, which was asking for updates multiple times a day, especially when there was a hard deadline around the corner. One of the more popular tokens of advice you get as a manager is to be able to remove obstacles in the developers’ way, but to get out of their way yourself too. In moving beyond this challenge, it’s important to establish bite-size milestones that you can use to identify impediments or updates without being caught off guard.
A change in mentality
The final, and perhaps most important element of transitioning to an engineering manager comes with extending trust to your developers: while I am involved with and occasionally drive the engineering discussions, I find that my developers know best as the project progresses and we reach the finer details of implementation. Having previously been an engineer, surrendering my desire to learn everything I can about the problem, contribute to it and drive it into the ground can feel like having a bad itch. Instead of running away with this desire, I find that I must prioritise my primary responsibility as a manager is to empower my engineers to solve the problem, and ultimately create a culture where I hope that they can feel the same itch. Inspiring this kind of energy in a team promises that tasks will be taken to their rightful end, and that imaginative solutions will be found to the obstacles.
Although I love this part of my job as I observe how a team of developers comes together to combine their effort to create success, I still have the lingering thought that I am unable to offer the same degree of individual influence on a project in my new position. Evolving your own idea of yourself as a professional individual can be a complex process, but it is exactly this that also makes me acknowledge that becoming used to my new sphere of influence is also a deeply important part of the transition. This is interesting to keep as a more long-term goal, and I look forward to perhaps reflecting in a few months’ time and being able to acknowledge how I’ve managed to shift my perception of how I define having a positive influence. This finally reflects how transitioning from developer to engineering manager involves spreading your awareness from your own work to how everybody’s work combines, and resting on the idea that every successful team consists of a jigsaw of different individuals.
