Why I almost ruined my career as a team leader. 4 tips for beginners
I have been working as a team leader for several years now and I can say with confidence that I really like this direction of development. And I remember, I almost ruined my career as a team leader at the very beginning, at the transitional stage, the developer is a team leader. I then worked as a developer in a large company and, in general, I liked the work. Our team had a nominal team leader – a good, sincere person who really liked poking around in his pieces of iron, and in the life of the team his participation was limited only to questions on the daily “how are you?”. In general, problems in the team accumulated, and no one dealt with them, and this bothered me. As a result, I was offered to try myself as a team leader. I am telling this story because I started my journey with great enthusiasm, but after 3-4 months I almost burned out and wanted to return to development or quit altogether. On reflection then, I decided that I could not leave so ingloriously and should try to understand the situation and find another solution. I have formulated 4 main reasons for such a rapid burnout that happened to me during this transitional stage. I managed to find a solution to these difficulties and continue to work.
So, four problems for a beginner team leader:
#1 Still trying to be a developer.
When a developer becomes a team lead, it means that your team now has one less developer. This is a key point that you need to clearly understand in your head, and also be sure to discuss with the business. Team leads can have different attitudes towards writing code: someone writes a lot of code (playing coach, although I do not share this approach), someone writes a little, and someone does not write at all. But, in any case, most of your responsibilities are no longer directly related to development. It is clear that you want to code, because we are technical specialists after all. But you no longer have to take on tasks from development that have a hard deadline. When you have free time from your main duties (now leading ones), you can code technical debt, bugs, architecture for the future, something else that has no execution time limit. The fact is that your working day becomes unpredictable: you can sit all day on calls, on emergencies, etc. If you take over the development, there will come a time when you will miss the deadline, or the team will actually be left without a lead, because you will only be coding as before. I was smart enough not to take on as many tasks as I did when I was a developer, but I still didn’t keep up and had to overwork a lot to finish tasks on time, which resulted in fatigue. Now I don’t take on business tasks at all, I don’t try to replace developers, etc., all tasks are planned based on the current resource of developers. By the way, in a project you start to find a lot of things that you can code, but that you don’t pay attention to, being overwhelmed with business tasks.
#2 Thinking you’re not doing anything useful
When I just started working as a team leader, I began to notice that there are days when it’s not at all clear what, in fact, I did in a day. You start to analyze, you realize that you spent the whole day in an incomprehensible place, and did incomprehensible what. Those. at the end of the working day there is no tangible result. And this thought bothered me very much, it seemed to me that I was doing nothing or doing, but useless things. When you write code, everything is simple: the result of your work is obvious. In general, you just need to accept the idea that you will not always have a tangible result of the work done at the end of a working day or even a week. And that’s okay. The result of your work will be reflected in the team and the product as a whole only after some time.
#3 Don’t plan
As soon as you become a team lead, you begin to interact with a large number of other participants who all need something from you. This is normal, because, as a rule, the team leader is the entry point to the team, and everyone will go to him with questions. I remember my first weeks as a team lead. It was a revelation for me how many more people are working on the project with me. I ran like crazy to help everyone with their questions and problems, but still didn’t have time to process all the “incoming requests” in a day, and besides that, my immediate duties in the team were piling up.
Realizing that I now need to plan my time helped me solve this problem. And 99% of the questions that come to me do not require an immediate answer.
I got myself a separate board for my cases, incoming questions, thoughts, etc. This is a kind of personal backlog that I work with, regularly clean and prioritize.
What I keep in my backlog:
To-do list. I have this list in the form of a simple kanban board: to do, in progress, ready.
The incoming questions are simply a list of cards that are sorted by creation date. I also call this column “distractions list” – a list of distractions. When they come to me with some question or request, if I’m busy now, I copy the entire message to the card, and I answer the interlocutor that I’ll look a little later, if it’s not urgent. When I have free time, I go through this list and decide what to do. I can immediately return to the colleague who asked this question, or add the task to my to-do list, delegate, etc. This distractions list allows me not to be distracted by “external requests” from current affairs (I can be in a meeting, interview, review, etc.), but not forget, but to solve these issues at the right time and with the right resources. By the way, I have a distractions book for personal purposes as well. I write down all sorts of ideas that pop up in my head every now and then, but which there is no way to deal with at the moment. This helps a lot not to forget and think at your leisure over the idea that has arisen.
Ideas and thoughts. I usually put some thoughts in here, which will need to be thought about or shared at an appropriate time, such as at a retrospective.
This is about things that are not tied to time. To manage your time you need to keep a calendar. I have allocated slots in my work calendar for my tasks, team meetings, etc. All my employment is reflected in the calendar. If someone wants to make an appointment with me, he just looks at the free slots in my calendar. Personal slots help me not to accumulate “internal affairs” that concern only me and my developers. Now I have 2 hours a day for personal tasks, that’s 10 hours a week, plus 6 hours a week for regular team meetings. It turns out 16 hours a week for the team and 24 hours for “external” questions. Of course, not always and not all 24 hours are filled with “external” meetings, but still, usually my calendar is packed very tightly, and without personal slots I would not have time to do many things, as it was before I started keeping a calendar.
#4 Being a bottleneck for the team
When I first started, I tried to control everything and everything. Such control resulted in overwork, stress, etc. I dived deep into all the developer tasks. Without my approval, no one could do anything. As a result, I spent a lot of time diving into details, building architecture, code reviews, etc. And the team was helpless, often idle and did not develop. I thought, because I am now responsible, I must carefully check and control everything. And I didn’t want to hear about delegation of tasks. With this approach, everyone suffers: the team leader cannot relax and forgets what a vacation is, and the developers stop developing, start getting bored and leave. I felt this problem especially sharply when the team needed to be expanded. When you are the leader of a small team (2-3 people), you still manage to control everything. But when the team grows and becomes 10+, you get into a rush, because this approach with overprotection does not scale. Now my main task is the development of a team that is always able to scale. I no longer dive into the details of the task, if there is no urgent need, and I leave many technical solutions to the developers, which has a positive effect on their skills and responsibility. Ideally, when the team can work without a lead. In the book “Do it like Google” it is just very well described. I recommend reading.
A little advice about this topic:
Try in the first 6 months. choose your deputy from the team, who will replace you on vacation or during illness. I want to note that the appointment of a deputy has nothing to do with the delegation of tasks. You can delegate any task to any developer (for example, send it to a meeting instead of yourself). The deputy should be able to keep the team functioning in your absence, so that tasks are done and releases are released. Whom to put as a deputy is up to you, I advise you just not to forget to synchronize your holidays.
Actually, that’s all. The solution of these problems allowed me to adapt to a new role and begin to develop in this direction in a calm working mode.
My telegram channel https://t.me/ar2code
