Distributed YES or distributed NO? Interview for those who for six months can not find a developer
On the eve of the team lead breakfast “Remote team. Start "we talked with the technical director of wemake.services - Nikita Sobolev ( sobolevn ). Despite the fact that the search for a developer, especially an experienced one, is a nightmare of a team leader or project manager, few still decide to switch to working with remote workers. Nikita, on the other hand, solved this problem radically several years ago. How? Let's figure it out!
Further in the interview will appear two: the interviewer (I.) and Nikita Sobolev (N.)
I .: Almost all team leaders and development managers complain that they can’t find a developer in the office. Especially in the regions. Take Kazan for example. For six months they can’t find a developer for themselves, but still hold on to everyone sitting next to them in the office. Does this seem to give illusory control?
N .: Precisely - the illusion of control. Let's probably start by defining remote work. And here I want not to first make a difference between remote and non-remote work, but I need to look at the work itself. At work they require different things. There is work where you just come, from 9:00 to 18:00 you sit, do something and, in principle, is enough. I call this approach "hours" - here you come and, accordingly, must sit out. All. There are no more formal requirements. Particularly cunning employers can come up with some ridiculous KPI to minimize the number of bugs in the prod. Or some other nonsense. And then no less cunning programmers will learn to optimize it without useful activity. And nothing will change.
And the second method is called "for the result." When you begin to check the result, in principle, it doesn’t matter to you what time the person came, what time he left, and what he did. That is, if it is important for you that on Monday this feature works, and on Monday it works - in principle, everything else does not interest you.
I .: Well, you understand that then there should be much more control points. Because you can wait a month for the result, and then it turns out that the person did nothing.
N .: Absolutely, yes. The result is not something big. The result is something small. When we try to achieve a global result, we have a lot of small intermediate ones. And these small intermediate results are also valuable and important for us. And thanks to them, we see a clear process, how a person goes from point A to point B, what decisions he makes, what code he writes, what features he sees next, in what order he makes them. We get full transparency. And in principle, it doesn’t matter to us where it is, remotely or not remotely.
We have a project, a global goal and a certain rhythm with which we are moving towards this goal. We see each intermediate result, we can control its quality, control its global direction. As you can see, remote or non-remote work is not important here. Not remote work is important to people who are about the first.
I.: I know that your whole team is distributed. It seems that you believe in people very much, and I read from another techdir that he does not believe in people, but only in control and deadlines. It seems to you that your position is such that a person is able to carry out a task independently without clear, constant instructions and control on your part. What do you think: can all developers work in this mode? What kind of people will cope, and which ones need constant monitoring?
N .: I really believe in people. But there are a few subtle nuances. If a person came and said that he would do it, at that moment I trust him. Another thing is that it would be illogical to trust him with something big and very important. Not because he is bad and deceives, but because it is something big, it can contain a lot of difficulties that a person can not physically cope with and let himself down, the project and me. Why bring to this situation? Therefore, the main idea is that the tasks should be small and understandable .
I completely trust a small understandable task to a person and say: “Here's a task for you for an hour or two. You can do it as you see fit. Here are our completion criteria, here are your tools. ” And, accordingly, during these two hours no one touches him at all, he is free to do anything. Two hours later, he brings and says: “Here is my result.” Or he says: “This can’t be done in two hours, and that's why. I came up with such a solution for the future. ”
It happens that people come to us who are used to working in the office or who are used to working in another outsourcing. And they can not earn anything in a month. Just because instead of following our simple rules, they try to work in the old mode. And naturally, they do not succeed. Moreover - they ignore my advice and recommendations of our bots. And yes, there are problems. Accordingly, if a person is such a typical office worker who is used to having three meetings a day and 15 minutes of writing code, he will probably find it difficult. Because there are no meetings, or any other distractions, there is only code and documentation. Thus, we move towards meditative programming without distractions and context switches.
And .: One thing surprises me in this scheme: when you give people small tasks, there must be someone who sees the whole project and understands where we are all moving. It turns out your load is increasing. And you have to keep this hundred small tasks under control, right?
N .: A person should have a complete picture in his head where we are going. If people in the project do not understand where they are going and why they are doing something, they will not be able to give a normal result. And so it is everywhere: remote, not remote - it does not matter. But in order to compile this complete vision, people need an understanding of the subject area, they need an understanding of the business problem, they need an understanding of some global milestones and their connection to business tasks and the subject area.
This can be done with a detailed description of what we do in the documentation. That is, the creation of a single language, understandable requirements, the creation of business models and scenarios, understandable graphs and diagrams, decisions made, use cases and user scenarios. This is not that we just need such a feature, no, but why do we need it, who will use it, in which case, what are the pitfalls in this feature. The documentation creates a complete understanding of where we are going . I will say more, due to the fact that we have all these small tasks connected together, we get such a “chain of tasks”, and the developer can understand where we started, where we are going and where we are.
The code itself is also very important, which is not written in the style of "here we have a bunch of trash." And with a clear architecture, with clear rules, with good patterns. And the code is tied to what we do at a high business level. When you look at a class, you already see that this is not just a class, but a class that is responsible for a certain area of ​​business - “oh, there it is!”. At this point, good developers have an understanding of what they are doing, and then they can begin to create tasks on their own. They will do some small part, and then they understand: "Ah, we still have to go forward there."
My only role in all this is to simply control the direction, well, a certain adequacy.
I.: I understood your idea that a common vision is the most important thing for a person to correctly understand / carry out tasks and see his contribution to the project. But in your work system, I see 2 more principles - this is to take, firstly, developers of an exceptionally high level, and secondly, this is a very well-written documentation. Right?
H .: That's right. And now we are returning to remote work. Why we, accordingly, chose this option, and not the "office" option. And now you precisely noticed that these two points are key.
The first is strong developers. Where to find them? Strong developers around the world are unevenly distributed. And there are points where there are more powerful developers and at the same time they are cheaper. Why should we compete, for example, with Moscow companies, who can afford to pay a lot of money for a strong developer when our resources are more modest? There is a wonderful regional market, the Asian market or the African market, or the market of other post-Soviet countries. There are strong developers, but they are several times cheaper.
It is important to understand that we do not resell the time of cheap developers for expensive, as everyone usually does. We try to find the best for the same money. And we offer a transparent payment system . How much earned - so much received. Due to the local market, companies have problems with good developers, but we do not have them.
And the second point is the documentation. Good documentation can only be written when it is needed. Because if it is written from under a stick and is not looked at, updated, it quickly becomes bad. Good documentation, for example, in open source projects, how is it written? She is the only source of how people can learn and take advantage of this open source project. If people see that something is not working in the documentation, they create a task and say: "Something is not working in your documentation." You say, “Oh, I'll fix it now.” If a person sits next to him, he will simply ask you: “What should be done at this point?” And you are forced to answer him. And in this process, the documentation will not be good. For documentation to be good, people need to be at a distance and not be able to communicate directly.
I .: Funny, it turns out that when people are at a distance, it’s easier to get involved in the project, because they can read the documentation, and in the office they have to look for who started to write it, where did this piece come from and what does it mean?
N .: Yes, it becomes easier for them, because the whole process of remote work is based on the fact that new people will come. There are two working options: automation and documentation. Many things are easier to automate: for example, deploy. And how something works is easier to describe in text or in a graph.
In the teams that work in the office, it seems to me that this is impossible to achieve. I very often hear that you need to spend a lot of time on this, and if you sit next to you, you work faster. If this is a short sprint, and you need to make a prototype of some application in a week, it will probably be faster to work face to face. But if we are talking about a project that lasts several years, then it critically accumulates all known problems very quickly. And after a while it is impossible to use it. This is the problem of all the software that I saw, which is written in a traditional model.
I .: What fears and prejudices did you have when you switched to working with a distributed team? Or were they not?
N .: Naturally, there were fears, and our first guys, whom we hired on a remote site, worked according to the old system, that is, for wages. And when you pay a salary, you do not care. Because you want to squeeze the most out of the time that a person sold you. I then had a lot of doubt and prejudice. And there was no control at all. I soon realized that in this format, remote work did not work.
As a result, we curtailed that experiment. And now I have rather a bias towards the office.
Someone wants me to be somewhere at a specific point on Earth, limiting my freedom of movement. He also wants me to spend all the time on him, limiting my freedom of activity. It is strange that for many people this option seems normal.
It is clear that there are always obligations. But in my case, these obligations are about the result. That is, at such a moment, I have to do this. And in office work, I have an obligation that I go to the office every day. And from above, they come up with some other requirements that I can skillfully put off for later.
The answer is so complicated. If you pay money for some reason, the remote team is hell. Because you can’t control anything at all. And if everything is done correctly, then the remote team is the next level of labor organization in comparison with what it is now.
I .: What does a correctly constructed remote work look like from your point of view? There is a certain developer who is ready to work on a remote site, what happens next?
N .: There is a very good example for developers. This is an open source phenomenon. Open source - these are millions of developers who remotely self-organize, no one really helps. And they do awesome things that the whole world uses.
And good remote work looks exactly the same. How does any communication in open source begin? The developer creates a task, says: “Something doesn’t work for me”, or “I don’t understand the documentation”, or “I want a new feature”. You look at what needs to be done in order to satisfy him. Next is a discussion, some clarifying questions, perhaps this task beats on several tasks. And then a code is sent that closes these small parts. The code is checked by tests and linters, a review occurs. And then a new version will just be released. Actually, that's all.
And the whole artificially created world around projects, which is now from the category of “we have 15 team leaders, 6 project managers and two scrum masters,” they are needed in order to squeeze more out of people for the same money. Because no one can check the result with all the fiction of importance and control. With a focus on results, everything works without them.
I .: Do you think there is a safe way to move to such a model? Imagine there is a team in the office, there are team leads, there are products, analytics and so on. They are critically short of developers, either they have constant fakapy, or the deadlines are on. At some point, they conclude that one cannot live like that.
N .: I will explain, I myself was not in such a situation of a safe transition. And I don’t know of companies that would gradually switch to this option. I had a very traumatic experience. We had a big money hole due to the fact that we worked in the old way, and somehow everything went badly. I had to dismiss everyone who we had that moment, and in fact start over again. And this moment, on the one hand, was very difficult, painful, and on the other hand, very simple, because I did not need to do the transformation along the way. I just chopped and started again.
I .: Many managers believe that the team is their main value. And you fired everyone. And now do you consider your guys who work for you in different parts of the world as a team?
N .: Of course not. I am generally against the use of the word “team” out of business. I believe that a team is really something unique. All that is now traditionally on the market is a team, at best. And in our case, it’s not even a team, it’s just a set of people who together make one project and earn money. They are not something that is not a team, they are not even familiar. Basically, now the word “team” is used as another manipulation of people.
I .: Interesting. It feels like half of the articles and speeches about managing a distributed team on how to rally this team when it is in different time zones, speaks different languages, and how to make interaction effective. Is this a problem for you at all?
N .: Not worth it. Moreover, I am against the fact that people rallied forcibly. I believe that so many people cross borders. There is a frontier of work, and there is a frontier of personal life. And at work, I am ready to communicate with different people. Because this is work, I do not always choose with whom to communicate. It’s necessary - it’s necessary. But when people begin to shove forcibly into my nose people with whom I do not want to communicate outside my work, such as "go get together with them." Why all of a sudden? I have my own friends, I have my own family, why will I spend time on unclear who, when I can chat with people important to me? For me, this is absolutely incomprehensible.
I .: Do I understand correctly that you simply do not impose a corporate culture and do not forcibly integrate your team, and in return people get complete freedom to choose what to do, what time and with whom to communicate. And give a result, of course.
N .: Yes. And I try very hard to differentiate between the things that I can do, because I pay money for it, and which I have no right to do, because I just pay money.
I.: I know that for many people your approach is rejection. For example, on the habr under this article there are comments that you are almost cruel, you are not going to pay anyone, and so on. Why?
N .: There really is such a problem. People see what they want to see, and what they are used to seeing. If people are used to living in an industry where they are used, deceived, manipulated, and thrown, then they see it. If people are used to living in an atmosphere of trust, in an environment of quality work and balance, they see it. The question is, unfortunately, in our industry the first prevails over the second.
I .: Doesn’t it seem to you that in fact the system that you offer solves one of the main problems of developers who say that they really write code 15 minutes a day? And the rest they spend at meetings and burn out, burn out, burn out ...
N .: Of course, I did it for myself! And most of all I like to write code. It was strange if I made a system in which I could not write code.
I .: Can your seniors earn enough for their life? And how many hours a day do they spend to earn as much as, for example, in the average statistical IT company in their city?
N .: They can, but not all. Only those who work a lot and efficiently. They can earn a lot. There is no upper limit and cannot be. And some people could not earn anything at all from us.
And we also have slightly different price tags. They are several times higher than market ones in Russia. It is important to understand that we are not selling the same watches. The usual hour of work is nothing. You sit, watch YouTube for an hour, and you get paid for it. Some companies want to insert a probe into you to watch what you do there. Therefore, the price of such a low-productivity hour is also low. We have an hour of work - this is a fixed cost of the task.
But here is another problem - the ruble exchange rate has fallen sharply. And we, for example, cannot work with European developers at all. We had such an experience, but they just get some crumbs by their standards. Many simply participated because they were interested, but for the money it was not enough. But with the guys from other parts of the world - it turns out, because they have a lot of money for their standard of living.
It turns out three groups: the “no” group (these are Americans and Europeans), the “maybe” group (these are ours, Ukraine, Belarus) and the “yes” group (these are Africa, Asia, etc.). Here the question is specifically about my implementation: for how much I can sell this idea to customers, and how much they are willing to pay. Again, we work only with Russian customers. If we actively entered the European or American market, they would pay more, and this problem would be partially solved. But so far.
I .: You have described almost the entire globe! How widening is the choice of candidates with access to the international market?
N .: It expands very much. We have not yet had time to work actively with South America. And there, like, there are also a lot of good developers.
I .: Tell me, how are you looking for developers?
N .: No way. They themselves come. They are interested in trying.
PS Nikita’s principles of work can and do cause controversial opinions, but the system is proving to be effective. Do you have alternative successful experience in organizing the work of a distributed team? Write in the comments!
And those who will be in Kazan on October 2, 2019, come for a team lead breakfast where you can discuss this article: express all your indignation or approval of Nikita’s approach, as well as listen to 3 other stories about working with udalenka and outsourcers.
Further in the interview will appear two: the interviewer (I.) and Nikita Sobolev (N.)
About working methods in general and the number of control points
I .: Almost all team leaders and development managers complain that they can’t find a developer in the office. Especially in the regions. Take Kazan for example. For six months they can’t find a developer for themselves, but still hold on to everyone sitting next to them in the office. Does this seem to give illusory control?
N .: Precisely - the illusion of control. Let's probably start by defining remote work. And here I want not to first make a difference between remote and non-remote work, but I need to look at the work itself. At work they require different things. There is work where you just come, from 9:00 to 18:00 you sit, do something and, in principle, is enough. I call this approach "hours" - here you come and, accordingly, must sit out. All. There are no more formal requirements. Particularly cunning employers can come up with some ridiculous KPI to minimize the number of bugs in the prod. Or some other nonsense. And then no less cunning programmers will learn to optimize it without useful activity. And nothing will change.
And the second method is called "for the result." When you begin to check the result, in principle, it doesn’t matter to you what time the person came, what time he left, and what he did. That is, if it is important for you that on Monday this feature works, and on Monday it works - in principle, everything else does not interest you.
I .: Well, you understand that then there should be much more control points. Because you can wait a month for the result, and then it turns out that the person did nothing.
N .: Absolutely, yes. The result is not something big. The result is something small. When we try to achieve a global result, we have a lot of small intermediate ones. And these small intermediate results are also valuable and important for us. And thanks to them, we see a clear process, how a person goes from point A to point B, what decisions he makes, what code he writes, what features he sees next, in what order he makes them. We get full transparency. And in principle, it doesn’t matter to us where it is, remotely or not remotely.
We have a project, a global goal and a certain rhythm with which we are moving towards this goal. We see each intermediate result, we can control its quality, control its global direction. As you can see, remote or non-remote work is not important here. Not remote work is important to people who are about the first.
About people, meditative programming and the two main principles of udalenka
I.: I know that your whole team is distributed. It seems that you believe in people very much, and I read from another techdir that he does not believe in people, but only in control and deadlines. It seems to you that your position is such that a person is able to carry out a task independently without clear, constant instructions and control on your part. What do you think: can all developers work in this mode? What kind of people will cope, and which ones need constant monitoring?
N .: I really believe in people. But there are a few subtle nuances. If a person came and said that he would do it, at that moment I trust him. Another thing is that it would be illogical to trust him with something big and very important. Not because he is bad and deceives, but because it is something big, it can contain a lot of difficulties that a person can not physically cope with and let himself down, the project and me. Why bring to this situation? Therefore, the main idea is that the tasks should be small and understandable .
I completely trust a small understandable task to a person and say: “Here's a task for you for an hour or two. You can do it as you see fit. Here are our completion criteria, here are your tools. ” And, accordingly, during these two hours no one touches him at all, he is free to do anything. Two hours later, he brings and says: “Here is my result.” Or he says: “This can’t be done in two hours, and that's why. I came up with such a solution for the future. ”
It happens that people come to us who are used to working in the office or who are used to working in another outsourcing. And they can not earn anything in a month. Just because instead of following our simple rules, they try to work in the old mode. And naturally, they do not succeed. Moreover - they ignore my advice and recommendations of our bots. And yes, there are problems. Accordingly, if a person is such a typical office worker who is used to having three meetings a day and 15 minutes of writing code, he will probably find it difficult. Because there are no meetings, or any other distractions, there is only code and documentation. Thus, we move towards meditative programming without distractions and context switches.
And .: One thing surprises me in this scheme: when you give people small tasks, there must be someone who sees the whole project and understands where we are all moving. It turns out your load is increasing. And you have to keep this hundred small tasks under control, right?
N .: A person should have a complete picture in his head where we are going. If people in the project do not understand where they are going and why they are doing something, they will not be able to give a normal result. And so it is everywhere: remote, not remote - it does not matter. But in order to compile this complete vision, people need an understanding of the subject area, they need an understanding of the business problem, they need an understanding of some global milestones and their connection to business tasks and the subject area.
This can be done with a detailed description of what we do in the documentation. That is, the creation of a single language, understandable requirements, the creation of business models and scenarios, understandable graphs and diagrams, decisions made, use cases and user scenarios. This is not that we just need such a feature, no, but why do we need it, who will use it, in which case, what are the pitfalls in this feature. The documentation creates a complete understanding of where we are going . I will say more, due to the fact that we have all these small tasks connected together, we get such a “chain of tasks”, and the developer can understand where we started, where we are going and where we are.
The code itself is also very important, which is not written in the style of "here we have a bunch of trash." And with a clear architecture, with clear rules, with good patterns. And the code is tied to what we do at a high business level. When you look at a class, you already see that this is not just a class, but a class that is responsible for a certain area of ​​business - “oh, there it is!”. At this point, good developers have an understanding of what they are doing, and then they can begin to create tasks on their own. They will do some small part, and then they understand: "Ah, we still have to go forward there."
My only role in all this is to simply control the direction, well, a certain adequacy.
I.: I understood your idea that a common vision is the most important thing for a person to correctly understand / carry out tasks and see his contribution to the project. But in your work system, I see 2 more principles - this is to take, firstly, developers of an exceptionally high level, and secondly, this is a very well-written documentation. Right?
H .: That's right. And now we are returning to remote work. Why we, accordingly, chose this option, and not the "office" option. And now you precisely noticed that these two points are key.
The first is strong developers. Where to find them? Strong developers around the world are unevenly distributed. And there are points where there are more powerful developers and at the same time they are cheaper. Why should we compete, for example, with Moscow companies, who can afford to pay a lot of money for a strong developer when our resources are more modest? There is a wonderful regional market, the Asian market or the African market, or the market of other post-Soviet countries. There are strong developers, but they are several times cheaper.
It is important to understand that we do not resell the time of cheap developers for expensive, as everyone usually does. We try to find the best for the same money. And we offer a transparent payment system . How much earned - so much received. Due to the local market, companies have problems with good developers, but we do not have them.
And the second point is the documentation. Good documentation can only be written when it is needed. Because if it is written from under a stick and is not looked at, updated, it quickly becomes bad. Good documentation, for example, in open source projects, how is it written? She is the only source of how people can learn and take advantage of this open source project. If people see that something is not working in the documentation, they create a task and say: "Something is not working in your documentation." You say, “Oh, I'll fix it now.” If a person sits next to him, he will simply ask you: “What should be done at this point?” And you are forced to answer him. And in this process, the documentation will not be good. For documentation to be good, people need to be at a distance and not be able to communicate directly.
About the remuneration system and team building
I .: Funny, it turns out that when people are at a distance, it’s easier to get involved in the project, because they can read the documentation, and in the office they have to look for who started to write it, where did this piece come from and what does it mean?
N .: Yes, it becomes easier for them, because the whole process of remote work is based on the fact that new people will come. There are two working options: automation and documentation. Many things are easier to automate: for example, deploy. And how something works is easier to describe in text or in a graph.
In the teams that work in the office, it seems to me that this is impossible to achieve. I very often hear that you need to spend a lot of time on this, and if you sit next to you, you work faster. If this is a short sprint, and you need to make a prototype of some application in a week, it will probably be faster to work face to face. But if we are talking about a project that lasts several years, then it critically accumulates all known problems very quickly. And after a while it is impossible to use it. This is the problem of all the software that I saw, which is written in a traditional model.
I .: What fears and prejudices did you have when you switched to working with a distributed team? Or were they not?
N .: Naturally, there were fears, and our first guys, whom we hired on a remote site, worked according to the old system, that is, for wages. And when you pay a salary, you do not care. Because you want to squeeze the most out of the time that a person sold you. I then had a lot of doubt and prejudice. And there was no control at all. I soon realized that in this format, remote work did not work.
As a result, we curtailed that experiment. And now I have rather a bias towards the office.
Someone wants me to be somewhere at a specific point on Earth, limiting my freedom of movement. He also wants me to spend all the time on him, limiting my freedom of activity. It is strange that for many people this option seems normal.
It is clear that there are always obligations. But in my case, these obligations are about the result. That is, at such a moment, I have to do this. And in office work, I have an obligation that I go to the office every day. And from above, they come up with some other requirements that I can skillfully put off for later.
The answer is so complicated. If you pay money for some reason, the remote team is hell. Because you can’t control anything at all. And if everything is done correctly, then the remote team is the next level of labor organization in comparison with what it is now.
I .: What does a correctly constructed remote work look like from your point of view? There is a certain developer who is ready to work on a remote site, what happens next?
N .: There is a very good example for developers. This is an open source phenomenon. Open source - these are millions of developers who remotely self-organize, no one really helps. And they do awesome things that the whole world uses.
And good remote work looks exactly the same. How does any communication in open source begin? The developer creates a task, says: “Something doesn’t work for me”, or “I don’t understand the documentation”, or “I want a new feature”. You look at what needs to be done in order to satisfy him. Next is a discussion, some clarifying questions, perhaps this task beats on several tasks. And then a code is sent that closes these small parts. The code is checked by tests and linters, a review occurs. And then a new version will just be released. Actually, that's all.
And the whole artificially created world around projects, which is now from the category of “we have 15 team leaders, 6 project managers and two scrum masters,” they are needed in order to squeeze more out of people for the same money. Because no one can check the result with all the fiction of importance and control. With a focus on results, everything works without them.
I .: Do you think there is a safe way to move to such a model? Imagine there is a team in the office, there are team leads, there are products, analytics and so on. They are critically short of developers, either they have constant fakapy, or the deadlines are on. At some point, they conclude that one cannot live like that.
N .: I will explain, I myself was not in such a situation of a safe transition. And I don’t know of companies that would gradually switch to this option. I had a very traumatic experience. We had a big money hole due to the fact that we worked in the old way, and somehow everything went badly. I had to dismiss everyone who we had that moment, and in fact start over again. And this moment, on the one hand, was very difficult, painful, and on the other hand, very simple, because I did not need to do the transformation along the way. I just chopped and started again.
I .: Many managers believe that the team is their main value. And you fired everyone. And now do you consider your guys who work for you in different parts of the world as a team?
N .: Of course not. I am generally against the use of the word “team” out of business. I believe that a team is really something unique. All that is now traditionally on the market is a team, at best. And in our case, it’s not even a team, it’s just a set of people who together make one project and earn money. They are not something that is not a team, they are not even familiar. Basically, now the word “team” is used as another manipulation of people.
I .: Interesting. It feels like half of the articles and speeches about managing a distributed team on how to rally this team when it is in different time zones, speaks different languages, and how to make interaction effective. Is this a problem for you at all?
N .: Not worth it. Moreover, I am against the fact that people rallied forcibly. I believe that so many people cross borders. There is a frontier of work, and there is a frontier of personal life. And at work, I am ready to communicate with different people. Because this is work, I do not always choose with whom to communicate. It’s necessary - it’s necessary. But when people begin to shove forcibly into my nose people with whom I do not want to communicate outside my work, such as "go get together with them." Why all of a sudden? I have my own friends, I have my own family, why will I spend time on unclear who, when I can chat with people important to me? For me, this is absolutely incomprehensible.
“No”, “maybe” and “yes” - where to look for developers
I .: Do I understand correctly that you simply do not impose a corporate culture and do not forcibly integrate your team, and in return people get complete freedom to choose what to do, what time and with whom to communicate. And give a result, of course.
N .: Yes. And I try very hard to differentiate between the things that I can do, because I pay money for it, and which I have no right to do, because I just pay money.
I.: I know that for many people your approach is rejection. For example, on the habr under this article there are comments that you are almost cruel, you are not going to pay anyone, and so on. Why?
N .: There really is such a problem. People see what they want to see, and what they are used to seeing. If people are used to living in an industry where they are used, deceived, manipulated, and thrown, then they see it. If people are used to living in an atmosphere of trust, in an environment of quality work and balance, they see it. The question is, unfortunately, in our industry the first prevails over the second.
I .: Doesn’t it seem to you that in fact the system that you offer solves one of the main problems of developers who say that they really write code 15 minutes a day? And the rest they spend at meetings and burn out, burn out, burn out ...
N .: Of course, I did it for myself! And most of all I like to write code. It was strange if I made a system in which I could not write code.
I .: Can your seniors earn enough for their life? And how many hours a day do they spend to earn as much as, for example, in the average statistical IT company in their city?
N .: They can, but not all. Only those who work a lot and efficiently. They can earn a lot. There is no upper limit and cannot be. And some people could not earn anything at all from us.
And we also have slightly different price tags. They are several times higher than market ones in Russia. It is important to understand that we are not selling the same watches. The usual hour of work is nothing. You sit, watch YouTube for an hour, and you get paid for it. Some companies want to insert a probe into you to watch what you do there. Therefore, the price of such a low-productivity hour is also low. We have an hour of work - this is a fixed cost of the task.
But here is another problem - the ruble exchange rate has fallen sharply. And we, for example, cannot work with European developers at all. We had such an experience, but they just get some crumbs by their standards. Many simply participated because they were interested, but for the money it was not enough. But with the guys from other parts of the world - it turns out, because they have a lot of money for their standard of living.
It turns out three groups: the “no” group (these are Americans and Europeans), the “maybe” group (these are ours, Ukraine, Belarus) and the “yes” group (these are Africa, Asia, etc.). Here the question is specifically about my implementation: for how much I can sell this idea to customers, and how much they are willing to pay. Again, we work only with Russian customers. If we actively entered the European or American market, they would pay more, and this problem would be partially solved. But so far.
I .: You have described almost the entire globe! How widening is the choice of candidates with access to the international market?
N .: It expands very much. We have not yet had time to work actively with South America. And there, like, there are also a lot of good developers.
I .: Tell me, how are you looking for developers?
N .: No way. They themselves come. They are interested in trying.
PS Nikita’s principles of work can and do cause controversial opinions, but the system is proving to be effective. Do you have alternative successful experience in organizing the work of a distributed team? Write in the comments!
And those who will be in Kazan on October 2, 2019, come for a team lead breakfast where you can discuss this article: express all your indignation or approval of Nikita’s approach, as well as listen to 3 other stories about working with udalenka and outsourcers.
All Articles