Interview with the CTO of Moeco: It’s Great to Have a Relaxed Remote Developer in a Hammock

This time our guest is Alex Korolkov the CTO of blockchain platform Moeco. During our discussion, we talked about the rules of hiring remote employees, managing distributed teams, forced vacation as a last resort, and why it’s great to have a relaxed remote developer in a hammock.

At 6nomads, we’re trying to identify the profile of successful remote specialists to make the search, selection, and hiring process much easier. How would you identify such specialists? What makes them different?

It’s all about self-discipline, self-management, as well as the ability to ask the right questions and search for answers independently.

Usually, specialists identify their working hours very clearly. If an employee starts to work off schedule, this is a sure sign that remote work isn’t suitable for him/her. For example, if a developer writes to me at 2 am, but no one asked them to work overtime, there is no such situation that would require it. It’s really important for specialists to realize their working hours, because burnout is common in terms of remote work.

Not underworking, but overworking is the biggest problem in terms of remote work, isn’t it?

If an employee doesn’t work, doesn’t cope with the tasks, then you fire them — it’s that simple.

It’s useless to track time: everyone is different, and they need different amounts of time for the same tasks. Moreover, in the summer they cope with tasks quicker than in the winter, because in winter all processes in Russia work worse. Instead of tracking time, you need to count delivery time: you should split tasks up into smaller ones together with the employee and control the implementation of two tasks per day. If one or two tasks haven’t been done, you need to define why it happened, involve other people in the decision.

No one cares that a developer doesn’t work according to a schedule if they do at least these two tasks per day. But, there are some signs of employee burnout: they start to do more and more tasks; they aren’t able to stop, and, as a result, they fizzle out. Sometimes, I take away access for two weeks when a developer works too much.

So, you have a kind of “parental controls”. You have mentioned aspects that can be tracked in the work process. But, how could you determine a long term and productive collaboration with the developer from the very beginning?

You can find out by using leading questions during the interview.

For example: if a person is late for an interview, this is a sure sign that they don’t know how to manage their time. Even during the probationary period, it’s quite easy to understand whether a candidate is able to use a calendar or not: you create an event, but you don’t tell them about it. People have to know how to use a calendar.

Also, it’s very important to know how a person works with text: if they’re able to write a coherent and consistent paragraph without stupid mistakes, it’ll most likely be convenient to work with them. This skill is especially indicative even for developers. Moreover, I know excellent product managers who aren’t able to write such a paragraph.

You mentioned writing skills. We’ve faced two points of view about communication in distributed teams: some consider the ability to write critically important, not only because it’s a basic skill that shows structure and consistency, but also because almost all communication has a written form and it’s important to express your point of view clearly; others believe that chats and messages are only a “band-aid”, and issues should be solved and discussed only through verbal communication. What do you think?

Verbal communication instead of chatting? I try to avoid verbal communication on important topics.

I think it depends a lot on people. With my co-workers, it doesn’t fit at all. I can critique them in this way, but for discussion it is better in chat. If we misunderstand each other and have a disagreement in a chat, then we can call each other and immediately solve everything. But, if we yell at each other, then the chat won’t help.

Is it possible to say that it’s necessary to grow for remote work? To be “molded” through office work, to advance in your career? We found that successful remote developers are about 30 years old. From your experience, is it important to look for such specialists?

Highly qualified employees are always older, but now there are two 24 and 25 years old developers in our team.

There are no age limits in the searching process. If an introvert likes their job, they could write great code at the age of 15 and work remotely perfectly.

There is no correlation between age and responsibility, is that right?

Responsibility is a little bit different. Responsibility isn’t about a process, it’s about a project. If you formulate a project incorrectly, a person who usually does pretty good delivery suddenly stops doing it for some emotional reasons. This’s not related to responsibility.

And remote work experience isn’t a key factor. For one of our team members, Moeco is their first job, and he’s doing awesomely. We hired him because he was interested in the “technical” part, he had had only university and open-source experience with the software. It turned out that he works perfectly and remote work is suitable for him.

The onboarding process takes a crucial part in terms of remote hiring. Because you have to explain to the new employee how to navigate this system, make sure that they don’t feel left out. How do you build the onboarding process?

The onboarding processes in large corporations and remote companies have a lot in common. In big companies no one cares about you, you can’t walk around and ask people who don’t have time for you. When it comes to remote work, the new employees just see a list of people in the chat, they hear them at the stand-up and meetings, that’s all. They will feel completely lost, so onboarding is the key process. Be sure to assign one or two colleagues, who are obliged to answer all questions. Onboarding becomes part of their work for a while.

Do you have some lifehacks for proper work immersion?

Move from the general to the specific. At first, you show how the whole system works, then you correct the bugs, then small features from one part, then features that aren’t connected with each other. You shouldn’t let an employee dive into any area: backend first, then frontend, then go through some tests. In this case, you will get what’s going on and remember all of the information for the first month.

Do you practice the attestation process when it comes to onboarding results?

We have a large and very cross-disciplinary platform. I like when people grow and do it themselves. It’s difficult to assemble the puzzle pieces to make a picture if you give a lot of information. If we make a test according to the onboarding results, it’s blatantly obvious that there will be some mistakes, which means the candidate will have a negative experience. Therefore, I think it’s better to talk about every feature during the job. That way, the candidate doesn’t have the feeling that they are wrong, because they perceive it to be a learning process. So, it will create a positive impression and be more constructive, I think.

Many people in our interviews have mentioned that soft skills are more important in terms of remote work than in the office. Do you agree?

Soft skills are very important. You can easily check whether a person can code or not. If a specialist doesn’t know or doesn’t understand something you can train hard skills and explain why you should do this and not another way. With soft skills, it won’t work.

If you explain to your employee: “Dude, you are rude when you speak English” — the employee won’t understand you and will be offended.

Same with grooming. If an employee says: “I need the statement of work,” they usually hear: “You are fired”. If a person asks for the statement of work, they want to delegate the task formulation to someone else, but I don’t need this, we all have to work as one team. If the product owner forgets some detail on the grooming, but the logical mistake is obvious, developers are obliged to point it out and not follow it blindly.

Proactivity is very important, and this is a soft skill without a doubt. The ability to talk to people, to behave constructively in different situations — this is almost impossible to teach, because people get offended, thinking that they were hired as developers, but learn some kind of nonsense.

Do you possibly have some kind of checklist for an interview that helps you figure out the suitability for remote work, to avoid mistakes and not hiring the “wrong ones”?

But I don’t mind hiring a “wrong” person. I immediately warn that I can fire you at any time during a probationary period.

I would like to hire formally constructive people, whose behavior would be different from the standard and would bring something new to our team.

We check if the candidate is lying on the CV during the interviews. If the developer writes that they know neural networks, we definitely ask for something that quickly makes the candidate think, to see whether they know neural networks.

Do you continue the conversation in the case there is such a lie?

Not necessarily! It is important to understand how a person’s logic works. There is nothing terrible in a small “exaggeration” on the CV, but if a person doesn’t understand that neural networks are a very deep and complex area, that’s weird to mention it after reading a couple of articles. So, if the CV isn’t connected in any way with the fact, this is the stop factor.

We heard that you are as strict as possible about a mismatch between the preliminary assessment of the task and the actual deadlines. Is it true, that you can easily fire someone for that?

Definitely. This is the only KPI metric of a developer’s work. The KPI of other specialists can be measured in another way.

There is a difference between junior, middle, and senior employees: junior doesn’t know the answers to the questions “What are we doing?” and “How do we do it?”, middle knows how to do it, but doesn’t know what to do, and senior knows how and what we are doing.

A person should be able to evaluate the time for each task’s execution. A good team leader with a team of five people would say that the task would take a month, and the error rate will be 20%. The senior developer would say that they would finish in 2 months and then mess it up because they’re not a team leader and don’t know what overheads arise in the team management process.

How do you do sprint planning and task prioritization on your team?

For example, I don’t plan anything on Friday, I shift anything that couldn’t be done at that time. But this doesn’t apply to the team.

We have backlog grooming on Tuesdays and Thursdays. We discuss all the tasks that need to be done there. No other tasks can be done except those that have gone through the grooming process. We break the task into smaller ones and estimate it. It’s senseless to make a task without an estimation, because in this case, we can’t provide answers to the questions like “what?” and “how?”. Sometimes we make off-schedule grooming if we want to.

During sprint planning, we take all the evaluated tasks and make a sprint. It’s important, that the business goal was delivered in the sprint. So, if we have three tasks, two of which are related, it’s better to take them into work, even if they are a low priority. Because the main goal of the sprint is to achieve results, and not to do all the tasks in a row.

What is the technical aspect of grooming organization?

I have a whiteboard; I draw something on it and people write it down.

Do you make regular face-to-face calls?

It’s necessary to do face-to-face once every two weeks. Of course, I call each employee more often than once a week. During face-to-face calls, we don’t just discuss work, we speak on other topics, about team members, for example.

This is the meeting where someone can tell me: “Alex, you interrupted a man during the last meeting. Don’t do that, please.” Or about someone’s behavior. It can’t be said in any other cases, but on such face-to-face calls, it can be done. Also, for the opposite situations, if someone got a great result, for example.

Moreover, I make face-to-face calls once a week during the onboarding period to get a feel for the person’s mood. I accumulate the feedback of team members and give it to new employees.

Ok — working aspects. Some CTO’s in our interviews told us that face-to-face is more about non-working aspects, in order to maintain team cohesion, to know what happens in everyone’s life. Because at such meetings people discuss the health of their dogs and their kids. Do you do this?

I would like to do it, but I can’t find the strength. I know some personal things about employees, I can talk to them about it, but I don’t force it, because the developers are mostly introverts — aggressive introverts.

People still confuse freelancers and remote workers, don’t realize how distributed teams work, and often ask the same question: “What will I do if the developer disappears, the deadlines burn, and everything falls apart?”. What would you say to them?

But if the person didn’t come to the office? How do you find them? It’s all about lack of professionalism. People sincerely believe that everything is under control if the developers are in the office. Control freaks are sure that the world revolves around them — it’s a very common mental disorder among middle managers, but you can’t scale control. A manager can control about 5–7 people, but as soon as there are 10 people in the team — three of them won’t do a damn thing, because control is not widely spread over them.

It’s much easier to tell people that you will not micromanage them, they can work as they want and when they want, no forty hours a week, only some time when you have to be online, and if you aren’t — you must explain why. And that’s all. Then we look at the results. If there aren’t results, we have a conversation, if this doesn’t help, the person leaves. And, by the way, the second mental block of bad managers is the fear of firing, although this is a normal working moment.

The success of managing a distributed team partly lies on the readiness to fire an employee even on the fifth workday, doesn’t it?

Yes, on any day — the fifth or thousandth. Even if the developer worked for you for two years valiantly, and then something happened to them and they began to act rude in meetings. First, of course, you send them on vacation for the whole time that they have, then another two weeks on leave of absence, and if the situation doesn’t change — well, you are fired.

Leave of absence is the last resort, a red flag. When you switch off all access and send them on vacation, it means that they can no longer work, and needs to think about it; if they come back — we’ll talk.

It’s clear. So, specialists can burn out, can’t stand the pace of the team, can’t cope with the tasks, but there must be a few employees who quit willingly, right? There’s little staff turnover in terms of remote work, except for developers in Moscow with an average “lifetime” of 1.5 years on one project.

Definitely. First, remote work isn’t popular yet. Second, it is comfortable. Third, people get along with each other much better in remote work, because they don’t meet each other, so they are less likely to argue.

And people really appreciate the opportunity to work from anywhere in the world: you can rush to Thailand or go skiing in Kyrgyzstan, you just need to discuss it with the manager because the time you are on a flight could coincide with team activities.

I am very loyal to the idea that employees can take the day off instead of weekends, and then fulfill it. I still see how the code appears in the repository, the tickets move, passing tests for each feature. It’s very easy for me to track when a person starts to mess up and becomes lazy. I turn a blind eye to this, but if people abuse it, it’s a different story.

There are two groups of people: those who like to work and those who like money. And the second one is quite easy to identify: their CV shows how they like money more and more; I don’t hire them.

And there are some people who are trying to find themselves. It makes sense to hire them, because they will work well for half a year, then they will either become sad, or they won’t — that’s just how it goes. People who are trying to find themselves are good candidates. People who have been working remotely quite a long time are good candidates, and those who want to start working remotely for the first time need attention.

Is the lack of turnover the fact that many remote developers are located in smaller areas?

Yes, and it also plays an important role. We probably pay them more than they could earn in their towns.

But isn’t your purpose to save money with remote employees from these smaller regions?

No, it’s a bad idea to underestimate your employees, specifically because they work remotely.

Saving at the office is already a good bonus from remote work in addition to the fact that it allows you to hire completely different people.

What lifehacks do you have as a remote guru that can help people dive into work? Some people wear shoes and sit at the table, others manage to work in their pajamas from bed, what do you prefer?

This is all very personal. I can’t write code in the daytime, it doesn’t work. I write my best code from 11 pm to 5 am. Additionally, it doesn’t matter what I am wearing.

I have a height-adjustable table: when I communicate with partners, like now, for example, I stand, it’s more convenient for me to talk in this way. When I do management tasks, it’s more convenient for me to sit. These are very personal things, they can’t be extrapolated.

There is an employee on our team from Batumi, whenever we have a video call, I see him on the balcony in a hammock with a cigarette in his hand and a laptop on his knees. He’s always relaxed, and he has such a great delivery that there are no days when he can’t complete the task. So, he deliveries a little, but constantly — I like that.

And there is another example — the superhero, he completes the tasks at all costs, doesn’t sleep for two nights, and then disappears for two days. I don’t think that’s a good idea. But if you count his delivery in a week, it’ll be more than others. The delivery is ragged because he sleeps a day and works two.

What about clothes. Well, I noticed that working naked is a little bit strange.

And now a pop quiz. What did you learn when you started working remotely? What was unusual?

I discovered that you have to communicate with people much more than in the office. I can’t get close to people in the office, but it’s virtually impossible with remote work. We discuss news, approaches to mathematical problems, and solve Einstein’s riddles.

Complete the sentence: don’t try to become a leader of a remote team if …

If you are a control freak.

Trait, that is especially important for a remote employee —

Self-discipline.

Why is remote work so unpopular in Russia?

Because Russia is a military country of control freaks. We love when employees march from 9 am to 6 pm.

At 6nomads, we help IT talent to get remote jobs in the best companies and select interesting projects for their professional growth. We decided to launch a series of interviews with the CEO’s and CTO’s of international companies focused on hiring and managing distributed teams and to discuss their successful experiences with remote work, although it still remains unpopular.

Read our first interview with Andrew Rebrov, CTO of Scentbird — “Move from Moscow to New York to fill perfume samples and never regret it” is about the successful experience of organizing the work of a remote team.