I'm curious to hear what fellow members of the DEV community think about the typical career ladder for engineers. Personally, I think its odd that we train engineers to be technical individual contributors for years and then have them pivot into roles as managers that
- they may not want
- they may not like
- they may be unfit for
Curious to hear from devs who have been promoted to managers themselves, what kind of training is offered at your company for this transition, or alternatives to this career ladder that maybe would work better?
Top comments (4)
I'm a fan of the multi-track career ladder for developers.
Each track should be just as deep, but with a different focus, you definitely don't want to promote all of your best developers into non-developer positions because that will lead to brain drain. You want to keep your best developers developing, and you want a path for them to advance. What we do at $DAY_JOB looks a bit like this:
Technical IC: Dev I, Dev II, Senior Dev, Staff Dev, Distinguished Dev
Influencer: Dev I, Dev II, Senior Dev, Principal Dev, Architect
Management: Dev I, Dev II, Senior Dev, Team Lead, Manager, Senior Manager, Director
The individual contributor track lets you go deep into your technical role, keeps you out of meetings, and allows you to progress to the same levels as the other tracks. You become an expert in your field and most of your time is spent coding.
The influencer track keeps you technical, but you start to work more across the organization than just within your own team. Your reach is greater, but you're still a developer. You definitely attend more meetings than an IC on this track, but you should still be coding a fair amount of the time.
The management track is technical as well in our case, but you're not doing much development work (some of us do, because we love it, but we try to keep ourselves off of the critical path -- no one wants to be relying on their manager to deliver some feature) but instead you're doing lots of 1:1s, making sure your team is happy and has everything they need to do their work. You're also helping them figure out how they fit onto the other tracks and helping them grow their careers.
Ideally, it should be pretty easy to hop back and forth between the tracks, say you want to try being a manager, but then discover that you really don't like it and want to go back to being an IC -- this should be easy to do and encouraged.
Would love to hear what other are doing in this space!
Thanks for your response! I think these tracks make sense except that I wonder if the people skills aspect should be introduced earlier than at the level of Team Lead. I think that developers could use more training in communication, but it's also the fault of the industry for not valuing those skills. Personally I find that the longer I am in a role just coding, the worse my social skills get which kind of sucks considering I used to have pretty good social skills.
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.