Transitioning to manager position
You become a developer because you love coding and the whole process of turning ideas into code. Building something out of nothing. Learning new technologies, programming languages, frameworks, etc. Figuring out how things work. You have been enjoying everything you do.
Now, if you are good at what you do, or you exhibit managerial abilities, or there is simply nobody more suitable in your team, you may be asked to become a manager. The common thought at this point is that “Becoming a manager would be a natural progression”. I would like to argue that this is not always natural, and you should not be forced to do something you do not want to do.
Why is it not natural
If you take a person who loves coding and turn them into someone who does not code, what is the logic there? They will start feeling disconnected from their passion, and eventually burn out and start hating their job. If they still code, it means that their managerial duties are not being done. That is not good for the business. Why would you have a manager if they do not manage?
If a person is a good coder, it does not automatically mean they will be a good manager. Development and management are two different types of jobs, both requiring specific skills and mind sets. It is similar to football players and football-team managers. Developer is more of an individual contributor. You should be a manager if you enjoy getting work done through other people instead of doing it by yourself. Also, you should consider your social side first. If you are not a social person, you may not necessarily be good at management. Also, if a person has trouble taking care of themselves, do you think they will be good at taking care of others?
People in a hierarchy tend to be promoted based on their past experience until they reach a position they are incompetent to do (Peter principle). Thus, a good developer gets promoted to a manager, and if they are not prepared for that, they will be unable to do their work. If a developer is not acting like a manager, do not promote them to one.
Some people take a managerial position for the extra money. While it is true that managers often earn more than their subordinates, this does not have to be necessarily always the case. If you have a group of specialists and a manager to manage them, why would the manager need to earn more if the experts are very hard to replace? A good manager does not necessarily have to be a good developer. If you enjoy what you do (development), earning less could be a better option than being a manager earning more but feeling miserable and hating your job.
Do not take a managerial position only because there is nobody else in your team to do that. This is not your fault. You should choose your career path consciously. Otherwise, not only you will get harmed, but also the company.
Other possibilities
There are generally two career paths (ladders if you will): a managerial one and a technical one.
Senior/Principal Developer – This can be a career position at which you want to stay. It is perfectly normal to have solid Senior/Principal developers who are happy being individual contributors, and do not want to move to management or general architecture.
Lead Developer (Technical Lead) – A semi-managerial role. Lead Developers lead projects and people purely from the technical viewpoint. They do not have direct reports and do not boss people around; they lead by gravitas. They generally act as a final judge of code aspects. However, your mileage may vary as their job description differs from company to company.
Architect – If you are good at and enjoy designing complex systems and want to stay on the technical track. Technical architects are often considered the highest position on the technical career ladder. Their job descriptions also vary a lot, even to the point that some Architects do not write any code (which can be considered an anti-pattern).
Manager qualities
The most important activity for management success is being a good mentor. Successful managers know how to mentor their teams to success.
The least important is technical skills. This proves that a great developer doesn’t necessarily make a great manager.
Last updated
Was this helpful?