To be or not to be a team leader – that’s the question

To be or not to be a team leader – that’s the question

There is a stereotype that moving up the career ladder is a natural and desirable process, and that after reaching a certain skill, a developer should move to the next level, for example, to team leaders or software (project owner). In my opinion, this idea is wrong. I experienced this firsthand, and now I want to share with you the story of how I managed a team and what conclusions I made about career development in IT.

Those who gather in teams will understand what pitfalls can await. Those who are already at the wheel, I invite to the discussion in the comments. Well, HR will be able to look at the employee and his feelings from the outside.

How I got into teamleads

When you have enough experience in coding, you want to try something else. It was the same with me – I, as they say, “wanted something strange.” I worked as a frontender for about ten years. At the beginning of this story, he was engaged in the development of the marketplace in a startup. Things were not going well there, the concept was interesting, but it was not possible to interest the market in the startup.

I started looking for offers and found a large developer who was recruiting IT people for the launch of an application for a residential complex. Hmm, interesting, I respond. Had an interview – based on my skills and experience, I was targeted for a developer position, but as it turned out, the company is looking for a team leader with good coding skills.

In the interview, I mentioned that I give lectures on React, so I can explain the material in a complex way and explain some things in a popular way. PZ latched onto these rocks and immediately offered me the team lead position. Mentoring is somewhat close to managing a team, and the transition to a new function for me did not seem difficult to him.

I didn’t ask where the previous team member went. I think he missed the deadline and he was eaten. Looking ahead, I will say that perhaps it was worth breaking the project into smaller stages and controlling it more carefully.

I was very satisfied, I finally grew up, I thought, and in general “Timlid” sounds proud. It’s not like there’s a developer there, they’re gone like dogs… And now I’m a white bone, I don’t need to write code anymore, I’ll sit all day, give out commands, strictly look at the dailies and encourage my subordinates with valuable advice and wise instructions while sipping a smoothie somewhere in the park. In general, everything, life was successful. It was in such a cheerful mood that I took office.

Timlid weekdays

So, it began: the first working week, getting to know the team and the project. I looked at how the products look, looked at the code. Unfortunately, I could not immediately understand what was happening. There is Jira in a sad state, many small tasks, mostly bugs, all in a heap, there are features that seem to need to be done, but who, when and in what priority is also not clear. I began to find out the details by casually getting to know the boys better.

For myself, I decided to select a couple of guys from the developers who teach in a simple and complex way, and also understand the project well, and at the first stage, in case of any misunderstanding, ask their advice. PZ talked about priorities.

For the first two days, team members wrote to me non-stop: what task to take on next, where to clarify the description, here it is unclear, there it is unclear, who to ask, where to look. In response, tired of writing, I simply called them. That is, in reality, I was constantly communicating with someone, someone wanted something from me and asked for something. I just wanted to say to some colleagues, well, get off the hook. I recently issued an assignment, and you appear again and want something from me. Maybe you will take care of her for a while and not bother me anymore today?

It was not at all similar to the mode in which I lived before – I quickly wrote my code, everything works, you can calmly continue to sunbathe and swim.

The understanding began to come that when you are responsible for the result of the entire project and cannot directly influence it, it is a headache for a responsible person without a healthy attitude.

In general, it reminded me of the management of a large ship, as it seemed to me before, only with the nuance that instead of choosing a course, you constantly had to choose which of the crew members would go to plug the next hole, while in the process of plugging, they became not less, but more, and the feeling chaos only intensified. As in the anecdote: there were four bugs, one was fixed – there were six.

Within a week, I began to feel almost in awe of those developers who handled the task well and quickly. I needed to make time for them again.

For me, my favorite developers were those who took the task and did not touch me for at least half a day (or better, a day).

As a result, last week, I thought, I thought, and I decided that that’s not why the rose bloomed that’s not why I pumped hard skills for a bunch of years to finally become a boss and plow as if these 10 years didn’t exist. After thinking for two days, on Monday morning, I wrote PZ that I am not up to the task, I do not feel enthusiasm for it in any way, and in general I am very sorry, but I will not do it anymore.

Apparently, my actions did not seem unsuccessful, and the movement that I managed to create gave the impression of being adequate, but in return I was offered what you would think, yes. more money. The recruiter probably decided that due to the complexity/negligence of the project, I liked the price. But everything was easier, I wanted to continue writing my favorite code while sipping a smoothie on the beach, not all this πŸ˜‡. I refused, and looking back I’m very happy with that decision.

What to pay attention to in the future of the team

I will talk about my conclusions, which I made after the experience of managing a team. In other words, what would I do if I knew everything in advance.

The skill level of the team

I should have wondered what with the self-organization of the team, how dense support the developers need. It’s one thing to prioritize and maintain focus, it’s another to load developers 4 times a day.

Now, I would ask where the previous team leader went, learn in advance about the processes, weigh all the schedules and include critical thinking when I was offered to take a leadership position right away.

Management base

It would have been better if I had trained in team management first. Books, podcasts or a good course to understand which modules to tighten before starting. Before the transition, you can try yourself as a speaker, community leader, organizer.

I did not notice any negativity or doubts about my professional qualities from my colleagues. Apparently, my actions looked quite confident from the outside, but inside I did not feel like a leader.

Adaptation as a leader

I became a team leader without onboarding. I was thrown into the middle of the ocean to swim out on my own. I think that it will take at least a month to figure out how to change from writing code to management.

If the company does not have a mentor or introductions, then the processes have not been worked out. Ideally, you need to learn, pick up starting tasks, be similar and see how the team that took place in this company builds work.

A sincere desire to lead

I could manage if I set myself a goal, but I started to realize that I didn’t like the pace and hustle. I felt sorry for the wasted effort and time compared to my past development experience. I realized that I need to free myself, to break myself further will not lead to anything good.

Readiness to plow

Maybe that’s what being a good leader is. it is a disposition built into the character. I am hardworking. In each project, as the tasks accumulate, I reach a kind of cruising speed, when the tasks are solved simply and quickly and do not cause difficulties. It won’t work out that way. “I will push everyone to work, while I sit idly by” is a mistake. The load decreases at a different rate. It is necessary to work out the management style, technical nuances for a long time, and only then, apparently, it will become good.

Consent to lose hardy

If you are a good developer, you can write code anywhere. And if you are a team leader familiar with the flow of one company, you will still have to delve into a bunch of processes in another. You also forget about development, which is a much more universal skill that is easier to sell (I think so).

Technologies do not stand still, something new appears at the front every year, new approaches, new chips, and frameworks change. You dropped out for 1-2 years, the skill goes away, you slowly start to forget something. It’s as if you’ve become a coach, inspire your wards, rejoice in their success, and quietly degrade yourself.

What would I do differently now?

If I were to do it again, I would take things more calmly, not wait for established processes or “work like clockwork” right away. This would be a good result, for example, in a year.

For a while, giving subordinates a lot of freedom of action (let them pull tasks from the pool to choose from), I would figure out which product or feature is a priority, for what exactly and when I will be asked. Further, based on this, I would plan to load subordinates and optimize processes.

If not him, then who

After tying the knot, I calmly resumed my job search and very soon returned to the life of a frontender. Well, there were (and are) really many vacancies. I am currently making a program for Alfa-Bank employees. For a year and a half, I haven’t even looked in the direction of management. The workload will increase, and the salary will practically not change.

I removed the line “teamlead” from the portfolio. At the interview, I mention that I had an experience, but I don’t want to repeat it. I did not receive rejections or uncomfortable questions because of this, normal developers are always needed.

In the near future, I will remain a developer here or there.

There is an option – to go to tech leaders. Close, interesting. Now, for example, I am developing towards writing middleware (backend-for-frontend). This is a step towards the back, I am beginning to understand what is arranged.

You definitely need to think about the future. It’s okay when you write code at 20, 30, 40. But you can’t write it forever? You will want to reduce the strain on your eyes, change your lifestyle to be more mobile, and in general, sitting all day in front of the computer is harmful. In IT, it is more than realistic to save up for the start of some simple, for example, trading business, which does not involve a large investment in time. In general, I will think in this direction. Thank you all )

Share your career stories in the comments. And see you in the next articles.

Related posts