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.