Greeting! My name is Sasha Sakharov, I am a backend engineer and a team leader at Avito.

In business, deadlines and product quality play a big role, so it is important to find the middle ground. There are situations when the product must be released within a certain period, otherwise the company will lose money. In other cases, it is better to wait, but write the perfect code, because due to mistakes, the company will lose not only money, but also the trust of users.

The team lead decides on the terms and speed of work. In many ways, the success of the team’s work depends precisely on the strategy he has chosen. Let’s figure out how to understand when you need to write the best possible code, and when you should add crutches.

Why the choice of approach depends on the specific project

The ratio of speed and quality of work depends on the field in which the company operates and the specifics of a specific project. A scheme that works for one team may not work for another.

The team leader must assess risks and make decisions based on many factors at once: budget, user needs, team work schedule, company management opinion must be taken into account. It is important to see the whole picture (Big picture) to understand which strategy to choose.

For example, banking applications require very strong code. If customers fail to make a mortgage payment on time, for example, or if their personal data is compromised, the consequences will be very serious. When working on products where security is important, developers choose a slow pace. They prefer to roll out updates later, but double-check the little things and minimize the risk of errors and user dissatisfaction.

In startups, on the contrary, speed is important. For example, my friend works for a company that uses machine learning to calculate product discounts by region for different customers. Discounts are often dedicated to holidays or seasonal sales, so deadlines are tight. It depends on whether the guys will be able to provide information to the client in time, whether they will be contacted again.

In my work at Avito, there were situations when I asked the developer to write code faster to guarantee a successful release. “Crutches” in the code are bad, and they will still have to be fixed later. But as a team leader, I am obliged to make decisions that will benefit the team: failing a sprint is not scary, but failing a cascade of tasks for seven different teams is unacceptable.

It is also important to remember that the team also has the right to vote and its opinion should be listened to. You don’t always have to make decisions alone, just because you’re the boss.

Why it is important to understand what pace of work is suitable for the team

In an ideal world, a developer will write code at the speed with which he is asked: if they say that it is needed urgently, he will do it urgently. In practice, it is almost impossible, because all people and teams are different, everyone has their own comfortable rhythm of work.

For example, one person will feel great in a constantly “hot” mode. Yes, it spins like a squirrel in a wheel, but it will show high efficiency precisely under conditions of stress. Developers who can and like to do everything at a very fast pace will be comfortable in the same startups or projects where a high rhythm of work is important. They will quickly get bored and burn out if they get into an enterprise culture where the release is once every six months, instead of once every two weeks.

There are developers who, on the contrary, will carefully understand every detail and check everything again ten times. A calm working environment will be important for such an employee – in a hurry, he is more likely to make mistakes. It will be difficult for a “main” developer in a startup, because the emphasis will be on speed.

Teams, like thinking, are also conditionally divided into “fast” and “slow”, and it is very important that they and the team are ideologically close to each other. The same principle works here: a meticulous and thoughtful team leader will most likely not work with a team of fast startups.

For example, I’ve got on well with Avito’s team now: I’m corrosive by nature, and so are they. If you give them a task, they immediately pick it up and do what is needed.

I also know that if the developer is not given a detailed TOR, he will spend three days researching a poorly described task, writing and clarifying the requirements. Therefore, as a leader, I need to prepare well for each project, so that as a result, developers spend less time on discussions and write code much faster.

Why is it important to understand the problem and evaluate it in perspective

The team leader must be able to assess the realism of the task set by the client or company management. If even because of an interesting and ambitious task you have to burn the team to the coals, it is better to abandon it or move the deadlines forward. Thanks to this, the team will not burn out, and developers will not have to write bad code.

In such situations, it is the team leader who is responsible for the quality of work and the atmosphere in the team. Sometimes it should inspire and motivate, and sometimes it should serve as a buffer that will protect the team from inadequate deadlines and requirements. No one wants to work hard when everyone else is resting. But when the avral at work is justified, it is important to explain to the developers why they are suffering. In such cases, for example, you can ask for an extra bonus for the team.

And it is also important to look not only at the current sprint, but also at two or three months ahead and think about what will happen to the project next. For example, if a manager asks for a promotion, there is a high probability that another one will be needed after some time. Then it makes sense to provide the ability to transfer data in batches. When the business wants to scale the product, you’ll have everything ready.

Now I have the right to choose Avith. When I am given goals, I can discuss them, and not just go and suffer in the name of business. You can always refuse the task – this is a valuable opportunity.

As a result, you need to follow a simple rule: before implementing a feature, you should think about what will happen if this feature takes off and requires development. If the team leader and developers are interested in how the product will continue to live, then it turns out that technical debt can be predicted.

Why sometimes you just have to put up with it and finish the code as soon as possible

It happens that both the ice and the team drown for quality, but incorrectly estimate the time for completing the task. If the deadlines have already passed, you have to come to terms with the fact that you will have to add the code faster. This is Damage Control: an attempt to minimize the consequences of a mistake, to close with some crutches and pass the project. At this moment, it is important to focus not on the small goal – to deliver the task, but on the big one – to launch the product.

To me, such a choice is given quite simply in the process: failure will affect everyone, the product’s performance will deteriorate, and no one will receive a bonus. Therefore, I tend to choose general success – it is important to roll out the product, and technical debt can be worked out later. This does not mean that we always pee on a crutch, but there are situations when we can afford it.

Nevertheless, the ice, for its part, should do everything to prevent such a situation in principle. Because if you tell the developers that you need to deliver the code quickly, then you will be the person who allowed a low-quality product to be made. This responsibility must be remembered.