{{announcement.body}}
{{announcement.title}}

How to Groom Your Engineers for Engineering Management Roles

DZone 's Guide to

How to Groom Your Engineers for Engineering Management Roles

By understanding your engineer’s driving motivations for wanting that new role and making sure that they’re realistic about the right things to optimize for with those motivations in mind.

· Agile Zone ·
Free Resource

Engineering leadership within companies are constantly looking to create an equitable process to figure out who on a software engineering team gets the opportunity to try management. However, there aren’t many good resources to help them figure out how they can spark interest in candidates that might be a good fit for management. 

The first thing I’d recommend is watching/reading is Tanya Reilly’s talk “Being Glue”. The whole talk is brilliant, and there’s a really important section about making sure you are steering (but not forcing) the right people towards less-technical roles like Engineering Manager. The main rules of thumb to follow while starting to move someone towards a management path are:

  1. They have to be strong, solid, and dependable engineers.
  2. They need something to anchor on when they’re learning a new set of skills, and already being respected by teammates for their technical skills gives them that room to maneuver.
  3. If they’re not already playing a role like Tech Lead where they’re somewhat responsible for delivering other people’s work, I try to find opportunities for them to do that. (e.g. be Scrum Master and push & track execution of teammates).
  4. They have to actually be excited to play the role of management and also understand that engineering management is a whole different ballgame altogether. The second someone mentions maybe being interested, share with them a copy of “The Managers Path” and ask them if that’s really what they want to pursue. Our industry’s history of taking people with good engineering skills but no interest in management, then giving them direct reports and hoping for the best, is responsible for a lot of the cultural issues we face.

Engineers are either actively pursuing a management path or you see the talent in them to be good in such a role. In both cases, you can start by offering smaller management tasks, without the need to add a label to them. You can say that you need help and you think they’re perfect for it. You’ll find opportunities through things on your own plate you need to handoff. Observe how your potential engineers do over a sprint or two. Evaluate the result and their engagement on the task and then have a 1-1 about it. This is a great way to let everyone have a taste of management. This strategy is found to be very effective because if someone struggles with it, it can be clear that they might not ready for a management role yet. For those that do well, you can keep finding new opportunities for them.

You can also look at the grooming of engineering management from a different angle. When strong engineers move to a management role, they can sometimes experience a form of imposter syndrome that when things get tough, and to make themselves feel better about their jobs and their impact, they might undertake more software engineering tasks, rather than sticking to the actual hard, and often thankless job that needs to be done. It’s also worth asking what the team actually needs from its leader - do they need someone who’ll mentor them on the technology? Review PRs? Partner in coding practices? Or are they looking for a leader or someone who’ll deal with prioritization? Do remember to make sure they actually answer the “do you want this?” question rather than the “are you ready? question”.

The biggest challenge you will face will be from senior devs who believe they want to move into management and leadership roles, but are in fact are unwilling to do the actual work of management. It is quite common, for folks to reach a certain level of experience and then to feel that they now must climb to the next rung on the ladder. Despite their experience, they may have a fairly weak understanding of the work of managers and leads. And when given opportunities, they might fail to put in the effort to grow in the ways that would be necessary for them to do those jobs effectively. In one sense, the situation is simple in that you know what to do: give them feedback, have expectations for performance, let them know that they can advance into these opportunities until they demonstrate the ability to perform to expectations.

The most important thing you can do here is to create a good career ladder that outlines meaningful criteria for those roles. However, in practice, this dynamic can prove really challenging. These are often your most senior team members. They may have the cultural clout to challenge your authority within the team. They didn’t get this far into their career not understanding the job of management without being at least a little obtuse to feedback. And, they may be very important senior contributors that you rely on—so you really do want to try to make them happy and feel that they are growing so that you can retain them. One way of dealing with this situation is two-pronged:

1. You either give reverse-able growth opportunities with clear expectation, feedback, and patience, or 

2. You don’t let anyone contributor be so critically important to your team that you feel it necessary to make bad promotion decisions just to retain them.

To sum up, you need to understand your engineer’s driving motivations for wanting that new role (recognition within the company? recognition within the industry? compensation? internal influence?) and then make sure that they’re realistic about the right things to optimize for with those motivations in mind.

Topics:
agile, agile adoption, devops, engineering management

Published at DZone with permission of Vishwa Krishnakumar . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}