Successfully promoting great software engineers to leadership roles

October 13, 2016 8:56 AM

I've noticed a pattern at the software company I work for: our best engineers (not just in terms of engineering but also in terms of their social skills, collaboration, coaching and working well with others) are promoted to engineering leadership roles and given direct reports. This reduces the time they spend actually making things by at least 50% due to the time they spend in management. They often don't make great managers (at least at first) and in some cases they eventually ask to return to being an individual contributor. How can we make this work better? What patterns of success have you seen for this in your own workplaces?

These are smart, committed, human-oriented people. They should make excellent leaders. How can we set them up for success? Are there proven ways of structuring this so the more time consuming parts of direct report management are handled elsewhere?

posted by anonymous to Work & Money (20 answers total)

I think this is an incredibly common theme across most technical industries. Great managers may be poor engineers or non-engineers, while great engineers often make poor managers. Someone being talented at and well suited for both engineering and management/leadership is an exception, not the rule.

IMO, the smart path is to create both technical and managerial paths of advancement beyond 'Sr. Engineer'. Allow very senior and talented technical people who wish to remain in technical roles to continue to advance in pay and title without being forced to move into management. Don't structure the titles and org chart such that 'management' is always an eschelon above 'technical'.

These engineers will still be leaders in your organization, but they will be primarily leading by their example, and by the mentoring they provide to the more junior contributors on the projects they work on.
posted by teatime at 9:09 AM on October 13, 2016 [25 favorites]

Not answering the question, but I work in a tech role and have flat out refused this type of promotion. Why promote me to something I'm not good at?

That being said, I think training and mentoring are a big deal here. Not everyone knows how to be a manager, how to deal with conflict, how to be self aware enough not to micromanage, that different people need different management styles and so on. Nearly everywhere I've worked, managers are thrown into the role and left to fend for themselves. That sounds good in theory, but I would find it helpful to hear the types of situations and personalities I might run into, and how to deal with them. It would also be helpful for me to have an identified good/model manager that I can just flat out ask for a correct approach.

So, some combination of mentoring, "official-ish" training, which might just be running through various scenarios, and having some resources to go to in times of need.
posted by cnc at 9:13 AM on October 13, 2016 [3 favorites]

(Of course, very senior technical folks who are interested in moving into management should have that path available as well. So I apologize for not technically answering the question. I just think the correct solution to the actual problems you're facing is equal parts what you asked for (that I didn't provide) and what I suggested.)
posted by teatime at 9:15 AM on October 13, 2016

I think it's an unrealistic expectation that they continue to serve as an individual contributor once promoted to management. It is (or should be) a totally different role with a different set of responsibilities, not something that gets tacked on to their existing role. The most successful managers I've seen are a step removed from the nitty-gritty detail because they have people to do that for them.

So no I don't think you should offload direct report management from them, you should be making that one of their primary responsibilities, and backfilling for them on the team.
posted by cabingirl at 9:18 AM on October 13, 2016 [1 favorite]

This is something that is common in my field as well (medicine)--people who are really good at clinical or research work are promoted to leadership roles and often flounder a bit, because often they've never had to manage administrative work or more than a couple of people. Being a successful manager is a different skill set than being a nice person with good social skills. For example, one of the things that I found difficult when I was promoted to a leadership role was scaling communications--how to make sure that my 13 direct reports and the 70 people who reported to them were all in the loop about new information, priorities, goals, and schedules, and how to keep track of progress and give feedback to outliers. That's really different from just getting along with people or mentoring someone 1:1.

Are you offering your new managers any kind of formal development? Any courses or workshops? Is there a clear mentorship pathway? Do they have somewhere to go if they're struggling? What kinds of issues have the people in those roles brought up?

I would also try to go "down the line" a bit to people who are currently in individual contributor roles, so that they have some of those skills going in. A workshop or something on giving and receiving feedback, for example, is something that almost everyone can benefit from, or some development around project management.
posted by The Elusive Architeuthis at 9:26 AM on October 13, 2016

The best manager I ever had is completely non-technical. She was able to let us subdivide the tasks and accomplishments from the goals that the CTO passed down from behind his closed office door, and kept us coordinating and communicating by tracking how we broke down the tasks and what the dependencies were.

If you need a technical person in management, find someone like this, the over-performing production assistant, and make them co-equals with the technical person. Let them deal with the organization and coordination and let the technical person do architecture and direction, and keep their fingers in the technical pie so that they understand how to set the goals.

But don't make them do the Gantt charts and accountability and departmental coordination, that's its own specialty.
posted by straw at 9:27 AM on October 13, 2016 [1 favorite]

Make the non-managerial positions more comparable (in some combination of pay/benefits/prestige) to the managerial positions. Don't make people feel like they have to enter the management track to "succeed".
posted by Etrigan at 9:36 AM on October 13, 2016 [6 favorites]

Look at some of the top tech companies that have individual contributors roles that go up very high: principal / distinguished engineers and fellows. Leadership is very important but as a technical expert as opposed to a people or project manager.
posted by JonB at 9:47 AM on October 13, 2016 [2 favorites]

I don't think there's a right answer for this, or if there is, I haven't seen it. But I found this Dan McKinley post on the technical track extremely useful. You're asking about the other track, management, but only by thinking about them both together can you get your arms around the problem.
posted by caek at 10:13 AM on October 13, 2016 [1 favorite]

This is only based on my anecdotal experience... But I am in a technical position and eventually want to move into management. There are 3 managers in my division who manage slightly different areas that are all technical. Two of them come from a technical background and one does not. The one who is not very technical, but is familiar enough with the company's processes, is the best manager of them all. She actually manages her people by checking on their workload, easing any client frictions, and doing the high-level work that lets the technical resources get their job done. The two technical managers ignore most of their managerial responsibilities and write code. They mostly only get involved with performance reviews and hiring/firing, and ignore all of the other stuff that management actually does. This causes a lot of issues. They write great code, but their employee retention rate is not great.

People who want to get into management will let you know, either by excelling in minor management responsibilities or actually telling you so. Let the senior coders continue to code if that's what they want to do. Don't make them think they have to become a manager to get a raise.
posted by possibilityleft at 10:16 AM on October 13, 2016 [7 favorites]

Most companies have two "tracks": a management track, and a technical track. Management track gets titles like "engineering manager" whereas the technical track gets titles like "senior architect." I think this is pretty standard across the industry. Gigundo monster corporations (Adobe, Google, etc.) have tiers upon tiers of technical track senior positions, like "member of technical staff," that indicate a large amount of technical expertise and freedom to work on R&D without having any direct reports. How many tiers you can support depends on the size of the company, how resource constrained the organization is, etc.
posted by deathpanels at 10:32 AM on October 13, 2016 [1 favorite]

There's a reason why most people are (not) answering the question you asked by saying "don't promote me" or "promote me, but not into management".

You're asking someone to do a job they have no experience and no training for. You help them succeed by giving them experience and training.
posted by danny the boy at 10:32 AM on October 13, 2016 [1 favorite]

Not answering the question, but I work in a tech role and have flat out refused this type of promotion. Why promote me to something I'm not good at?

I think the answer to this is usually "that's the sole promotion track/only way to be promoted in our organization."

So, then, the question isn't "would you like to be promoted into a management track rather than further up the engineering track?" it's "would you like to be promoted, ever?"
posted by pullayup at 10:36 AM on October 13, 2016

At my place of work, which uses technical and management tracks, there are defined prerequisites for every rank in both tracks. Any technical person wanting to transfer to management needs to show competence in both administration, finance, and a variety of soft skills (as well as having a technical background/education). If they don't have those skills there are training courses that they can take, but it's a hard stop on them going into management until they have those skills.
posted by cardboard at 10:48 AM on October 13, 2016

my engineering department is also two track: from software engineer, you can either promote up to senior engineer, which is basically taking more leadership and authority over technical decisions, or engineering lead, which is about trying out management responsibilities.

The eng. lead has a small team (2-3 direct reports) and still does individual contribution. It's a bit of a stressier role to balance, but is intended to force the lead to decide if they want to continue managing or switch back to the technical track. You aren't supposed to stay at eng. lead for more than a year at most, and it's also possible for senior engineers to switch to lead or vice versa if they want to try out one set or the other.

Senior engineers advance to being principal engineers. Engineering leads advance to being engineering managers. Engineering managers have little to no coding responsibility, but focus mostly on mentoring, assignments, and career development of other engineers. Principal engineers are essentially architects who have authority over larger pieces of our tech ecosystem. You can basically be in charge of code or in charge of people, but we don't make anyone do both for very long.

Also, as an additional note, for people who are in charge of other humans, don't give them more than 10 direct reports. Even if it gets to 8, you want to start think of tiering with leads or other junior managers. It gets tough to give each member of your team the time that they deserve if you have a huge team.
posted by bl1nk at 11:54 AM on October 13, 2016

I think there's a big unsaid in all of this. Just because a programmer has good people skills, it doesn't mean they want to be a manager in an HR sense. If coding is what makes them happy and they can also add value as a mentor, architect, or whatever, find ways to have them do that while staying true to what keeps them motivated and engaged. I'm certainly on the other side of this coin, happiest when my management skills are getting the team working better and I don't miss my more technical days very much.
posted by advicepig at 12:36 PM on October 13, 2016 [1 favorite]

The company is just following the Peter Principle, first discovered in the 1960s. It states that anyone who does a good job is inevitably promoted to a different role until they eventually end up with a role they are very bad at, which is where they stay. This is called being promoted to your "level of incompetence".

Pluchino et al produced a most illuminating paper on this a few years ago.
posted by w0mbat at 2:51 PM on October 13, 2016 [1 favorite]

Adjust your expectations. A manager (even a technical one) should spend 100% of their time managing.

Make sure they get management training. I like a lot of the recommendations in this guide. There is a great free series of podcasts at Manager Tools. Buy them a copy of High Output Management.

Manage them effectively. See How to Manage Managers.
posted by unrulychild at 3:33 PM on October 13, 2016

I'm a developer who refuses all offers to advance into management. I'm good with people, good with general project management, and my employer would love for me to manage resources and/or projects.

I don't want to. I love to code. I don't want to figure out why Jane hasn't completed her widget or why John never gets his time card sumbitted on time.

I'm lucky - as a dual-income, child free household, my husband and I have the privilege to NOT move up a ladder we don't want to be on. But if I were the sole support of my household, or under financial pressure to increase my contribution, I might cave to the pressure and say "yes" to one of the more money less happy offers my boss gives me.

This is a long and anecdotal way of saying that maybe some of the techs going into management see it as the only way to increase their earning power at your company.
posted by hilaryjade at 5:55 PM on October 13, 2016

One common pattern where I work is that high performing ICs are often made "tech leads". The tech lead role involves many aspects of line management -- they often own or heavily contribute to areas such as project planning, estimation, co-ordination and communication with other teams, technical mentorship and leadership, establishing and enforcing engineering best practices such as adequate test coverage and quality code reviews, etc. but they do not have direct reports and have no responsibility for the careers and happiness of the team members, performance reviews or performance management, etc. This allows folks to get a taste of management and practice skills that are vital for managers while allowing them to easily bow out of the role if they don't enjoy it. Some people choose to stay tech leads indefinitely and help shape the technical direction of their team and never decide to become managers. But if a tech lead does want to become a manager, then responsibilities such as having career conversations with team members, contributing heavily to performance reviews in the form of highly detailed 360 feedback, etc. can gradually be transitioned to them, leading to a fairly smooth transition into a managerial position.

As everyone else has said, a manager with more than, say, five or so reports shouldn't be expected to do any IC work at all. If managers in your org are expected to spend half their time on IC work, unless they have tiny teams, no wonder they are failing!
posted by phoenixy at 6:29 PM on October 13, 2016 [1 favorite]