Team Lead VS Engineering Manager

Hello! My name is Vasilisa Versus and I am a former three-time CTO in small startups (20-50 people), as well as head of infrastructure or development in companies such as Yandex and Sbermarket

Today I really want to share a few thoughts on the topic of career development. And the missing puzzle pieces between the position of team leader and the desired position of Service Station.

Anticipating comments from incompetent people, I would like to clarify right away that everything is conditional, and the “badges” are just tags as points for googling, filtering vacancies and a kind of start for building expectations. And of course, I am sharing purely my experience, I am sure that I am wrong and in general I am waiting for your comments!

I recently wrote about my journey from TL to EM. Subscribe to my public in tgthere will be a lot of this, and we are just getting started.

Team Lead

Let me try to formulate in my own words what a team leader is: a person whose responsibility is to distribute the tasks assigned to him between team members, monitor their implementation and, of course, report to managers and peers about the process.

Perhaps I can also highlight that the lead is expected to complete work tasks, organize a certain work process, resolve conflicts and mentor participants.

Why does an engineer need leads?

IMPORTANT! Everyone answers this question for themselves! I'm just fantasizing… So Vasya sits and writes code, he likes everything and, in general, expectations are met for all parties. BUT at some point, he develops an opinion on changing the process or a desire to help the manager with organizational issues. Somewhere at this point, a junior lead appears.

You won't necessarily be leading a team from the first second, the transition process can take years and the first step is going beyond the linear execution of tasks in the course of the desire to do something different, more complex or more focused on the result in the future, and not now.

Actually, speaking about myself, it happened to me rather from the opposite. I asked too many questions just trying to sort out bad tickets from the BA and at some point I was given a couple of interns with a task of the urgency level “yesterday”. I had to wriggle out. And after such stress and a series of successes, how can you even return to a position of quiet calm coding? Sign up for my courses on how to overcome the flying squirrel coder crisis (joke). I tried more than once, but the constant fires somewhere and my love for solving problems played their role.

I think it's better to move not from fires, as I did, but in the course of curiosity and the opportunity to gradually try out the functions of a team leader. For this, you don't need to do anything other than just talk to your current boss about taking on some of his tasks. Just take the initiative and continue to study how deep the rabbit hole goes.

What's wrong with lead position?

To move towards a team lead, you don't even have to be a senior, in general, this can happen even with an intern. The only question is how effectively you will perform these functions. And I assure you, it is rare that they expect you to be an excellent student in everything, rather a good student or sometimes a C in something, lol.

And this is not even a problem, just a teaser. In fact, the lead combines the competencies of different developers, performs some QA functions, often replaces the project manager, and sometimes even the designer or product manager. You will definitely play the role of a business analyst at least to your boss… And let's also remember the main responsibilities associated with people management, i.e. hiring, providing good conditions, even emotional support, at least to some extent critical, in such a position.

Wow. So much stuff in one person. The good news is that all of this will be done extremely mediocrely. Oh, that seems like bad news, but I have another bad news that you will rarely have the resources to develop in depth in one of these directions. When you take such a role, you most often move in width, closing the gaps of your team at first and over time, and if you get used to it and want to master it, you will learn to competently select personnel, focusing on coordination, and not closing the holes yourself.

Therefore, I can immediately give a recommendation to be less critical of yourself, and also give yourself space to replenish resources. Support your colleagues and do not hesitate to ask them for help. For me, this was the first step to learning how to delegate tasks correctly. And move on.

Engineering Manager

Key difference Engineering Manager (hereinafter EM) from the lead that EM is a specific function, such a person will be closest to classic developers in the world of management. With a very clear area of ​​responsibility, as well as hard skills.

I will make a reservation, this is so on paper, but EMs often have their own teams and are very close to team leads, at least if you do not habitually move in breadth, then gradually in any company you can come to a good hybrid of people manager and engineering manager.

Why is EM cool?

Let's start with the fact that EM is aimed at improving the efficiency of the development process. Let's consider this its main function. The better you are as an EM, the better the selected indicators will be. I think this is a killer feature. Finally, you can focus on your specific development and apply your hodgepodge of knowledge in a focused manner.

I would also like to note that in addition to focusing on performance metrics, EM will ideally not be a people manager for a specific team or project, but rather will horizontally help build processes and periodically optimize them. Taking over some functions in building regulations, rituals, and also taking on tasks for designing the application architecture.

The latter is generally difficult to fit into the overall picture, but let me be straightforward, as the code is reviewed, those components that
reuse, yes even in general how teams are divided among themselves, it's all about the general process of interaction and the bottleneck will often be somewhere here, and not in whether the agenda is described for the daily. Of course, the EM will ideally work in tandem with the Architect and act as his consultant in what resource limitations we have and on the other hand will be a conductor of his ideas, gradually bringing elegant architectural plans to life.

Returning to everyday tasks, in general, your job as an EM is to look for growth points, select ways to observe them, and move towards this in different ways. This is mostly project work, work with documentation and processes, sometimes with automation, most often it is work with people.

What Happened Next?

Okay. Glad we're finally here. Are you a lead yet? Or just a developer who dreams of becoming a CTO? It doesn't matter.

Let's get straight to the point without any unnecessary snot. We'll take the worst-case scenario and in the points where you're lucky, be more happy about the shortcut, but try to look at the big picture to understand which tasks around you are closer to the EM role.

Point 1. First, you need to free up as much of your time as possible to move to a new position. You need to start negotiating with peers and leads right from the start about trying to take on new functions. Negotiating and selecting tactics in interaction with people is one of the basic hard skills for EM. Prepare a thesis base, try to look for compromises and benefits for both parties. In general, start reading and watching something about negotiations. This will definitely be useful and, I hope, interesting.

Point 2. Okay, what should we agree on? In general, I recommend trying to document your development process in advance, for example, for onboarding purposes, you can even offer it to your manager. It will definitely be useful for newcomers in the future, and will also help to see holes in the process. In what format should all this be written down? What is the end result? The right questions that I recommend you discuss with your colleagues. I will say this: the more you can describe in less time, the cooler. Again, I recommend googling and stop accumulating dissatisfaction, let it be expressed. But remember Point 1.

Point 3. When you have managed to describe something, try to calculate how much time and at what stage from when and how the idea comes to when it ends up in production. Find the point where you could have the greatest effect. For example, is it often some story with CI and code style, or maybe frequent return of tickets from QA can be prevented by tests? Again, document your thoughts, at least in some form, and do not be shy about sharing them. I am sure that the fear of being ridiculed and condemned is only in your head, or you should urgently look for a new place if in fact your initiative is ready to be rudely cut off.

Point 5. Sell the idea of ​​improvement as in Point 1. You can't just give up and despair. You need to study possible strategies and time after time look for those improvement points in the process of negotiations that your manager or his manager will accept in extreme cases. In the secret fourth point, I would suggest sometimes trying to include such optimizations in your linear tasks. Together with some expected refactoring, you can offer the team to do some additional tests, as an example. And if you manage to create a real case from this. Where you can show what your process looks like from the outside, what the numbers were before the change and how the change made the work process better, then the real point 5 will already be a simple story.

Point 6. Don't rely only on your own resources. The main thing in EM work is to define the problem and make it simple for other people to solve. Try to find strategies for selling the solution to other leads and developers and even other roles. Go beyond simple coding and..

Point N. Your goal is not just to grow in the hierarchy, your goal on this path is to find your own strengths in helping to unite people. CI, metrics and regulations, development processes, negotiations and so on are just your tools, in the next steps you will be able to do much more. The main thing is to believe in yourself and not despair.

Instead of an afterword

Of course, no one likes people who poke at problems, but believe me, those who can explain that the problem is actually a trifle and can be solved by everyone – are loved by everyone. Didn't you watch the Futurama episode where mini-copies of Bender were able to overthrow the monster thanks to Fry? Why did you watch cartoons then? Enough. From this point on, I wish you good luck.