Transition from engineer to lead

What makes it even harder is that sometimes it is not clear how this transition will affect the work you do. There are certain expectations from the person stepping into the new role, but there are also expectations from the company as well – and in some cases, these expectations might not align, leading to various issues, big and small. This is exactly the topic that I would like to discuss in this article – if you decide to make this move, how will that affect you and how will your job change? The other important question that will be also addressed is how to achieve this – what are the possible ways of moving to this new role?

Author’s note: Team leads have to deal with managerial topics on the daily basis, therefore this role is also commonly called Manager in many companies. For the rest of this article, I will be often using the term “manager”.

How will your work change?

Do not expect to be able to spend days immersing yourself in the code for hours (but you may get a chance to do that from time to time). Don’t worry, you will still get to do some engineering work and even more important, you will have to maintain an engineering mindset

Once you actually make the transition, your work will consist of two large groups of activities – managerial ones and technical ones. I think it’s fair to say that the split between managerial and technical work will be 70-30 or 80-20 most of the time, in favor of managerial work. Occasionally, that split would be roughly equal, or even in favor of technical work – but these are exceptions. Do not expect to be able to spend days immersing yourself in the code for hours (but you may get a chance to do that from time to time). Don’t worry, you will still get to do some engineering work and even more important, you will have to maintain an engineering mindset [1]. But more on that a bit later.

First and foremost, your team and the work they do comes front and center. This isn’t some locker-room talk – your main responsibility will be to support your team so they can do their best work. There are many activities that a manager needs to conduct, that may seem simple on the surface – but combined together, they may actually spell doom for the whole project (or team) if not taken care of, or make the team flourish (if handled properly). Let’s take a look at some examples of these activities:

• Helping the team design new process or improve an existing one. There’s much more to this than simply choosing to follow methodology like scrum or Kanban (or using your own approach!). For example, you can try to eliminate bottlenecks, reduce waiting times, or simplify complex procedures. You will also have to help the team get all the required information to start working on some feature or new product/service. Oh, and don’t forget making decisions regarding testing strategy, deployment strategy and other engineering topics.

• Helping the team create technical standards for the work they do. How do we perform code reviews? Do we have any coding standards? Do we write documentation and what does it cover? Do we have proper monitoring for our services? How quickly are we fixing our bugs?

• Provide guidance in the technical discussions and challenge design decisions. Also, provide your insight or expertise in specific domain.

• Be the link between the team and the upper management.

• Keep an eye on the amount of work that the team is doing, to prevent exhaustion and (in extreme conditions) burnout. This might mean that you will have to say “no” in certain situations, push back certain decisions or suggest a compromise.

• Conduct technical interviews, help with the onboarding of the new hires, coach your team members and help them become better engineers.

• Last item on this list, but certainly not the least important – together with your team, try to define culture that reflects your shared values and that everyone in the team would like to be a part of.

Sounds like a lot, right? Well, it is a lot – but you will get to experience most (or all) of the listed activities if you work as a manager for some time. At the beginning, you will be probably involved in only a subset of these activities, but during time, you will most certainly do many others as well. But that’s just one part of the story. Remember that I mentioned that there is also the technical aspect of your job? Up until this point, this was probably something that you did most of the time – as an engineer. However, due to the nature of this new role, this aspect of your job will change as well.

…if you are thinking that by becoming a manager you will be able to “design things the way you want” or even “not write code anymore”, you need to immediately re-think why you actually want to become a manager

First off, let’s move some things out of the way: if you are thinking that by becoming a manager you will be able to “design things the way you want” or even “not write code anymore”, you need to immediately re-think why you actually want to become a manager. You will absolutely need to stay technical and maintain a technical mindset. However, you will probably not spend your time working on one task after the other. Instead, you will probably (again) have to focus on the things that (in one way or the other) have impact on the work that your team does. Here are some examples:

• You will conduct research (or part of the research) that is required to get the new project off the ground or design a feature or part of the system. This might involve writing code to test some early assumptions (like writing a small proof-of-concept) or playing around with some product or technology. This will probably involve lots of reading and compar- ing information from various sources. And all this needs to be done so you can have a starting point for the real discussion with your team.
• You may work on the tasks that nobody likes. Maybe they are tedious or boring or require a lot of repetition – whatever the case is, nobody works on them, and they are sitting in your backlog for weeks or even months. This is ideal place for your contribution because this work also needs to be done. Leave the most interesting or critical tasks for your team members – give them learning opportunities, something to be excited about, while you show support by cleaning up some mess in the background. Are there some low-priority bugs? Maybe some feature is not properly covered with tests? Is there some small feature that needs to be implemented? These are exactly the opportunities that you are looking for. By working on something like this, you still have hands-on experience with the code, and you get the understanding of the construction of the product [1].
• You will participate in many technical discussions regarding the architecture, design of the new feature or part of the system or adopting some new process or technology.
• You might be involved in monitoring the existing services and participate in resolving production issues. This would probably require learning about various new tools or different approaches to application monitoring.

With this, I would conclude the part regarding how leadership role would change your job. However, there’s   still one more important topic – and that is how to make this transition.

Ways to make a transition

Well, the obvious answer is to simply apply for such a job, but I would like to mention two different ways of moving to (or preparing for) a leadership role within your current company (and people very often forget to take such things into consideration). These are internal transfer and shadowing.

Internal transfer

This is probably the easiest way to make a transition. From time to time, companies may form new teams that will work on a new project. Depending on the business case, these projects could involve building new products, redesigning existing ones, implementing some compa- ny-wide initiatives, etc. The scope of these projects could be anywhere from very simple to extremely complex. They might have a tight deadline, or be long-term engagements; in some cases, they may even require specific skillset or knowledge.

However, for many of these projects, the company may decide to start with a small team that would consist of existing employees (the ones already employed by the company). The size of the team may vary significantly – in some cases this small team might be enough for the entire course of the project, but in other cases the team may be later expanded with additional hires. Whatever the case, the initial team would be responsible for laying the foundations for things to come.

If there is such an opening in your company – you may be given a chance to lead such a team, or maybe you can volunteer for such a role. Depending on the size and scope of the project, this might be a great learning opportunity, especially for the someone who is new in the leadership role. Here’s as few reasons why:

• Since all the team members are from the same company, you will usually work with the people that you know and with whom you have probably already worked with. You will share common knowledge about the culture, processes, and many other things. This should make day-to-day work and communication much easier. This is very different from situation where you join the existing team where culture and the ways of working are already established.

• Team sizes at this stage are usually small, which makes management easier. More people may join the team during the project.

• It is much easier to keep track of what’s going on when you are starting something new. Jumping in the middle of the ongoing project can be very hard, because there might be a lot of catching up to do.

Shadowing

If previously described scenarios are unlikely to happen for whatever reason, your best option might be asking your manager or technical lead to involve you in things that he/she is doing. This is where shadowing comes into play – type of on-the-job training that allows an interested employee to follow and closely observe another employee performing the role [2]. This basically means that (if your manager agrees, of course) you might be able to join him during various activities and you may watch him/her conduct those activities, take notes and ask questions.

Besides purely observing how your manager operates, you may kindly ask to be more actively involved in certain parts of the job. This means that your manager might be able to

give you a small task to finish – at first, that would be something small and non-critical (and also easily delegated). However, your manager might also raise the bar by giving you control over some specific part of the job that may involve much more responsibility. If done right, shadowing might be an effective way to learn some new skills and get a glimpse of the other role – giving you an opportunity to make up your mind and decide if this is something that you would really like to do.

Conclusion

If one thing is clear at this point – it’s probably the fact that moving to a leadership position is not easy and it’s not something that should be taken lightly. The complexity of your job will increase and you will have to face some completely new challenges. This article tried to provide you at least some information regarding what to expect if you decide to step into a new role. However, this is a very complex topic and there are many things that are important but were not mentioned in order to keep the article focused; in the same time, some of the thngs that were mentioned probably deserve their own article (or a few). Being a leader of a team puts you in a position where you can have a huge impact on other people and their perception of work – this is why understanding your role and acting accordingly is important (and this is the main motivation for writing this article).

---

Author

Miroslav Lazovic is an experienced software engineer from Belgrade. Over the past 15 years, he worked on many different projects of every size – from small applications to mission-critical services that are used by hundreds of thousands of users on a daily basis, both as a consultant or part of the development team.

Since 2016, he is focused on building and managing high-performing teams and helping people do their best work. He likes discussing various important engineering and management topics – and that’s the main reason for this blog. Besides that, Miroslav has quite a few war-stories to tell and probably far too many books and hobbies. There are also rumors of him being a proficient illustrator, but the origin of these rumors remains a mystery.

– Backend TL@Neon and Dev. Advocate @Holycode

---

References:

1. Managing humans (3rd edition), chapter 18: “An engineering mindset” by Michael Lopp, Apress, 2016
2. Gartner Glossary – Job Shadowing: https://www.gartner.com/en/human-resources/glossary/job-shadowing#:~:text=Job%20shadowing%20is%20a%20type,or%20into%20a%20new%20role