Making The Move from Software Engineer to Engineering Manager

I made this jump roughly one year ago when I went from, "Software Engineering Team Lead" to "Software Engineering Manager." As team lead I had four direct "reports" -- I put reports in quotations because they weren't reports as I've grown to understand them today -- I was basically responsible for ensuring their work was done well and on time. Admittedly, when I made the jump to manager I thought it'd be more of the same but I was wrong. If you're facing the same decision hopefully this will help inform your decision.

Motivation for Becoming a Manager

When considering making this change do your best to identify why you feel this will be a good change for you. If it's just for a pay bump, you probably shouldn't do it. I wanted to make the switch to manager because I thought it was the right move for my career and I wanted a new challenge. In hindsight I still agree with my original premise but I can now see the underlying key factors that drove me to that decision. Two of those factors were imposter syndrome and the prospect of changing things that weren't currently within my power.

The Challenge

My primary known motivation for becoming a manager was the challenge. I had been a software engineer professionally for the six years since I graduated college and to this day software development is my strongest passion. Making the move to manager felt like a challenge because in my opinion being a manager requires a different set of skills on a day-to-day basis when compared to the skills needed to be a software engineer. I felt that becoming a manager would give me the opportunity to hone my verbal and written communication skills and approach problems with a different mindset while gaining a level of maturity I knew I needed.

Imposter Syndrome

Looking back, my primary subconscious motivation was imposter syndrome. If you're not familiar with the term, it's basically that unescapable thought of, "I shouldn't be here. I belong in a dumpster with all of my bad code and bad ideas." Coincidentally, I still have this exact thought at least 100 times per day... Moving on.

I have imposter syndrome because I don't have a CS degree, I have a degree in communication. Early in my career I never gave it much thought. (red-black trees don't come up a lot when you're writing marketing emails for hotel chains) With every move up the software development ladder the imposter syndrome became more real. It reached its pinnacle when I was the lead software engineer with the afore-mentioned direct reports. I now had direct reports with way more engineering knowledge than me who were capable of having entire conversations that I could barely follow. At the time I thought engineering knowledge and throughput were the only things a software engineer could be measured by so I carried around this mild panic that this was it; I had reached the top of my personal ladder. Better go find that dumpster.

Of course, I now know that it takes a lot more than technical skill to be a top engineer but it was impossible for me to decipher that when I only had a view of the smaller picture.

Typically when you read about imposter syndrome the general tone is, "Don't Let Imposter Syndrome Hold You Back!" (and you absolutely shouldn't because its not real) but I find it interesting that imposter syndrome did the opposite for me. Imposter syndrome messed with my head so much it actually propelled me forward. Shoutout to my weird brain.

Management !== Control

Another subconscious motivation for me was the idea of having a bigger voice within that company and using that enhanced voice to fix all the things I had identified as "broken." To be completely honest this is something I still wrestle with, with some regularity but it's something I've been able to better understand over the course of the last year.

As a software engineer you'll always find code, processes, something you don't like and want to change only to find yourself feeling powerless in trying to do so. I'm coping with the hard truth that this feeling never goes away. You'll always find things you don't like that you can't change regardless of your status within an organization. Camille Fournier wrote a great blog post on this topic earlier this year.

As a new manager there are things that you'll get to fix and optimize but it's been my experience that those things are limited to things that affect your team and are contained to your team. The hard part is finding and defining that line. Rarely are there changes to be made that only affect one team or even one organization. Changes that impact other teams or organizations are the things you may want to change the most but these are also the changes that are most difficult to make.

When I first started talking about making the switch into management the CTO of the company asked me to think on it for a few weeks because it was a big decision. I took that time to compare and contrast what I thought management was with what I was doing at the time as an engineer. What it really boiled down to was, "If the pay was the same, which would you rather do for the next five years?" I chose management because I felt it would force me out of my comfort zone and make me a more well-rounded person.

The Switch

So you've taken the plunge into engineering management but now what? It's important to think about what type of manager you want to be, how you'll spend your time and how you'll interact with your team.

Defining Who You Are as a Manager

You need to do this entirely for yourself. Defining your ideals as a manager will help stay focused and stable while doing your job. When thinking about this I defined the manager I would want to have as an engineer. This is what I came up with:

• Transparency and honesty with the team
• A culture of trust
• Understands software development; can mentor the team
• Consistency in mentality and goals
• Maintains a fun, inclusive environment that I want to be a part of
• Fights for the team's best interest

It might just seem like I copied a part of my resumè onto the page but I can assure you I did not. These bullet points are absolutely the manager I want to be but these points can be easy to lose sight of on a daily basis.

Redefining What it Means to Work

I went from a 70/30 time-split in favor of development to a 50/50 split during my first few months, to a 30/70 split thereafter. The 50/50 split was a weird time for me. I felt like I was only being productive 50% of the time as the other 50% were full of meetings, hiring, (we'll cover that another day) and mentorship with the team. I remember telling my manager that I didn't feel like I was doing anything even though I was working into the night. I had to convince myself that there was more to "work" than closing Jira tickets and I felt bad about myself until I was able to make that mentality switch.

Managing a Team You Were Once a Part Of

This is something that can still be tough for me. Becoming the manager of a team you were once a part of has its tradeoffs. On one hand, you've already established a rapport with your team and they (hopefully) already respect you and your ability to lead the team. On the other hand, It's important to understand how your behavior permeates throughout your team.

From one of the bullet points above of what makes a good manager: "Consistency in mentality and goals." This is something I did not do well at first. As an independent contributor I could share my emotions with my fellow team members. If I was frustrated, happy, or otherwise we could share those things with each other. It was harmless. This was something I continued to do when I first became manager but it had a much different effect. Sharing my emotions openly as a manager caused my feelings to spread throughout the team. If I had negative thoughts about a new UI component. The team tended to share that same sentiment.

Over time, I learnt that the best thing for me to do was be a constant for my team and find ways to share my thoughts without portraying positive or negative emotions.

Moving from Software Engineer to Software Engineering Manager is a bigger change than it may seem on the surface. Make sure you understand your motivations for making the change. If you decide to make the change work to understand what your new role means to you and those who will be reporting to you.