"When control is not from above, but appears inside you": about JS-development in SEMrush

At the opening of our conference HolyJS from SEMrush, front-end developer Anastasia Manzyuk appeared on the scene, and in her welcoming speech she mentioned an amazingly high level of autonomy within the company: each development team independently makes many decisions that in another organization can be “lowered from above”.

We wondered how it affected the development, and we asked Anastasia a few questions about this and, in general, about her front-end work at the company.
')


- What do you personally work at SEMrush?

- I am from the infrastructure team responsible for the development of various internal services, for example, a service for working with user data.

Our customers are other teams of our company (developers or Sales). For them, we make tools that automate their work.
Often we work not only on the dark side of SEMrush, but also come to light: we are engaged in various improvements that the user sees. They are associated with his profile, authorization or registration.

We also help another 27 development teams in solving some global tasks, but this is a slightly different story.

But it is worth noting that more often in our company one can encounter a representative of the development team, whose service is being created for our external users - marketers and not only.

- And what is the specificity of the work on the "dark side", what is it like - to develop for your own?

- I think that the most important difference is the speed of receiving feedback. When your customers are your colleagues sitting in the next room, the feedback comes almost instantly. You can often get a request for some kind of new functionality right in the corridor while you go for tea.

Our colleagues also give very constructive advice, immediately with suggestions how this or that problem could be solved - this is very valuable, we try to use it, and it helps us a lot.

The second noticeable difference is metrics. Working in the product team, you can track the growth of users, how many of them use more and more functions, who thanks to the new functionality goes to broader tariff plans.

In the case of internal users, it is a bit more difficult to keep track of such things, because the dynamics will no longer depend so much on the quality of your product. Yes, you can follow what functionality went steeper, but again, how to understand how much money it actually saved or brought the company? This is where metrics are always a bit tricky for us.

Someone might have thought that when the end user doesn’t see your work, it’s a little disappointing. But in the area of ​​responsibility of our team there are services on which the work of many other products directly depends. Therefore, if something goes wrong with us, the user will definitely notice it. So we definitely do not feel such regrets about this.

And in everything else, as it seems to me, this is all very close to the work of the product developer. It is still important to monitor the quality of the product, ensure that the service is convenient for the user, and the new functionality is delivered on time.

- Is “development for developers” different from “development for Sales”?

- There is an obvious difference that often developers do not need an interface, only an API is needed. But, in my opinion, the main thing remains the same: it is important for both the developers and the Sales team that the service is stable, fast, and easy to use. Therefore, projects are written with the same requirements for them.

- As for the “autonomy of teams” in SEMrush, for starters, let's ask this: in the end, the stack of technologies used in the company turns out to be very diverse? What is used most often?

- Indeed, since the team chooses what it will use, and we have already 28 development teams, we have a large enough technology stack. The list covers almost all popular frameworks and libraries, I will try to list the most frequently encountered ones: React, Redux, Mobx lead in new projects, Vue and Angular are found, someone writes in TypeScript. Some teams use Saga. Have experience using Node.js on the backend. In services written a little earlier, you can often find Backbone.
Among collectors there is also a free choice: from grunt and gulp to webpack of the first and second versions and babel.

- What exactly are you working with?

- In new projects, our team uses React / Redux, webpack, babel. The choice for such technologies fell due to their popularity in our company - you can always get good advice from colleagues, or find it among a lot of information on the Internet. In some older projects, we often encounter Backbone, gulp, and grunt.

- Relatively speaking, usually in a company of this size there is a “big uncle” who thinks about boring things like backward compatibility and does not allow teams to play with shiny new things. And in your case, this uncle is not. What does this lead to, how often do you have to “beat your hands” in order not to play too much?

“I think that even in companies with technical control from above, developers are thinking about backward compatibility and other“ boring things. ” Just the responsibility for the final product lies with one person.

For some reason, when they find out that we don’t have that “big uncle”, many people begin to think that we have complete anarchy here, everyone does what he wants, and in general it all looks like some kind of zoo with rabid animals.

Not really. It is necessary to understand: when there is no such control from above, it should appear in you and in each of the developers. You yourself must become a "great uncle."

Because when you know for sure that it is you who are responsible for everything that happens in your product, you and the look at all these newfangled things change. I don’t want to drag everything into the house, I want only the best, most reliable and proven. And it becomes not only the priority of the company, but also your personal priority and even desire.

Naturally, new frameworks are coming out, but who prevents to touch them first on something small, maybe not even on a user? Usually, this is what happens: I tried something simple - I dragged out, shared my experience with my colleagues, found out that you are not alone, and here you can think: “Isn't it about time to use it somewhere else? tasks.

- On the issue of “sharing experience with colleagues”: since you have different teams with completely different knowledge, how actively are they exchanged within the company?

- We have a practice of sharing knowledge, the company is trying to develop it and strongly motivate developers to participate in it.

A couple of years ago, we just had meetings when someone said: "I want to tell everyone about this cool thing." Interested gathered, there was a report.

Then, in order to make the process even more active, we started a board on which any person from the company can hang a sticker with the subject of a speech, which he would like to tell or listen to. It turns out two columns: "I can tell" and "I want to listen." Supply and demand.

The performances take place about once in a week or two, and often they are really useful. Someone tells how to introduce new tools. Someone about some difficult task: why it turned out or not, what conclusions did. Often there are reports between different guilds: QA tell how to write auto-tests, front-tenders - how to curb your first <div>.

Some teams inject this kind of thing inside themselves, so that there is no situation when the only QA is on vacation and you don’t know what to do with the tests until it is gone.

To make it more fun for us, even pizza is brought to such reports, and knowledge is assimilated at double speed!

There are still situations when you do not know how best to solve some problem, but urgently, there is no time to wait for a report. For such cases, there is always a thematic general chat, where you can throw a cry and ask if someone had any experience in solving such a problem. Very often someone is.

And if not, then this is a great excuse for everyone to tell in a separate speech how it all ended.

- Is there a rivalry between different teams? Do they compare “some metrics will be better”?

- All teams are very different: each has its own product, its own goals, its own workflow, therefore, even if they use similar metrics, then the scales are very different and the indicators also.

And if you try to compare someone, it will be a comparison at the level of "here they are - well done, but we are not very good". But this “not very” will not even be relative to the other team, but to your own results.

Therefore, it seems to me that there is more competition with oneself. Do better than he did. It did not work out - to understand why, find the problem, fix it and try again. And the success of colleagues is rather just a motivator for your own.

- In the case of JavaScript, people often talk about a variety of pain - “zoo frameworks”, “what to do with dependencies” and so on. Firstly, how do you feel these painful spots in SEMrush, and secondly, does the “autonomy of the teams” somehow influence this?

- Of course, we also experience difficulties. And with the update of dependencies, when you have a huge product written a few years ago and there is no one who wants to rewrite it now. And the zoo of frameworks from past years and new products is all familiar to us.

Here's a good question about team autonomy. On the one hand, autonomy allows you to make your product, independent of anyone, update dependencies as soon as you need it, use frameworks that you consider appropriate for a specific task. When you do not depend on anyone - you are your own master, so many problems are solved faster and easier.

All pain begins in elements where several products intersect - in common parts. For example, I want to make some tools in inter-team use. But everyone who uses them loses autonomy immediately. Will other teams be able to update their instrument by the time you want to update yours? And there is always a very painful choice.

We need to think about how it will be better for users and for further development. And we must go and negotiate, there is no general solution to the issue that would suit everyone. Here begins the inclusion of the very "big uncle". Think ahead how to do better so that it is good now.

In general, it seems to me, “do it normally - it will be normal” - this is a very correct motto. Because almost all the problems that we stumble upon are the remnants of some unresolved problems, and often ours. If you think about the user more often, about the value you are carrying to him, and how the person who works after you will support it, some problems will start to be solved by themselves.

At least, I myself would like to get as close as possible to this approach in my work, and to expect the same from my colleagues.