How to effectively build and manage a remote development team

In February of 2020, our COO, Alexey Likhachev, presented a report at the TeamLead Conf 2020 in Moscow. He shared Evrone’s experiences of successfully managing remote teams. We hope that this article will become your guide to 20 best practices that will help you build, grow, and manage a team that is fully remote and spread around the world. 

From the day Evrone was founded, it was designed for remote development. Even the two founders of the company work from different cities. Over the past ten years, we have conducted a lot of experiments and built all the necessary processes to work efficiently with a completely remote team.

Analyzing the digital footprints that developers leave is the key to success

The main digital footprint that developers leave is, of course, the code they write and the corresponding documentation. Apart from that, their communication in the corporate Slack, messengers, and email, as well as their code reviews, comments, daily meetings, movement of tasks around the columns in JIRA, and time tracking all leave digital footprints too. So, here’s how you can use those digital footprints to implement remote team management best practices.

Guiding the team from day one

One of the basic rules is to lead your developers from the first day you hire them, starting at the inbound interview. It should consist of a well-prepared, standardized set of questions, and a set of tasks to give the candidates. It’s very helpful to develop a tool that will allow all your experts to conduct interviews comfortably, understand exactly what questions you want to ask, be able to evaluate the candidate’s answers to specific questions and, based on the results, be able to issue their expert opinions on how well a person meets their supposed technical level and whether they will be a good fit in the company and position.

Onboarding

It’s good to have a special person or team responsible for onboarding. They should be in communication with new hires from their very first day, answering their questions, showing them around, and sending them interesting information. This can help new hires quickly get more comfortable working with their team and vice versa.

Welcome book

As your company grows, at some point you’ll probably realize that you need to collect all the information about the company and its history into one place, so that your team members can easily find answers to common questions. You can give them a link to a Welcome Book where they can read about the company and its internal processes in detail.

One task at a time

A developer should only be focused on a single task at any given time. This allows all participants in the project to understand exactly what each developer is doing right now, at every point in the process.

Daily task tracking

We usually present reports to our customers stating the hours we spent on each particular task or function. It is very important to present the report on time and ensure that it is accurate, error-free, and honest. That’s why we have a rule that each developer must keep a daily log of their tasks and the time spent on them.

Daily meetings

Daily meetings allow the team to synchronize and ensure that each member of the team knows what everyone has done, what they will be working on, and what problems they are having. This is especially important when you have a distributed agile team.

Slack activity

Developers don’t spend all their time writing code. They often use chats to learn important details, ask questions, and discuss issues. Their Slack activity can also answer your questions about what your developer is currently busy with.  If you want to see if your developers share knowledge and determine if they are going in the right direction, you should monitor the Slack chats and look at the questions that they ask, see who answers those questions, and how they answer. If you see that a developer is asking questions which obviously do not correspond to their current task, you can immediately talk to them and resolve the situation.

Internal meetups

Remote team culture often lacks a personal element, and holding internal, online meetups is a great practice to foster friendlier relationships among team members. These meetups don’t have to be limited to technical topics. They can be conducted on any common interest, from cyber sports and gaming, to online wine tasting. Keep an eye on who visits which meetups to learn quite a bit about your team members.

Attending conferences

One great way to keep remote team motivation high is to provide your team members with an opportunity to attend any conference for free, at least once a year, with the company covering the cost of flights, accommodation, and the conference itself. It’s an amazing chance for people to meet in real life to talk and build connections, while gaining knowledge. You can also learn a lot about the direction a developer wants to go, based on the conference they choose to attend.

Evrone Challenge: technical level standards

At some point, we realized that we had a problem with the fragmentation of knowledge, and we needed to draw up a standard for ourselves to define the various technical levels within our company. Now, we have clear knowledge requirements for each level and a tool to test each developer’s knowledge. Evrone Challenge is a set of tasks, tests, and questions the developers go through, in order to determine which technical level they are at. It is not mandatory, and we do not force our developers to go through any kind of certification. We invite them to come and test their knowledge and gain some insight into their own skills. The Evrone Challenge is not a revision control tool, it is a training tool. A developer who does the Evrone Challenge learns what technical level they are at, what gaps in knowledge they can address, and which direction they should go in their development career.

Performance review

It’s very important to foster an environment where your developers are not afraid to tell their colleagues that there is an issue with the colleague’s work. Performance reviews can be a useful tool in this regard. Every three months, we send a small questionnaire to our developers. It consists of three questions and tasks that allow them to assess their colleagues’ performance and quality of work. This helps us identify which developers are experiencing performance issues, allowing us to talk to them about the issue and take steps to help them improve. In addition, this also allows us to recognize developers who are exceeding expectations and reward them for their performance.

Anonymous feedback

If your team members want to report something that they are not comfortable talking about in person, they should have an opportunity to report anonymously. It can be a form in your internal system or an anonymous form on the website.

Remaining estimate

JIRA has one of the must-have tech tools for remote employees. It’s called “remaining estimate” and it helps developers understand how much time they have left to solve a problem. It’s important to cultivate an environment where your developers trust you and feel comfortable telling you about any problems right away. The sooner an issue is recognized, the sooner it can be resolved.

Code review

We recommend practicing early code review and writing the tests ahead of time. This allows you to send a pull request for review at the moment main functionality is written, while the developer is still focused on the code. The developer can see the comments and solve them while he is still writing tests. This method allows us to solve problems more efficiently and effectively and recognize potential problems in advance. It also lets you see all of the developer’s work, the staging, pre-production, and production, showing you exactly what the developer has been doing.

Contribution activities

Github is a wonderful contribution activity tool that can help you analyze your developers’ performance. We do around 90% of our projects on Github. This tool shows you, in a fairly simple form, all the activity of each developer. You can see who made a lot of commits and pull requests and participated in discussions of other pull requests.

Commits and pushes

Each developer should send their work to the repository at least once a day. We developed a system that monitors the daily activity of our developers in all repositories. If the system finds that a developer has not made a commit in the last two days, it sends a Slack notification to the developer and their managers, team leads, and the account managers.

Attentiveness

In general, a pull request can say a lot about the attentiveness of a developer. If the developer didn’t issue the pull request in accordance with the rules, didn’t write the name of the task, didn’t indicate the essence of the pull request, didn’t note important points that those conducting the code review should pay attention to, or repeated mistakes that have already been addressed, this indicates that there are likely some problems with attentiveness and diligence.

Proactivity

Typically, the proactive developers always want to stand out and want everything they do to go to production as quickly as possible. In short, they make themselves and their accomplishments more visible. If a developer shows these signs of proactivity, it likely indicates that they are trying hard to reach their goals and be successful in their work. However, this doesn’t mean that more reserved developers can’t be proactive, as well. You should also take into account their behavior at daily meetings, the way they provide reports, whether they report about their problems or not, and how they talk about issues. All together, this will help you better determine whether or not a developer is performing at their best.

One-on-one

The next tool that can help you understand what level a developer is at is the “tête-à-tête” or “one-on-one”. This face-to-face conversation should include a number of questions on what the developer wants for their career, where they want to grow, what technologies they want to learn, and whether their current role is satisfying them. Tête-à-tête is a tool that helps you understand and monitor both in-house and remote staff issues.

Internal ERP

We have a corporate information system that we have been developing for a long time. It gives us the opportunity to put new hires, or those without a current project, to work in an ERP team. Developing your own internal ERP project pushes your team members to come and learn how to work more efficiently and effectively, since they will actually reap the benefits of their work. Our ERP team members can be transferred to a client's project at any time, and every developer knows that they must work carefully and leave documentation and context on how the next developer appointed to ERP can pick up where they left off. This practice of transferring knowledge from one developer to another allows us to solve issues and find solutions more quickly and effectively.

As more and more people are forced to work from home during this time, we hope that these tips for managing remote teams can help you continue to work effectively and efficiently. However, even during the best of times, a remote team can be an excellent option and a valuable resource. If you’re interested in building a remote development team for your company, let us know how to contact you, and we’ll be in touch soon.