This post was first published on CoderHood as From Coding to Management to Leadership. CoderHood is a blog dedicated to the human dimension of software engineering.

Management is not for everyone.

The skills required to code and the skills needed to manage people are very different. Being a good manager is also not the same as being a good leader. Moreover, being a good manager of developers requires being able to think like a developer.

Most engineering managers start as developers, writing code full-time. At some point in their career, they reach a fork in the road. The sign pointing straight ahead says, "technical path," and the one on the left says, "management path."

The straight path continues through a familiar technical landscape. In this direction, most problems are solvable logically and intellectually, with tools and systems built to help. The biggest challenge on the technical path is keeping relevant with the time. Technology changes at an impressive speed, and staying still is a death sentence.

The other path is scary and uncharted. It still requires technical skills, but at a higher level compared to the purely technical track. When you take this road, interactions with people become an important part of the job.

People are complicated, they don't follow defined patterns, and do not always work in logical ways. Emotions, personalities, personal situations, fears, health and many other factors enter the picture in a complex ecosystem that cannot be analyzed with tools. Taking this path does not mean adding new responsibilities to the old job. It is a new job altogether.

Software developers take the left path for one of two reasons. Sometimes they are pushed into it by their boss. Other times, they see an opportunity and choose to take it.

Why are developers asked to manage?

There are many reasons why developers are asked to manage other developers. Every situation is a little different, but I am going to give you three common reasons.

Reason #1 -- To open up career advancement options.

In some organizations, the technical career track comes to an end sooner than the management track. For example, a developer can progress to Principal Engineer, while a manager can go up to CTO. In those organizations, a developer who is not interested or capable of managing people runs into a role-wall.

If a developer is skilled and is regularly promoted, their manager sooner or later faces a dilemma. What to do with them? How to recognize their contributions and increase their responsibilities if there are no more promotions available in the technical track? There are a few common answers to that question:

1. Create new titles. That's how honorary titles such as "Fellow Developer" and "Distinguished Developer" are born. Promotions are typically associated with generous salary increases. Having more levels to grow exceptional talent is an avenue to recognize experience, achievements, and influence radius, along with giving hefty compensation increases.
2. Move them to management. A developer who moves to management gains access to titles that typically require management of people. For example, positions at the Director, VP or C-suite levels are often associated with the direct management of individuals.
3. Give them more high-level technical responsibilities such as Architecture or technical ownership of projects. Those extra duties might or might not be associated with a title change.
4. Provide opportunities for lateral moves within the organization. That could include moving to a different engineering department, or a different unit altogether.

Reason #2 -- To scale the organization, growing leadership from within.

Typically a single manager can have up to seven direct reports. During times of growth, hiring new people requires finding new managers to scale the organization. The best managers are promoted from within the organization, and for that reason, leadership is keen to develop existing engineers to management roles.

For example, an engineering organization with up to eight people requires one level of management, that is one manager and seven individual contributors. Organizations between 8 and 57 people need at least two levels of management, that is up to 8 managers and 49 individual contributors. Organizations between 58 and 393 people require at least three tiers of management, that is up to 50 managers and 343 individual contributors.

Some organizations have much flatter org structures, but that requires each manager to have many direct reports. For example, Google is notorious to have engineering managers with anywhere between 7 and 25 direct reports. Google is also famous for having engineering managers very distant from their direct reports, barely knowing who they are, what they are doing and how they are performing.

Since software development organizations tend to grow fast, management opportunities are not rare. In theory, every time seven new engineers are hired, a management position opens. What is rare is for developers to have the skills required to be managers and for leadership to know how to train new managers into their role. Not everyone can, want or should be a manager.

Reason #3 -- To allow for reorganizations without having to hire more managers.

Engineering departments reorganize all the time, even if they are not growing. During the shuffle some people are promoted, teams split or merge, and reporting structures shift. In the process, managers end up with too many direct reports and the need for new leadership becomes clear. At that point the need is acute, and there is not a lot of time to hire new managers. That's when, often, developers are promoted to management to fill the gaps.

Why some developers choose to go into management?

Writing code is fun, and it keeps being fun for a long time. Some developers would never want to do anything else, and probably never will. Others would like to code forever, but they also want to scale their efforts and run their team. A few want to run entire engineering organizations, abandoning full-time coding altogether.

I started by being part of the first group. I often ended up in technical leadership positions, and eventually accepted a hands-on management role. At the time I wasn't in the right organization, and I didn't like the experience. I had no support nor mentorship and hated it. Years later something switched in my brain, and I knew that I wanted to scale my area of influence. I jumped on an opportunity, and I have been thrilled in my new role ever since. Today I still code, but not often, and I do not miss it.

My transformation from full-time coder to manager, and eventually to manager of managers, took many years. It wasn't easy to understand and start feeling that leading teams have great value. My output is no longer measured by the amount or the quality of code and systems I write and design. It is measured by the amount and quality of code and systems my organization writes and designs, and by the quality of its culture.

My job has shifted from writing code to providing the ideal environment for others to write code. It takes all the experience I accumulated in 30 years of software development to be effective in my role. On top of that, I have to learn how to interact with people, mentor them, coach them and get out of their way so that they can do their best work.

That is my story, but there are many others.

Engineers choose to manage other engineers for different reasons. Here are some of the most common ones:

1. To scale the area of influence. Managing people increases the radius of influence from one person (yourself) to many. You don't have to manage people to be an influencer, but influencers often end up managing people.
2. To improve as a leader. Leadership and management are very different things, but being a manager gives opportunities to practice leadership.
3. To gain access to Director, VP and CTO/CIO positions. If titles are important to you, or if the job description of a Director, VP or CTO/CIO are what you are after, management experience is most likely necessary to get there. Moving to a hands-on engineering management role provides the platform to learn if management is right for you.
4. To get out of the weeds. At some point in their careers, developers sometimes start feeling the need to get out of the details and start thinking about software in broader strokes. For example, in recent years I stopped thinking about software as an execution of instructions and algorithms, and more as data flow and manipulation systems. When you start managing developers you often become involved with the high-level view of the systems your teams are building, and less at the code level. That new vantage point can be refreshing for some.
5. To work more with people and less with technology. Management and leadership are very different roles than writing code. They need an intense focus on people who create technology and not the technology itself. The types of problems a manager has to deal with are often fuzzy and nuanced by human factors. There is no debugger for humans. Not yet, at least.
6. To make more money (often only a perception). This point depends greatly on the organization and the pay structure. That engineering managers make more than developers is more of an assumption people make than a rule. In general, compensation is based on the area of influence and responsibility. Under that lens, being a manager should be associated with more money. However, there are many exceptions. It is not rare in tech for a software developer to make more money than his or her boss.

Conclusions

If you are a developer in a scaling software organization, you will be asked, sooner or later, if you are interested in management. Do not take that path if you are not sure why you want to do it. Also, do not take it if you are not planning on giving your all to your prospective employees. Nobody seeks to have a manager who is managing them as a career experiment. People want to have a manager who cares and is going to work hard to create the best possible environment for them to thrive.

Management does not give you control. It only gives you an opportunity to prove to your staff that you can be a good leader and career guide. If you can't prove it, your employees will not let you lead. A leader can only exist if his people allow him or her to do so.

Before taking a management role, make sure to...

1. Know what you want. Do not accept to manage people just to try it. Would you want to have a boss who is "experimenting" with you?
2. Understand that management is a different job. It is not "coding with some extra management stuff on the side."
3. Know that you need to be a leader, not just a manager. Management is one of the things you need to do; leadership is how you do it well. Look at it this way: managing is like knowing the syntax of a language, and leading is like knowing how to write the algorithms, solve problems, structure your code and design systems.
4. Understand the value of a manager. If you believe that management is overhead, you shouldn't take a management job.
5. Decide how you are going to measure your performance. How will you measure yourself as a manager? How will your boss measure you?
6. Be sincerely interested in people and their career aspirations. If people annoy you, if you want to have the last word on disagreements, or if you are seeking authority, you should not be a manager.
7. Develop your soft skills. Being a good developer is not enough.
8. Have a mentor;Â ideally your boss. The last thing you want is to acquire a title bigger than you with no plan, direction or anyone to help you grow in your role.

If you enjoyed this article, keep in touch!

• Find all my posts on CoderHood.
• Join my professional network on LinkedIn.
• Follow me on Twitter.
• Join my Facebook page.
• And finally, follow me here on dev.to!