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:
- 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.
- 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.
- 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.
- 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:
- 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.
- To improve as a leader. Leadership and management are very different things, but being a manager gives opportunities to practice leadership.
- 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.
- 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.
- 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.
- 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...
- 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?
- Understand that management is a different job. It is not "coding with some extra management stuff on the side."
- 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.
- Understand the value of a manager. If you believe that management is overhead, you shouldn't take a management job.
- Decide how you are going to measure your performance. How will you measure yourself as a manager? How will your boss measure you?
- 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.
- Develop your soft skills. Being a good developer is not enough.
- 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!
Top comments (19)
Great post, Lorenzo. Thanks for your work. I agree with almost everything. I have one comment and one question:
My comment: You conflate management and leadership, like leadership is somehow the progression path of the manager. This is actually quite common (a lot of others do it), but I don't think it's accurate. I think leadership and management are very different things, and few people excel at both.
Personally, I like the definitions by Marcus Buckingham: A manager is a coach who brings out the best in her people. Her focus is on each individual. A leader is a visionary who rallies people around her idea of the future - be this the future of a product, or a company. Her focus is towards the outside, and towards the future.
Ultimately, it is a matter of how you define leadership, so it's always a bit random. However, I find the definition you have given a bit unsatisfying. If a manager becomes better and better at his job, this does not necessarily mean that we need a new name/title for him: "Now you are not a manager any more, but you are a leader!"
After all: When a developer progresses, and accomplishes what you describe above ("knowing how to write the algorithms, solve problems, structure your code and design systems"), do you invent a new title for him, as well? "Now you are not a developer any more, but you are a ... senior developer? Ninja?"
That was my comment.
My question: You ask the aspiring manager to decide how they would measure their performance. I'm curious: How would you, or do you, measure it?
Thank you for your very thoughtful comment.
There is much that could be discussed about the difference between management and leadership and it does come down to definitions, as you said. I used to see it the way you define it, but I changed my view a few years ago. I love the way Max Depree talks about it in his book “Leadership is an art”. He says “The first responsibility of a leader is to define reality. The last is to say thank you. In between, the leader is a servant.”
In the long term, I measure my performance by measuring the impact of my efforts. The impact is the delta between what happened because of me vs. what would have happened if I was not there.
In the short term (daily) I measure it by asking myself if I made a difference to people and/or the organization, that day.
Putting "Leadership is an art" on my reading list, thanks :-)
About measuring your impact, or productivity, as a manager: I wrote Recalibrate Your Productivity Sensors some time ago, maybe you find it helpful. It talks about how, as a manager, most of the metrics of productivity you had as a developer just go away, and you have to find new ones. I think it arrives at a similar conclusion as you do: Make a difference to people and the organization. Unblock, teach, listen, encourage, give feedback, bounce ideas back and forth, etc.
Great post
Thank you! It is a pleasure to post on dev.to. Thank you for creating this community and for making it so open and welcoming to contributions.
Thanks for making the most of it!
Great post, thank you. I'm just recently finding myself at the leadership/technical fork in the road and unsure of where I want to end up, and this post has helped clarify some things for me.
For those without management experience, are there any resources that you can recommend?
Here are some great books that are a great starting point:
However, the best resource you can have is a strong mentor. Here are some notes on how to find one.
Hope this helps :)
Great, thank you for these.
Adam, I would like to add The Manager's Path to Lorenzo's list of books. It's very actionable, concise, and practically relevant.
This looks like an excellent resource, thank you.
I just wanted to follow up on this by saying I've read the book through and it's an excellent, enlightening read. Thanks again!
I'm glad to hear that. Thanks for getting back to me :-)
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.
Thanks for great post.
I just got a position as development manager, i want to lean how to interact with people, mentoring, team leading in better way.
What should i do? Should i join a course?
What did you do learn all this?
There isn't a silver bullet, but there are many things you can do.
What I did:
1) I realized that being a development manager is a different job than being a developer. Depending on your level, you can still code, but priority must be given to people (not code).
2) I read everything I could about leadership, emotional intelligence, effective communication, personal interactions, etc.
3) I had a great mentor. Having a strong mentor to brainstorm situations and learn "how to think" on a daily basis is a great thing.
4) Experience. As for everything, you need practice. You get better as you go.
Just like coding, leadership is a journey, not a destination.
I find myself heading down the technical path (which is difficult... many organizations setup management as the only real advancement path). But I don't agree with your characterization... technical is a hard, scary path too. As a technical lead, the problems I need to solve often have no obvious answer. Usually the key to finding the "right" way is seeing the issue from as many perspectives as I can. IOW, picking the most optimal trade-offs for all parties concerned. And this is a shifting target. It is a large responsibility, and often even my spare time is focused on research. Being a technical lead requires you to be business-aware and people-aware, but primarily for being able to translate these concerns into technical qualities of the software / operations.
Leading on the technical path requires soft skills too. Often my day is mostly spent mentoring or helping people work through problems they are stuck on. Usually we just talk it through, but sometimes pairing is involved. From time to time, I need to talk with customers and stakeholders to try to understand the goals behind their feature requests. I also have user stories to finish, often ones related to architecture (e.g. implement optimistic concurrency so I can go with fully stateless services, enable blue-green deployments, etc) or canary-ing new integrations which others can add onto later. At times it is hard to get my own stories done among all the other things. But that's ok! I took the path because enjoy learning and growing technically. And that has certainly been happening. :)
Thank you for your note. I don't disagree with anything you said. The tech path is very hard.
In my post, I said that it is "familiar" making the assumption that the reader is a developer who is familiar with the difficulties of that path.
For a developer, management can appear scary because it is a completely new direction.
I had no intention to imply that the technical path is easy or relaxing. Far from it. I also agree with you that technical leadership requires many soft skills, even if you are not managing the people you work with.
The biggest difference is in the type of problems you need to contend with using soft skills. As a tech lead you can keep it technical, so you need to know how to approach developers on technical subjects. As a manager, you have to add the soft skills necessary to deal with much more personal issues such as friction between employees, health issues, promotions and raises, performance issues, team building activities, career management, career mentoring, etc. Those are the kinds of things that, in my experience, make management "scary" for tech types.
Thanks for the good post. :)
Thank you!!