This is something that comes up often in sessions through the Endeavor network or with companies I advise so I thought it worth a blog post. Imagine a situation where you have a startup, you are in the right place and have the right skillset to scale this up, you build up your engineering team with a few core people who help you grow to the next level. Then you hire some more engineers and some more.

The ones who have been there for a while get promoted to senior engineers as the team grows: it makes sense, since they are “senior” to the newcomers in terms of years of experience in the company and also they know more about your system since they built it. (This in itself requires perhaps a whole blog around experience vs institutional knowledge, but I will let this one fly for now and come back to it later; for now let’s assume that your reasoning for promoting engineers to “senior” is pretty good.)

Then one day one of your senior engineers comes to you and say: “Hey, I am pretty senior and I do a lot of things in this team and I want a promotion!”.

This is a pretty standard request and you think it through: this person has indeed been with the company for quite a while and has been put a lot of effort in a lot of aspects of your platform, has helped onboard a lot of the newcomers and has seen us through a lot of “fires” we had to put out. In other words, your initial instinct is to say “yes”, because this person has put a lot of blood sweat and tears into your company and you want to recognize that and help them with their career development. So you start thinking of promoting this person to an engineering manager position — and therein lies the problem! To most people a promotion means stepping into a managerial position; however, what most people fail to recognize is that there are different skillsets involved in being a strong engineer and being a good manager. And a good engineer doesn’t necessarily make a good manager! While the first few career progression steps in engineering seem more clear cut ( associate/junior, mid-level, senior) the path from senior onwards is not that straight forward and it’s easy to fall into the trap: senior engineer – engineering manager.

What I do myself when confronted with this situation, and what I recommended to companies who reached out to me to discuss these issues is this: when a senior engineer comes to you and ask for a promotion ask them back: what do you envisage and want that promotion to be? What do you see yourself doing once we finalize the promotion? How do you see your job changing?

Most engineers, you will find out, envisage NO change in terms of what they do! In other words, they expect to be doing the same thing, same coding, same design/architecture and so on; they do envisage a change in the scope of the projects they get involved in: whereas before perhaps they were not involved in making architecture decisions they now want that, whereas before perhaps they were not involved in exploration and prototyping , the want that. And that in itself should be telling for you: what they are asking for is a recognition of their technical talent and more TECHNICAL responsibilities. And this is where a lot of companies fail to recognize there are 2 directions for career progression: technical leadership and people leadership. And in most cases, when engineers ask for a promotion they are interested in heading down the technical leadership path: they want to oversee larger parts of the system, they want to get involved in architecture, they want to be involved in the decision making around frameworks and languages to be used and so on. And in a lot of cases, asking the above question helps both you and them clarify the direction they want to go in.

There are still cases though where they might think they want to go down the people leadership path. It could be that is something of interest to them or in a lot of cases, it’s a mix of curiosity and misunderstanding of what that might comprise of. In such cases I recommend a few things:

• Discuss openly with the person what their job would look like if they decide to embrace an engineering manager position
• They are going to be responsible now for a group of people, their direct reports, so they have to have 1-1’s with these folks and constantly deal with concerns and issues brought up. This means time spent talking to your team every week. Simple arithmetic shows that for a team of 5 engineers, assigning 30 minutes for 1:1 every weeks takes away nearly 3 hours of your week.
• They have to start getting involved in hiring — sourcing candidates, filtering out resumes, screening calls and so on. Plus the interview process, in which you now play a major role and in most cases have to be the one making the final call.
• You have to get involved in legal matters, such as visa / green card processes; if you are also unfortunate enough that one of your team members is showing performance issues, it is now your job on one hand to try and help them and if needed start a whole HR process to address their lack of performance.
• You now have to help distribute the work across your team: you have to learn each member’s strengths and preferences so you can distribute this work correctly.
• You need to start cross-communicating with other colleagues in other teams to help shape up the engineering roadmap. This takes countless meetings to understand needs and priorities across the org . And you need to communicate these back to your team so your engineers have a clear picture of where the company is going so they can be effective in their efforts.
• You now need to get involved in performance reviews: this typically means collecting feedback from peers, clients, HR and compiling it and putting forward an action plan for each one of your team members: be it a promotion (yes, you yourself will be faced with the exact situation you have created: “I want a promotion!”) or a compensation increase and so on.
• You need to manage up, have 1:1’s with your direct manager and others to develop partnerships and set up client communication channels.
• Speaking of which, if your team works on a product which has clients, now it becomes your responsibility to liaise with clients and get requirements and feedback from them. Also it’s your job now to implement a “support” channel where you can react in a timely fashion to client requests and support calls.
• If there is any animosity in your team or in between your team and another team, guess what? This is now your job to address.
• Your job becomes enabling your team to play at its best. You need to constantly clear the path for your team to run at full speed!

You might get occasionally involved in a code review, for say a very sensitive part of the system, especially if your team is somewhat junior (and it is your duty now to help them progress to a more senior state!) — but do NOT expect that being a manager means you will write more code and ship more versions of your software to production! In fact the opposite is true. If any work comes in your direction, your job becomes NOT to do it yourself but to delegate it to your team members who can take this task and see it to completion in a timely, efficient and elegant manner.

One way that I found effective to get engineers to understand what the above list REALLY means is to have them shadow me for a day or 2: get them to attend all the meetings you are attending and see for themselves. Ask them to take part in some: prepare the notes for the team meeting, take notes during the alignment meetings with other teams, sort through resumes and take part in screening calls. This helps them understand very quickly that this job will see 90% of their times spent in a lot of areas which are not related to coding, or architecting things, or debugging things.

If they are still interested having understood all of these aspects, there are of course a few other things you need to take into consideration such as supporting them develop into this managerial position — and I will come back to this perhaps in another blog post. I have found out though that in most cases, having this discussion and clarifying the differences helps the engineers decide the direction they want to take, and more often then not turns out what they want from a promotion is actually a technical leadership path.

Sadly, a lot of companies still misunderstand these 2 aspects, and too often I see individuals in such people leadership positions. If your manager/director/etc does most of the coding work in the team, for instance, that is a clear indication you have chosen the wrong person for that job. Soon, engineers underneath this person will start realize they are somewhat irrelevant and the feeling of self-worth will diminish; this will lead to the senior ones leaving and what you will be left with are either the juniors, who don’t know what they don’t know, or the ones who don’t care and they just want an easy 9-to-5 ride. Multiply this by a few engineers-become-managers and soon your whole engineering org becomes worthless. That’s one step away from implosion and it’s a dangerous situation to be in.