Usually you have to be a team leader before you can get promoted to manager.
That aside, to answer your question, I think it depends on whether they have the necessary skills for this role.
Being a team leader requires both technical skills and people skills (leadership being the most important).
Being a manager requires only a limited set of technical skills (enough so you understand what devs are trying to explain to you) and very strong people skills.
From my experience, devs are "promoted" to leadership roles (team leaders or managers) based exclusively on their seniority (i.e. how long you've been a part of the team/company).
Upper management sees the transition from technical to leadership/management as something that naturally comes with time. This, of course, has nothing to do with reality. You can be a very good developer with 10 years of experience and be a an awful team leader or manager. And this is usually the case. There is a reason why, after so many years, they're still writing code. And it's not the lack of opportunity. It's because they don't want to do something else. Writing code is what they like/want and if it's up to them they'll probably do it for another 10 years.
Basically, when a team leader or manager leaves a team (or the company), the spot needs to be filled. So upper management needs to find a replacement quick. And what they do is simply choose the dev who has been on the team the longest. That's it. They don't assess your people skills, your leadership skills or anything else.
They just ask if you wants the position. But that's more of a formality. Even if you say no, they're going to encourage you to give it a shot. They'll even try and make it look like it's a piece of cake. Even though, in reality, if you want to do it properly, it's very difficult. And that's problematic because
1) you end up with poor leaders/managers who don't do their job properly.
2) you lose devs who could have continued to do a good jos as technical people
3) you lose devs who finally get fed up about having to deal with poor leaders
But if you do it right (i.e. choose people who actually want to follow this path and are qualified for it), there are benefits:
1) They already know the project and there is no need for an accomodation period (to know the project, the team, the customer(s)).
2) The relationship with the other colleagues is already established.
3) They have the all the necessary technical skills to understand anything the other devs might want to discuss.
To conclude, I think this practice (or promoting devs to team leaders or managers) is a good idea when you do it right (i.e. the chosen devs want to do this and they are qualified to).
Otherwise, it's a ticking time bomb.
Currently writing open source code and helping partner developers as an Integration Engineer at Login.gov. Author of Foot in the Door: My Self Taught Journey Becoming a Software Engineer
Agreed 100%. There is such a dangerous assumption in the industry among upper management that "leadership is something that comes naturally with time" like you said. It is patently false. If they are writing code for 10 years, chances are that is what they want to keep doing.
I've worked at companies who theoretically are doing it the proper way, but even then I have seen people in leadership roles that clearly need more training on people skills, even if they are good at dealing with architecture and high level software problems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Usually you have to be a team leader before you can get promoted to manager.
That aside, to answer your question, I think it depends on whether they have the necessary skills for this role.
Being a team leader requires both technical skills and people skills (leadership being the most important).
Being a manager requires only a limited set of technical skills (enough so you understand what devs are trying to explain to you) and very strong people skills.
From my experience, devs are "promoted" to leadership roles (team leaders or managers) based exclusively on their seniority (i.e. how long you've been a part of the team/company).
Upper management sees the transition from technical to leadership/management as something that naturally comes with time. This, of course, has nothing to do with reality. You can be a very good developer with 10 years of experience and be a an awful team leader or manager. And this is usually the case. There is a reason why, after so many years, they're still writing code. And it's not the lack of opportunity. It's because they don't want to do something else. Writing code is what they like/want and if it's up to them they'll probably do it for another 10 years.
Basically, when a team leader or manager leaves a team (or the company), the spot needs to be filled. So upper management needs to find a replacement quick. And what they do is simply choose the dev who has been on the team the longest. That's it. They don't assess your people skills, your leadership skills or anything else.
They just ask if you wants the position. But that's more of a formality. Even if you say no, they're going to encourage you to give it a shot. They'll even try and make it look like it's a piece of cake. Even though, in reality, if you want to do it properly, it's very difficult. And that's problematic because
1) you end up with poor leaders/managers who don't do their job properly.
2) you lose devs who could have continued to do a good jos as technical people
3) you lose devs who finally get fed up about having to deal with poor leaders
But if you do it right (i.e. choose people who actually want to follow this path and are qualified for it), there are benefits:
1) They already know the project and there is no need for an accomodation period (to know the project, the team, the customer(s)).
2) The relationship with the other colleagues is already established.
3) They have the all the necessary technical skills to understand anything the other devs might want to discuss.
To conclude, I think this practice (or promoting devs to team leaders or managers) is a good idea when you do it right (i.e. the chosen devs want to do this and they are qualified to).
Otherwise, it's a ticking time bomb.
Agreed 100%. There is such a dangerous assumption in the industry among upper management that "leadership is something that comes naturally with time" like you said. It is patently false. If they are writing code for 10 years, chances are that is what they want to keep doing.
I've worked at companies who theoretically are doing it the proper way, but even then I have seen people in leadership roles that clearly need more training on people skills, even if they are good at dealing with architecture and high level software problems.