One day of remote team lead on the backend

Hello, Habr! I’m a remote backend developer from Maxilect. Now I am working on an internal company project, which we are implementing together with a foreign partner. Anything can happen on your own projects with high loads and limited server resources. Sometimes we have measured work, and at other times we burn in production fires all day. But unlike many other projects, there is freedom of choice of architecture, and all responsibility for the technical decisions made is on you. Each of your improvements can lead to the fact that it will take one more server to process incoming traffic, or, conversely, one less. It is both inspirational and affects all of your work, right down to your daily routine. Continuing the story of my colleague from the front, in this article I will tell you what my working day looks like.

My schedule is hardly standard. I am a team lead, but I do not see myself as a manager in the future. At one time, I already led Java development in one of the offices of a large telecom, but I realized that I was more interested in programming. More than anything else, I enjoy solving technical problems. And I agreed to the status of the team lead in Maxilekt only because in this capacity it is possible to influence the adoption of technical decisions more strongly. An ordinary developer, of course, can express an opinion, but the final choice will not be his. In this sense, his hands are tied. And the team lead has more freedom of action, and I like that. Observing how our project is developing, I wanted to solve the accumulated problems – I like to make good systems.

I have already mentioned that I do not plan to develop further in the managerial field. The further you go, the less time you spend on what is most interesting. And I don’t see myself in any other role. And in the labor market, as a senior developer from the region, I feel more confident: even in Krasnodar, in the office, you can quickly find a job, not to mention the multitude of remote offers. In this sense, it is more difficult for managers. So I do the tasks of the team lead, but I try to keep the maximum connection with the development.

7:00

I am a morning person, I wake up with the sun at 6 or 7 in the morning.

Morning is a great time to think about an action plan for the day ahead, to put tasks on the board in order. At this time, the whole world is still asleep, and I can in a calm atmosphere solve some of the most important work issues, including technical ones.

10:00

At 10 am we have a daily with the team. We’re going for a maximum of 15 minutes. If the meeting drags on, the participants become distracted, so I deliberately stop all the protracted discussions. It is better to schedule a separate meeting for such topics, inviting only those who are directly affected by this issue. There are many people in the team, everyone has a different profile, so this is a huge time-saver.

On the daily we talk about who did what yesterday, what problems they faced, what they will do today. I usually speak first – I bring the latest news about the project, for example, what is happening in production. The team solves difficult problems and does not always see the result of their work, so I try to fix it. Let’s say that during the day we launch Clickhouse on new servers, and in the morning I talk about how many percent of the CPU load it needs in real operation, how many thousands of messages per second it processes. I also talk about bugs – for example, quite recently we had problems with Kafka (we ran into a bug of Kafka itself), so on a daily basis I could not help but warn my colleagues about how this bug manifests itself.

If, in parallel with the activities of the team lead, I manage to solve some development tasks, then I also talk about them. Well, after that I will give the floor to my colleagues.

10:15

After the day, the team goes to work, and I can say a third of the working day has already passed – it’s time to take a short break. I usually go out for tea and then go back to work.

In my team, I try to minimize the number of meetings and meetings. Calls distract developers, take them out of the flow state, and severely reduce the speed and quality of work. Therefore, outside the framework of the daily daily, we call up only if someone is faced with a difficult problem that cannot be solved without a colleague. In other situations, we create chats for the required number of people and try to resolve the issue there. But some meetings, conditioned by the work methodology, are inevitable. We need to plan a sprint and do retro.

We live in two-week sprints. Releases are released on Mondays every two weeks. And in the first days of each sprint, we are planning the upcoming tasks. I usually put it on in the morning while everyone’s head is still fresh.

On the eve of planning, I talk with a foreign partner to identify his main wishes. In addition, we get tasks from the backlog. During planning, all these tasks are brought up for general discussion. Usually, tasks come to us in English with explanations in the language of business, while during the discussion I try to explain in Russian what they want from us. We decompose these wishes, evaluate them and see if they all fit into the next sprint. If at this stage it turns out that we have accumulated too many tasks, the subtasks with the lowest priority are sent back to the backlog, and I subsequently agree with the partners.

13:00

I am not particularly picky about work conditions and life schedule. I don’t have a hard lunchtime or ritual that I would use to unload my head. But in summer, at lunchtime, my wife and I sometimes walk along the coast of the Azov Sea. We have a small apartment on the beach, where we come in the summer. Sometimes in the middle of the day we walk along the shore to have lunch in the dining room – it turns out to be a great walk. In winter I work from Krasnodar, there are no such opportunities.

14:00

Throughout the entire workflow, I stay in touch with the team of the mentioned partner. As with our team, we only call on urgent matters, for example, problems in production. Let’s say the number of clicks drops sharply compared to the previous days. In this situation, I connect and see what happened there. In order not to jerk my team once again, I do not connect developers and testers to communication with a partner. If their help is required, I formulate the request in the form of a finished task.

Although most of all I love solving technical problems, as a team lead I very rarely sit and program something. Usually I spend all day solving all sorts of issues – from installing specific versions on a test bench, to introducing new technologies. This is a huge range of tasks. For example, we started introducing testcontainers – we connected the library. Locally, everything works for developers, but there were problems with GitLab (when we push our code to GitLab, it also runs tests, and they did not work there). The developer himself could not solve the problem due to the lack of access to the GitLab configuration, so I had to connect here. I didn’t have access either, but with the help of my colleagues, the issue was resolved. And such tasks fill almost the whole day.

A separate pool of my tasks is processing merge requests. As tasks are completed, new features need to be integrated into the master branch, and so that nothing breaks, I study each such request very meticulously – I consider it almost under a magnifying glass. Sometimes I ask colleagues who know this or that piece of code better to connect. Sometimes this causes new discussions, so that everything is merged for a long time. But this way we can be sure that after enabling the features in the master branch, everything will be fine.

17:00

As I said, we live in two-week sprints, releasing on Monday. On Friday night at the end of the sprint, I create a meeting for the team – we are doing a retro, summing up the past two weeks. The results of each retro are reflected in Confluence. Naturally, the problems that are highlighted at these meetings, we try to solve as far as possible.

19:00

I do not have the hard end of the working day, which is usual for many. I know that it would be nice to have the principles of distinguishing between work and rest, but this is how I used to live. If there is an interesting task, I work. I have had such a schedule since the first years of the University, when I studied and worked at the same time. Evenings, as well as Saturday and Sunday, I see as a good time to put things in order.

22:00

Since I get up early, the evening is short – usually by 10 o’clock I’m already asleep, so that in the morning I can return to interesting work tasks. It inspires me. For example, right now we are implementing ClickHouse. In this system, many things are done outside the box, so it is interesting to work with it. Our case of using an analytical database almost ideally falls on it – as if ClickHouse was made for us. Such tasks keep me confident that I am in the right place.

The author of the article: Andrey Burov, Maxilekt.

PS We publish our articles on several sites on the Runet. Subscribe to our pages in VK, FB, Instagram or Telegram channelto stay informed about all our publications and other Maxilect news.