Hello! My name is Alexander Athenov. I am the lead team for the Order Processing development team at Lamoda. Last year I spoke at TeamLead Conf 2018. The recording of the speech is available here .

In my report, I will tell the story of how I became a team leader, what problems I faced, and I will share different strategies that may seem familiar to you separately. However, I focus on what kind of profit they give in the complex.


')
The report will be divided into 3 parts:

1. In the first part we will discuss a little about the company and the features of our IT. This is necessary in order to understand the context in which everything happens.
2. In the second talk about my way to the company.
3. In the third - about the methods used, their pros and cons.

Lamoda as an IT company

Lamoda is primarily known as a major retailer of fashionable clothes, shoes and accessories in Russia and the CIS. At the same time, few people know that for a percentage or a fixed amount we provide services to various businesses / legal entities.

I will give an illustrative example. Suppose you have a basement for sewing wallets. You have created a website for your products and successfully unleashed it. Many people know about you now, but despite this you have problems with the delivery, storage and communication with customers.

Lamoda can solve similar problems in the following ways:

1. Provide the services of its delivery service.
   
   LM Express is our own delivery service that we have been developing and automating for a long time.
2. Provide communication with the client. For this we have our own call center.
3. Keep the product at home or even sell it for you (commission).
4. Marketplace. Partner products can be displayed in our mobile application, on the website or its mobile version, and the partners do the rest.

The question arises: “How to manage to solve both your tasks and satisfy the needs of your partners?” We have a changing and developing business with our own needs. We somehow improve everything, develop and move forward. At the same time, it is still necessary to correspond to those women who come from outside. It seems that for this you need your own IT, and not a small one.

We are talking about in-house development at all conferences since 2016. We automate all processes ourselves. These are about hundreds of different services: from processing orders and payments to working with address objects and gift certificates. All this is supported by a team of about 300 people.

Why am I talking about our IT and its scale? Because 300 people are many teams. When some teams work on a single technological stack, we try to reuse all these developments. These can be bundles, libraries, technical practices. But we also try to fumble for successful process practices between the Timlides, and I will tell you more about this later.

Key issues

I came to the company in 2015. Three days after my employment, a New Year corporate party was scheduled, to which I decided not to go. My priority was to stay and think about my tasks for a trial period.

The corporate party in Lamoda is a themed holiday for which everyone loves to prepare. Therefore, on Day X, the architect of my department came to work during a parade, in a tailcoat. At that time, our team was engaged in order processing services. It was a monolith on the old Zend1 framework. What did I watch? The guys have prepared a forced release and want something. Having made sure that everything was OK, we got together and went for a holiday.

And here I am. The release went into production with hotfixes, and in front of me was a beautiful 50-inch TV set with some kind of dashboard. On the dashboard there was a chart with the words “Rabbit MQ problems”. It seems that if there is any data on it, it means that something has broken. But I do not know where to look to test this hypothesis.

Perhaps you can look at some logs. However, I am only the third day at work and do not know where they are. I guess I can find a link to the grafana board. Perhaps it is worth looking through it the source of metrics and delve there? Yes, but it’s too thorny. I wish it was somehow documented. And again there is a question: who are all these people who are sitting around? Two or three floors, on which IT is distributed. Everyone is doing something, and I do not know with whom I should communicate if something went wrong. There is no pivot table that I could turn to if I understood that the release had broken. Or maybe there is a person on duty, but I just do not know?
* (of course he was) *

There were other issues. The first and most ridiculous to which we will repeatedly return: “Where is the documentation?”. The answer is simple: at the same time everywhere, nowhere and in the heads of experienced employees. Since everyone went to the corporate party, and I don’t know about where the docks are located, the answer for me sounded like “nowhere”. I had a readme on which I rolled out the project on my laptop. But this was not enough. I wanted to get answers to many other questions. For example, what are the basic rules of “behavior” for a developer?

Let me explain: I decided to request access to the combat system in order to enter the user interface. For me it would be very useful, since my task for the trial period was about processing the authorization system, and I wanted to poke buttons, log in to the production booth. I threw a request to the security service, to which I quickly received a concise answer: “Nah, we will not give access.” It turned out that only real users get access to the combat system: workers of the warehouse, call center, and so on. Since I previously worked in telecom, I got used to the fact that I had access to read and write to the production base of various cellular operators. And here, it turns out, this is impossible. There is a protocol.

In addition, I was faced with many other conditions and restrictions that the team leader told me about. In the early days he dedicated me to many different fascinating moments. This information was so much that not everything could be memorized and recorded.

The following questions of interest to me concern the long run. For example, how and where to grow?

Why is it important? Because already from the start I need to somehow behave. I have come to the post of middle php developer. What should I do next to exceed expectations, and in the future to get a higher grade, for example, Senior? And one more question: “What is expected of me on my current grade?” That is, how much should I be involved in processes such as code review, releases, duty?

All the questions I have listed now were answered by our team leader. The last two, more strategic ones, were answered through the performance review system. I'll tell you more about it.

Performance review

Every 6 months, a person conducts the so-called self review. He talks about the cool things that he managed to do in the allotted time. However, there is an underwater rock. It is connected with the fact that people usually point those achievements to self-review, which they are subjectively inclined to consider as such. It is unusual to think in terms of business, and even if a routine project allowed a company to earn a lot of money, then it could not represent a challenge or interest for a developer. There is a danger that in this review this project will not be listed.

The next stage is a peer review. Then follows a series of commissions, where there is communication between team leaders, department heads, SRT, and, if necessary, HR director. Then a message about the results.

What are the possible outcomes?

The first option: a person managed to make six months worse than it was before work began. It seems it's time to say goodbye. It happens very rarely, but we will be realistic - it happens.

Another option is a deuce. It seems that something was not enough. Maybe speed, predictability, perseverance. Something needs to be improved.

Three - what was expected, then received. A person works at an adequate pace and in all respects corresponds to his grade.

Four - did more than agreed. Candidate for increase of a post / salary.

Five - wolf wolf. It seems that it is time to raise, give bonuses and so on.

I went through several iterations of this review myself. Previously, it was held every quarter, which was not very convenient, because in 3 months it does not always happen that an opportunity to prove oneself happens. Now review occurs every six months.

Thus, at first I grew from senior developer to senior. Then my team leader decided that he now wanted to work more with the equipment and switched to the position of technical leader (architect), and I became the team leader.

So, what is next? I need to do something, somehow get settled.

The first thing you encounter is the same questions that we talked about earlier, only now a little bit at a different level. That is still not clear: where is the documentation? Now I need to somehow communicate with other departments, communicate with other leads, architects and someone else, think at a higher level. But at this very level of documentation, probably not either.

Another point is the same “basic rules”. What I can?

Probably, I can monitor the implementation of tasks, do a code review. Perhaps I now have the power to change processes, somehow in my own way to communicate with people.

How and where to grow? This question does not go anywhere, because then you may want to become the head of the department (group lead).

Well, the question - what is expected of me, also seems to me quite understandable.

And now you need to be able to answer all these questions not only for yourself, but for the whole team. In my case, the team was recruited almost from scratch. It turns out that for five or seven people I have to say everything, explain, set goals. It takes time and effort. Such things need to plan and think through. So what is the responsibility of the team leader?

What should a team leader?

First of all, it is work with tasks : their setting, adjustment, description under the grade of the person who gets the task. For example, for a junior, I would prefer to make a very detailed description and I would expect him to write the correct code and tests. And senior, I will tell you a technical or business goal, and he will be free to decide for himself how to achieve it. In any case, all this takes time.

Of course, you need to extinguish code review when conflicts arise during it. Monitor what happens, move tasks according to status. I also perform release engineer duties on a regular basis. It is often necessary to think about how our deployment affects all others. The service I deal with is order processing. It is associated with approximately all Lamoda systems and, accordingly, is able to affect many business processes during its release.

Another point is related to this monitoring, alerts and watch . If there is some kind of business feature, you need to keep track of it, introduce new metrics, hang notifications for it, report to the support service, and so on. These are all questions of architecture. I currently have no dedicated architect in the department. I perform his duties in those cases when I need some specific solution within a specific task / project.

Still need to pay attention to communications . This includes personal meetings, which are held about once every two weeks with each developer; retrospectives, planning, communication with managers and other departments. But it would be nice not to rot.

Many people say that after 10 years of development it would be great to get a “management to development” ratio in the region of 80 to 20. Even this is not always achievable. As a result, you inevitably lose your expertise and fall out of current trends. It is necessary to continue to grow further.

There are possible strategies for how you can grow, in terms of your position. In the next section we will talk about how the rotation of roles in a team helps to increase bus-factor.

Rotation of roles

I will bring up to date those who do not know, and tell you what bus factor is.

Bus factor is a number that says that if a certain number of developers “hit the bus”, then the work on the project will rise. It can manifest at various levels. For example, it may be a bus factor for a particular complex element of the system.

Suppose we have a case in which we need to rake out some kind of reporting system. The developer spent 5 days to do this. The bug was complicated, but it was fixed, and everything became good. Then there is still some problem in the same module, and the same developer turns out to be on sick leave. This means that the next person should spend the same amount of time trying to figure out the problem. You will have to understand from scratch, because there is no documentation (ha-ha).

What will be discussed next is just strategies to increase bus factor. And they will converge into one, rather pleasant picture with all previous duties of the Timlid I spoke of.

In addition to documentation, you need real experience. That is, you need a team that has already managed to touch different parts of the system, and is now ready to cope with any tasks. But if the team just got together, then all this will not come from nowhere from scratch. My main goal is to tell you how you can combine several different approaches that will allow you to close problems with both documentation and experience.

Support engineer

Everyone heard about virtual developers. But it will not be about VR-kits and not about people on the remote, but about the role of a support engineer.

Who is a support engineer?

We have a guy who makes support backlog. He came to work, he has no single task. He opened a backlog for support in task tracker (Jira), and there problems sorted by criticality. He took the most important and begins to repair. After all problems are solved, write down why it broke and how to avoid it in the future. If he doesn’t have another support (this is funny, because the support never ends), he looks into the technical backlog, which is already quite large.

Small distraction: this is a system for a half hundred thousand lines on the old Zend 1 framework. The previous architect of the team once said that according to our system, we have a debt of this size - this is not technical debt, but rather a technical mortgage. Hence the title of the report.

If there is nothing to do, the support engineer can take from there some kind of non-priority task, which it is not a pity to quit and return to the newly appeared support. So it usually happens. And he has not been doing this for more than a week, because it would be a direct path to frustration. If you have been doing only the support raking for the whole two-week iteration, it will demotivate you greatly. You repair, repair, repair, and there is no end to it. For this reason, every week we transfer the role of a support engineer to the next person.

Release Engineer

There is another virtual position that is very convenient for unloading a tmlid - this is a release engineer. He prepares releases for pre-scheduled fix-versions, collects branches, prepares builds, runs all tests. If tests run automatically, it simply controls the result. In his own area of ​​responsibility to choose how it all nicely roll without downtime and special effects for systems dependent on us.

It so happens that we need to communicate with other teams before the deployment, to warn them about the changes. As a result, the release engineer rolls everything out and looks to see if anything has been smashed. We use for this, Sentry , Prometheus , Icinga , we look at Elastic, with the help of Kibana . The release engineer decides what to do if something goes wrong. That is, it is his responsibility to decide whether a hotfix is ​​needed, or if we all broke, lose money, and need to roll back. The decision to rollback is taken only as a last resort, but it also happens.

He (the release engineer) records the problems that arise. If something ripped, it would be great to learn from your mistakes. For this, it indicates the release date and errors that led to the problem. This enables the next release engineer to look at common problems and avoid them. Well, yes, he has not been doing this for longer than a week in a row, because collecting a release is expensive.

If the release is large, then half a day takes off easily and it is very difficult to have time to switch to your tasks during the breaks. For example, you run some build that takes 20 minutes. While the assembly is underway, you can smoke or think about life. But if you returned to the task, and the assembly ended successfully, you need to switch again. In general, this is a rather dreary process, pulling out of normal development and not allowing to enter the stream. For this reason, the next week the release engineer is another person.

Techlide

Another more interesting virtual position is the technical leader.

An architect (sometimes called this way) engages in battle when a major important task is found or a new project is launched. This means that he takes responsibility for the design, development and launch. He is given the right to communicate with the team leader and the team manager, to make technical decisions and to transfer the responsibility to document them. If some kind of rubbish happens on the launch, then it records all the problems that have occurred and their causes in the same way as the release engineer or support engineer does.

findings

What do we get in the end?

Rotation of roles in a team for a long time (at least six months) makes it possible for even an inexperienced junior to acquire the skill of working with various parts of the system and types of tasks.

In the beginning, I said that documentation and actual experience can help with the solution of typical tasks. After applying the described practices, it’s not a fact that you solve the problem of documentation, but a high-quality and diverse experience will be gained by all members of the development team. With a prolonged rotation of virtual roles, a person has time to play the role of support engineer to touch various parts of the system. As a release engineer, he learns to deploy, communicate, observe, make quick decisions. If he got the role of a technical member, then he is prepared to independently drive larger and more important projects.

From this point on, the team leader can and should delegate his tasks to his subordinates, because, if you remember, the team leader has a task not to spoil himself and grow somewhere.

Thanks to such practices, it is possible to finally give someone a part of their work. For example, releases. It is 4-8 hours per week, which are suddenly released from time to time. Now you can spend them on developing, reading articles, solving other problems. A big mistake would be not to forget it in the calendar and spend it on not the most useful meetings. Although, as a rule, this is the case :) Now the team leader can rejoice, as he has the opportunity to be less nervous and trust his employees part of his work. If something happens to him, the projects will not stand.

As a result, we increase the bus factor of the tmlid. The team, in turn, can be sure that if something went wrong with the team leader, then any of them will be ready to take on a piece of work and cope with it.

Of course, there are limitations. Such an approach is impossible if you do everything alone (person-department). If a couple of people are subordinate, then it is already possible to rotate duty and releases. Three partners and more - even better.

In my case, there are 5 developers, three of whom share virtual roles. The other two are just engaged in development, new features. They are not involved in releases, support, and so on.

Another important factor is time. You have to endure until the moment when the rotation of roles has the proper effect, and you get a team ready to perform tasks that usually lie within the competence of the team leader. The problem is that we use time as a very accessible and replenishable resource. But this is not at all the case. You can assume that in six months or a year the developer will somehow “swing” himself, get the necessary experience and be ready for duty and something else. But this may not happen, and, as a rule, does not occur if the situation is set to flow. The flow of tasks may be such that he will not have external motivation to develop as needed. And it is precisely the interleaved virtual roles that give a chance that you will be able to help the members of your team to fully develop and move forward for the next grades.

In the end, it all comes down to one very specific quotation: “The leader’s task is to have more leaders, and not those who blindly follow the leader . ” I believe that the use of these tools will help you grow for yourself, for a minute, a team of team leaders. This will allow you to move on in a professional and career way. For the company, the team and the project, this will make it possible to exist comfortably. Also, you can finally go on vacation.