As you, a software engineer, progress in your career, there may come a time when a management position is an option for you. This might seem very enticing and is often viewed as a promotion, but it isn’t. It’s a track change from an individual contributor to management and encompasses various new tasks requiring different skills than the ones you used to get there.
Considering these two roles are so different, is being a manager really something for you? Would you like to spend most of your work time communicating with other people? How can you avoid being a bad manager?
In short, you can’t answer these questions just by thinking about them. There are many factors involved and most situations are unique. The best way to get the answers is to try it out. This decision is also reversible.
As a matter of fact, even just trying management makes you a better software engineer. You will learn how your manager thinks, what their goals are and how they communicate with upper management as well as people inside your team to list a few.
As Steve Jobs said in one interview:
You know who the best managers are? They’re the great individual contributors who never, ever want to be a manager, but decide they want to be a manager, because no one else is going to be able to do as good a job as them.
I’m Viktor and I’ve recently switched from an Android Engineer to an Engineering Manager position in one of our product teams in Babbel. My work mainly consists of managing 7 engineers, product discovery, aligning with other colleagues and a lot of communication.
Several people have reached out to me about this switch, so I have decided to summarize some common concerns and questions. This post will not glorify management, as it’s not better or worse than programming, but simply different.
Missing coding
Missing coding is one of the most common concerns engineers have when thinking about switching to management. And it’s a valid concern as coding was the main part of your job until now, but will be little to none going forward. What will happen after such a drastic change? Would you still enjoy going to work?
First of all, you are not giving up on coding completely. You probably have side projects and are always tinkering on something in your free time. You are giving up doing this as your day job. This way, coding becomes a hobby that you can look forward to in your free time, where there are no time constraints or restrictions, and no considerations of what and when the PM wants to ship.
You should also think about what part of coding you like the most. Is it the abstract problem-solving? Finding elegant solutions in your preferred language or framework? The instant feedback when your code works? Or perhaps something else entirely?
Some aspects of programming have parallels in management and others are the complete opposite. For example, you still use abstract problem-solving when you need to imagine how software might work on a high level, so that you can properly explain it to the PMs, Designers and others.
On the other side, the language and framework constraints are gone as your main medium is now spoken and written language, which is notorious for ambiguity and misinterpretations. Also, you may work with people that might come from different cultures and have varying previous experiences and seniority levels. Making sure everybody has access to information they need and actually understanding it, is a problem no one has solved.
The same goes for instant feedback after you compile and deploy your code. This exact moment and its associated feeling will be gone. Your feedback loop is now a lot longer, as the output of the engineers and actually moving the company metrics is what you are chasing. You can only properly know if you are on the right track after a few days, weeks or even months.
However, you do receive instant feedback by talking and listening to people, which might be similar to the one described above. Yet, when writing code you get a boolean feedback as to whether it works or not, while with people, you try to interpret their words, putting them on a scale where the ticks or borders are not defined.
It’s not a promotion
Have you heard of Peter Principle?
The Peter Principle states that a person who is competent at their job will earn a promotion to a position that requires different skills. If the promoted person lacks the skills required for the new role, they will be incompetent at the new level, and will not be promoted again.
It summarizes why switching from a software engineer to a manager is not a promotion. And how the word promotion is often used inaccurately. The latter requires different skills and encompasses vastly different tasks than the former. If you are a great software engineer there is no guarantee that you will be a great manager.
Being good at writing code doesn’t mean you can do proper stakeholder management. Onboarding a new hire doesn’t mean you can do people management, goal setting, conflict avoidance and resolutions. You might have done some of these things before, but now you are responsible for judging complex situations and resolving problems, while trying to make your stakeholders happy.
As a promotion is often linked to salary, many companies are compensating some of their engineers higher than their managers to highlight that this is not a promotion. This also removes money from the equation.
Moving into management makes sense if you would like to do something different from coding. There are two main differences. Firstly, communicating with people to solve never-ending problems and find results you don’t know you are looking for. And secondly, there is a ton of ambiguity and very little focus time, which is the opposite of what you’ve been doing until now.
A note on Peter’s principle: Being an Engineering Manager is also the last position where you will work inside a Product Team. A further promotion means you would manage managers and thus have a very different daily work than before. Their jobs have even less in common to your current position.
Good fit if you like these things:
There are some general rules of thumb that you can follow to make sure the transition is smooth and your expectations are set properly. This is not an exhaustive list at all.
Self Management
Big part of being an Engineering Manager is deciding what you should do next. You will need to evaluate different opportunities and make decisions based on uncertain paths and outcomes. Planning focus time to get work done is going to play a key role, while always being flexible for unexpected urgent topics. Nobody can tell you how to do all this, because every situation is different and only you have all the information needed to make the best decision.
People management
Helping people succeed is your main goal as a people manager. This requires a lot of communication, figuring out how every individual works and what their goals are. You should be an enabler for them, which requires documenting progress, setting milestones and copious amounts of administrative work. It’s also a very responsible job as you are directly impacting people’s lives as their manager. This can be very rewarding, but also a heavy burden, making the job quite stressful.
Talking and meetings
As you move away from actually writing code, you don’t stop thinking like a programmer. You just start talking about how code works, rather than writing it. And the talking continues depending on your exact responsibilities. Communication is paramount as an Engineering Manager. You will be a translator between various stakeholders and making sure information is properly transmitted, and more importantly, comprehended. There are no clear answers when deciding who to involve and what information to give them. These are all decisions you have to make.
Making decisions
With you being in a managerial position, you will receive a vast amount of information from different sources. And for everything you don’t know personally, you will need to know who to ask. This is important because you will need to make a lot of decisions, often with no clear right option. Therefore, you need to be comfortable with the ambiguity and consequences. Mistakes are going to be made and it’s important to extract proper learnings from them, so that the right path forward is found. And this can only be done if you accordingly analyze what happened and decode the underlying reasons. And remember, in hindsight everything is always clearer, but this is a bias, so don’t stress about it too much.
Final thoughts
As with most (big) decisions, you won’t know before you try. Because you are working with people and the exact job requirements might change depending on your workplace and team focus, it’s hard to know in advance.
If possible, start slowly by taking on some responsibilities from your current manager. This would make their job easier, while giving you a good stepping stone to try it out. The responsibilities can increase as you progress and help build your idea of what the new position would look like.
Talking to others about your concerns and thoughts is a convenient way of addressing some worries you might be having. These people could be your manager, other managers or people on the internet that are in a similar situation. Sharing your expectations and doubts can help visualize them and observe them from a different perspective, thus making this decision easier.
In this post, I made it clear that switching from a Software Engineer to an Engineering Manager is not a promotion, but a track change that requires very different skill sets. The exact job requirements and tasks will always vary from company to company and making a cookie cutter decision is impossible.