Nowadays there is a natural progression for senior software developers (either in startups or more corporate style companies) to make the jump from their current technical role to a more leadership/management oriented role. This progression is usually motivated by several needs which arise from the evolution of the company/team/product and require the senior dev to dedicate his time to training/onboarding, planning/road mapping and leading the team, contributing to more macro level decisions and coaching while becoming less and less involved in day-to-day engineering activities.

The title of the job is not always “Manager”. It’s usually something along the lines of VP of Engineering or Tech/Team/Project Lead, which carries a different meaning from having Manager in your job title, even though it requires a lot of management activities.

In this article, I’m going to introduce how and why the jump from a more technical oriented role to a more management oriented one happens and the issues it may carry along with it. I’ve drawn some inspiration from this lovely article from Charity Majors, you should definitely check it out. I’ll also go in depth on the challenges facing you when you make the jump.

“Hey, I have invited you for that meeting we talked about…”

The jump from tech to management is a natural progress caused by the team growth and your seniority in the project. If the team needs more developers then you’ll probably be involved in the recruiting process. Then when those people join the team, it’s your job to coach/onboard them. If there are drastic design or architecture decisions taking place then you’re one of the people responsible for taking the final decisions. All of these tasks usually require a lot of time, whether it be time spent reviewing and approving candidates, answering to emails or preparing and conducting meetings.

This means you will be dedicating most of your time to activities which are much more directly related to managing the team than actually developing software, which can be a huge turn-off for a lot of developers out there.

However, this switch in focus to more management oriented work can be a necessary evil. As a Senior dev, you carry the technical knowledge of the project and will be one of the people who can tell if a newcomer is suitable for the project. You will also be precise in estimating tasks and planning the work, since you have been part of the project since the beginning, undertook the early design decisions and know the architecture. All of this knowledge is very valuable, and hiring someone new to do this kind of work where all this prior knowledge is required is not an option most of the times.

With this being said, here are some of the reasons why devs jump from their tech role to a more management focused role.

Salary

Truth be told, companies are willing to spend more on management hires than they are on their tech hires. I know this is generalizing and that it might not apply to every company out there but you hit the salary cap much faster working as a software developer than you do by managing the work of others.

In my point of view this happens for two distinct reasons.

The first reason is the fact that soft skills usually pay out more than hard (technical skills).

The second reason is Accountability.

Soft skills are harder to learn than technical skills. Sure, you might have a superstar engineer who is a 10x developer and can crank out work by himself like no other. But is that guy really relevant to your team if he can only work by himself? What if he has poor communication skills? Are you still inclined on promoting him to a more coaching oriented position? Will he be doing a good job?

Management hires need to do their work, but they must also possess strong soft-skills to address the human side of building a project such as communication, empathy, team-spirit and problem solving.

Accountability means you will be the person to blame for the team’s successes and shortcomings. When everything goes wrong you don’t blame the person who carried of the operation and did it wrong, you blame the person who gave the order, and when you’re the person who gave the order and your head is on the chopping block that means more $$$.

Career & Lifestyle

Software development is a type of job where you need to be constantly learning and upgrading your toolkit in order to stay sharp and perform the best job possible. But life and other responsibilities may drift you away from your late nights of working on side-projects or your typical blog post reading. This has a psychological impact more than anything. People start to feel like they cannot keep up to date, skills wise, and transfer to a job which gives them more room.

Also, as people mature, they also gain a more clear grasp of life and human interactions so they naturally gain communication skills and experience which can be valuable to management operations.

On the other hand, some people get into software development with the clear purpose of climbing the ranks and become the team’s manager.

Embracing a new role

For people who are considering making the jump, here are some key aspects to take into consideration while making the transition. For this section, I really need to thank Alexander Grosse for his amazing Masterclass on How to build a tech team in the Start & Scale Week from ScaleUp Porto.

1) Shifting focus from technical work to management work

Some people really dread management work and try dearly to hold on to whatever technical work they can do. This is not a bad thing as most of the devs who juggle their tech work with their management work tend to be successful in doing so, and that allows them to be more in touch with what the team needs and what he can do to unblock the team. If your superiors/company allow you to navigate around more technical work then go for it; if not, hey, there are always side projects to be made!

However, if you remain active as a developer, don’t be on the critical path. Seriously.

Your time is now divided between a multitude of activities. If code reviews or deployments depend on you then you’re becoming a bottleneck to the team just for the sake of selfishness and trying to hold on to as much technical work as you can. If you see yourself in this position and not willing to let go then you’re probably not suited for a management role.

2) Don’t be the Team’s Hub

Engineering does not exist in isolation. Engineering teams need to co-exist with other areas of expertise in order to deliver value to the customer. Keeping your team away from roadblocks or distractions (which is a task for the manager) is not the same as keeping the team way from any outside communication.

Your developers should be able to interact with other teams from different disciplines and end-users of the company’s product in order to adjust the product fit and find flaws in the software. If this becomes hard to manage, allocate a time frame where the team can perform work dedicated to external dependencies.

3) Hire right

Recruitment is always a touchy subject. Hiring processes usually take a lot of time, and the more time it is taking from people from the upper ranks then the more costly they are. If your company is growing above 20 people you should consider asking for dedicated HR personnel to be hired.

Some key points to consider are:

• If you need quality then hire quality. Software developers can be expensive but they can quickly earn their value. At least try to get a couple of solid and stable hires who can then coach the rest of the team.
• Don’t fall into referral traps, and don’t let teams do their own hiring by themselves. Teams need diversity, you don’t want a team where everyone thinks/is the same.
• Hire for value fit. Forcing someone who doesn’t believe in TDD having to do it is far harder than having someone learn a new language.

As a final note on this topic, there are several opinions about the current interview/hiring process for software development jobs being broken. Please take some time to review the company’s current process and give your feedback accordingly.

4) Have purposeful Onboarding

Onboarding is a vital subject when discussing team productivity and general happiness of fresh hires.

On a small company (<10) the onboarding process is usually spontaneous. However, if your team grows beyond that then it is time to grow beyond “hey that’s your seat and please go talk to [person]”.

It is your job as team manager and leader to give people all the context they need and mentor them. You can point the newly hired engineer to the resources he needs, introduce him to the team and the team’s processes and get him started right away. People already know they will be unproductive in the early stages so don’t give them any more reasons to feel that way.

One of the most effective (and helpful in terms of growth) processes of onboarding is support. By being assigned support tasks, the newly hired member can work on his communication skills, understand different problems and parts of the product and navigate around the project while closing support tickets. This will greatly help him or her in understanding the product, the market and how everything works. It is also, in my opinion, a growth experience since one, as a developer, will understand the product’s issues from the customer’s perspective, which can lead to understanding what failed in terms of user experience and what can be improved.

5) Have 1 on 1’s

There’s not much science in this. You should be having one on one conversations with you team members. In these discussions you should focus on figuring out how they’re doing, how they are adapting to the team and the company and what they see as potential problems in the future. You’ll not only be building a trusting relationship with the other person but also figuring out some underlying concerns which may not arise in the day-to-day operations.

You should also look to give (and receive) feedback in these instances. Here’s a great article on how to navigate around feedback to junior developers (I’m guilty of the second type).

6) Working on tech debt

Being a developer turned manager you know more than anyone else that one of the things that haunt developers the most is technical debt. No-one wants to build a house on a faulty foundation so, whenever you can, give your team some space to refactor and reorganize.

Tech debt can be one of those things which makes or breaks the team’s morale. If the team is able to work on technical debt they feel their work is respected and that the compromises made during planning can now be properly addressed. On the opposite side, never being able to do some “housekeeping” can eventually lead to frustration, tiredness and ultimately be the cause of people to leave the team.

7) Incentivize communication and collaboration

You need to know what people are doing. If you don’t know, then you don’t know what you’re doing. Use the tools at your disposal to track this, not only to know if everything is running as expected but also to unblock people if need be.

Also, have regular Demo sessions. The team needs to be able to present the work they’ve done to the rest of the company. This will keep everyone focused on delivering something that is done right (presentable) and will also serve as a status update for everyone else who’s not involved.

8) Define culture and values

Growth is an enemy of culture. Most companies pride themselves on having an amazing culture only to find out that the culture is an echo of the C*O’s beliefs.

Ask yourself and ask your teammates — “What is our culture?”

If you don’t have a culture statement defined then maybe is time to inform the company that something needs to be done about this, otherwise each team will create its own culture which will usually be defined by the opinions of the most dominant personalities. Even if the people in charge are upright, their personal values can clash with the ones the company defines as its culture. Culture definition is an exercise where everyone should contribute to. This definition evolves over time as the team/company grows and more people contribute to it.

Values are something cultivated at a company level but also at a team level. In the case of software development teams, values can be enforcing TDD and code reviews or always having a clearly defined git flow. Always look out for people who don’t adhere to the team’s values. Burnout by value conflict is real and it may be the cause of instabilities in the team.

9) Get feedback

Not everyone has experience management or can manage properly from the start. If need be seek, appropriate training. This can either be reading a book, doing a course or having a workshop. Please be sure that after the training everyone responsible for managing different sectors or teams in the company gets together to talk about what could work and what couldn’t in terms of management methodology.

Also, if possible, have your work reviewed by others of the same status. Peer review is always effective in finding spots where work can be improved.

10) Don’t preach for long hours

It is your duty as mentor and leader to give the example and if you don’t know by now the downsides of working long-hours then you should get informed. It may be secretly hurting your team without you even knowing. I found this article to be very enlightening on this subject.

---

Making the jump from dev to management is not an easy task but it may lead people towards a more meaningful career path. Think about what you want to do and in which conditions do you see yourself managing an engineering team. Also bear in mind that this switch requires you to be proficient in a lot of areas surrounding the team’s efforts.