Alexey Kataev, Head of Development at Skyeng, talks about running an efficient remote development team. In 2014, I started one of five remote developers at Skyeng. Now we employ more than 80 developers and all of them work remotely. Why did we choose this format? Remote work has a lot of benefits. It’s easier to hire people and make them stay. Not many companies are ready to hire remote workers. But there are lots of talented developers in smaller cities who’d love to work for a bigger company but cannot move to a bigger city. For them, Skyeng is a perfect opportunity. Plus, remote teams are easier to scale as we don’t need to rent office space. But many people are still skeptical about remote teams. I picked three most frequently asked questions and will address them in this post. Cultivating team spirit is still possible even if you don’t work in the same room. How to build a strong remote team? People can be engaged in the process even when each of them works from home. How to motivate developers? Remote work doesn’t mean that your employees sit on the couch watching TV shows all day. How to monitor and control developers? How to Build a Strong Team? Use video chat First of all, all our meetings and talks are held through video chat. Thus we can see each other and realize that we work with real people. Another rule is to have a real photo as a profile pic in Slack. No pretty sunsets or cute cats. It helps to remember that your colleagues are real people, not functions behind the screen. Make your communication efficient We have lean communication processes to make all team members feel included. For example, everyone must fill in their Slack profile — this helps to avoid questions like “What’s your email?” We have a set of rules that make out communications efficient. New hires complete a course on efficient communication. No one has to reply to a message instantly. After all, that’s impossible when half of the team is in Saint-Petersburg and another half is in Thailand. With our processes, an instant reply is rarely required. We communicate in the asynchronous pattern. In Slack, we have separate channels for each team, each project and for ad hoc discussions. A developer can subscribe only to the channels he or she needs. Otherwise, we’d just get swamped with all the information. For the same reason, we discuss everything publicly. No private chats. All the channels are easy to find due to standardized names. We split the communication flow. Meet more often Meetings make a team. People need to talk to each other. We have stand-ups with analysts and designers who give an update on a project. Then we have daily morning stand-ups. We have team meetings and stand-ups for the whole development team. We have retrospective meetings where everyone can share their thoughts on the tasks completed. The most exciting ones are of course tech reviews. Plus, we meet offline. Once a year we rent a house and have a team retreat. Choose one mode of work and keep to it From my experience, it’s a bad idea to have a mixed team with half of the people working from an office and the other one working from home. I work from home, and I don’t like to be a talking head on a conference call with the office. Everyone should work either from home or from the office. How to Motivate Developers? Give them context Each developer must know what he or she does and why. Show them how their work will bring the company millions of dollars and how happy reaching your KPI will make you. Help your programmers meet with the users. Our assistants collect user feedback weekly and post it in Slack. This way developers see how their work affects people. Explain why their tasks are important It’s not always that obvious. For example, we had a script for payouts to teachers. We wanted to make it work faster. Why was that important? Some teachers had to wait for the payout for seven hours. By the law of large numbers, some teachers quitted by the end of the day as they couldn’t wait that long. So it was not just an abstract script, it affected people directly. Understanding this connection helps to boost motivation. Hold analytical stand-ups Analyze your results and see which features worked great and which ones were not that successful. At Skyeng, almost every team has such meetings and all the developers can see how their work affects the product results. How to Monitor and Control Developers? Give them more freedom It may sound counter-intuitive, but more freedom leads to more commitment. There can be several levels of freedom. This is the most basic level when developers can choose to work on the tasks they like. Choosing a task. Developers should engage with devising a technical solution — this way they feel more responsible for it. To cut the number of proposed solutions and save time we have tech reviews where we discuss all the options. Choosing a technical solution. This is the highest level of freedom, and we are still experimenting with it. Inverted planning means that a product manager says “Here’s our goal, you can do anything as long as you reach it”. Each team develops a plan and presents it to the management. This also makes a team feel more committed and responsible for their actions. Inverted planning. Make all the processes transparent Too much freedom without transparency leads to chaos. That is why we make all our processes transparent to everyone. A manager can open a board in Trello at any moment and see what each developer is working on. We have specials bots to update the statuses of tasks automatically. Discuss the results In an office, it’s easy to see whether people are working or not. But with remote work, you only see the results, not the process. So it’s very important to discuss what was done and how it affected the metrics and KPIs. We have such meetings weekly. We built our processes through trial and error. Now we have an efficient remote team where all the developers enjoy their work and are committed to the process. If you have any questions on the topic or want to share your thoughts, message me — I’ll be happy to share our experience.
