Bust Remote Development Myths with These 5 Habits

Header image for blog post about how to bust remote development myths

Perhaps the greatest advantage a business has today is the ability to transcend national borders when hiring. And boy is it true for the software development world. Having managed Messapps and been in the industry for many years now, I’ve noticed that the more successful a company is, the more likely it is to have remote employees.

Whether the employees work in different cities or countries, today there’s no need for a company’s developers to commute to a cubicle farm — or worse, commute to a place where free food and ping pong tables are thought to make people happy.

I’ll always argue that remote work is better — especially for a software development company. But it isn’t always the easiest. The Ben Parker in me is always whispering: With great remote teams come great responsibilities. But once you experiment and develop some key habits, knowing how to grow with a remote team becomes second nature.

In this post I’ll show you the habits engrained in our company’s psyche that help us hire the right people, increase development speed, and improve the quality of our final product – all while fostering a remote work culture.

Myths about remote development

Before getting into our processes at Messapps I want to do some mythbusting. Even today there’s still a stigma about working with remote developers and going remote in general. I find it amazing that, in a world where we send people to space, many think that working with team members outside of your city is a problem.

Myth: Remote developers are inferior in quality

Is there a chance you will work with a bad remote developer? Yes. Is there a chance you will work with a bad in-house developer? Yes. It has nothing to do with where the developer is located.

There are great developers all around the world. HackerRank recently published an article that shows how well people from different countries perform on coding tests. China, Russia, and Poland are among the top. The US and UK are ranked #28 and #29. Surprised?

This myth exists because people don’t hire right. The only way to ensure you hire the right developers is to have a good interview routine in place. For example, at Messapps, all of the developers we hire, whether for our New York or Moscow team, go through a three-round interview process. (More on this below.)

Myth: Time zone differences make communication difficult

Time zone differences can be a problem if you don’t organize your team. If you have ten time zones and everyone works whenever they want, then yes, it’s problematic. On the other hand, different time zones can actually double your productivity.

If your time zone differences have a small spread of 4-5 hours, have everyone agree to stay online at the same time. I found that though some developers prefer to work in the early morning and some prefer late nights, it’s usually not a problem for anyone to adjust their timeline by a few hours.

If your time zone differences have a spread of 8-10 hours, you can double your productivity and improve client satisfaction.

Consider having a day and night crew. Those who are within the smaller spread of 4-5 hours should be online at the same time as you. Those who are more than 6 hours away from you will end up doing some of their work while you’re asleep. And nothing makes our clients happier than knowing they can submit a bug at midnight and have it fixed by the time they wake up.

Habits that make remote development work

Whether “remote” means working with someone across the street or across the ocean, you must follow certain rules — every day — in order for remote development to work right.

Using a rigorous hiring process

At Messapps we put candidates through three rounds of interviewing before bringing them on board. Here is exactly what that process looks like:

  • Round 1: Complete an online coding test. To test candidates we use HackerRank. This gives us access to a large number of test questions for different coding languages and difficulty levels. These coding tests serve as filters and give us an objective measurement of how much a person knows about app development. Only people who score in the top 10% go to the next round.
  • Round 2: Interview with our CTO, Stas Batururimi. The goal of this round is to see how the candidate analyzes a problem and finds logical solutions for it. To accomplish this, we schedule a Google Hangout call with them and send them materials to read before the interview (here’s an example). The materials are there to help the candidate review some concepts that might have been forgotten but learned before.

    Once the interview starts, the candidate is given some of the more difficult tasks we’ve faced in our work. The candidate solves the tasks in a Google Docs document so that we can see the thinking behind the solution in real time. Because some of the tasks can be difficult, we don’t always expect the person to find the solution in a given timeframe. We do, however, expect the candidate to demonstrate logical thinking and an understanding of important development concepts.

  • Round 3: Making the decision. If the candidate passes the first two rounds, we know that the person has great development skills and broad coding knowledge. But sometimes even the smartest developers don’t work out. To determine whether they fit our culture, during the third round I interview developers to better understand their goals in life and attitude towards work.

    The ideal team member must be hardworking, constantly trying to improve, and able to communicate with other team members in a friendly yet informative manner. This interview process helped us hire some of the best remote developers we have on our team.

Having daily “standups”

Many practices we follow come from agile principles. The first one is standup meetings. Standup meetings notify everyone on the team about who is working on what and if there are any obstacles being faced. We use the Status Hero bot and Slack for this.

Every morning our team members are asked three questions:

  1. What did you do yesterday and were you able to hit your goals?
  2. What are you planning to do today?
  3. Are there any obstacles impeding your progress?

With this daily check-in, we know which projects are being worked on and if there are any issues with them. These updates also let other team members know if someone is waiting on them to finish some part of the project.

Communicating effectively (with rules)

It’s important to have all the right tools set up for team communication. Your team should be able to easily discuss work-related issues and have a place where they can share a funny video they found on Facebook. We use a mix of two tools for 99% of our communications: Slack and Phabricator.

We use Slack for our day-to-day communications. We have channels for each project we work on but also more general channels. For instance, there’s one where our designers can drop interesting design articles they found. There’s also one where developers can share cool code libraries they found.

It’s important to add a rule to channels that states that project-related issues should be discussed in their respective channel. This way everyone is aware of what’s happening. It creates a system that makes everyone feel as if they’re sitting in the same room talking.

Managing tasks in a central place

Hubstaff recently published an article about using Trello for Kanban. Phabricator’s workboard is very similar to Trello, and setting up Kanban is similar too. We set up our workboard with 5 columns:

Screenshot of a task tracking board for post about making remote development work

Phabricator workboard with five columns to track the progress of tasks

By default, the Backlog aggregates all of the tasks. If there’s an emergency bug fix required or feature we’re falling behind on, we put it into the Priority column. When developers open the board, they first take all the tasks from the top of the Priority column. If it’s empty, they take tasks from the top of the Backlog column.

While a developer is working on an issue, that task is placed in the Working column. And as a rule, each developer should not have more than two tasks in the Working column. It’s simply impossible to multitask with finesse.

Once a developer finishes the task, it’s moved to the “To check” column. This is where the project manager tests code and confirms the issue is fixed. If the code passes, the task is moved to the Done column. If it doesn’t pass, the project manager leaves comments and moves it back to the Priority column for the developer to fix ASAP.

Working with a Kanban board gives you two main advantages:

  1. As a manager you know what’s happening and which tasks are being worked on
  2. As a developer you always know what needs to be done

Separating suggestions from bugs

If you’re working with software, bugs are inevitable. But in order to stay on track, you need to separate bugs from suggested changes.

For bug reporting we use Instabug. When implemented into the app, a user can just shake their phone to report a bug. And the amount of information we get from each bug report… Oh boy is it gold…

Data from Instabug including screenshots, OS version, battery, wifi, session length, user steps and more

Data from Instabug including screenshots, OS version, battery, wifi, session length, user steps and more

Everything a developer needs to fix a bug is here. What’s better is that we can easily integrate it with Phabricator. So whenever a bug is reported, it automatically goes to the Backlog and a developer can start fixing it right away.

A challenge we’ve faced, however, is clients reporting suggestions as bugs. For example, one can report a “bug” that will say: “Do you think we should change the background color to orange here?” When something like this is reported as a bug, it messes up our whole system.

To avoid this there are two options: 1) you can enable the suggestions feature in Instabug which isn’t linked to your workboard or 2) if the bug reporting tool you’re using doesn’t have a suggestions feature, you need to make it clear to the beta users that suggestions should be reported separately.

Conclusion

Working with remote developers allows you to hire the best people in the world. They can also make your team twice as productive. To make remote development work, you just need to have the right processes in place.

Do you share some of our habits for running a remote team of developers? Or do you do something else entirely? Let me know in the comments. And feel free to email me directly at vm@messapps.com if you have any questions about the work we do.

  • Alex Kistenev

    Very detailed article, it’s a good read! Speaking of Slack bots for daily standup meetings you should add standuply.com and standupbot.com as well =)

    • Dann Albright

      Glad you liked it! Thanks for the recommendations—there are so many Slack bots out there that it’s pretty impossible to come up with a comprehensive list. Always glad to hear about ones that people like!

  • Marco Gaertner

    This is a great article. Thanks very much — it gives me much to think about.. My biggest challenge has been on how to brainstorm remotely. Yes, chatting and forums are fine, but nothing is quite close to a nice whiteboard session. Any thoughts on this?

    • Vasily Malyshev

      Hey Marco!

      Great question. The way I see brainstorming is it should not be a team meeting where you COME UP with solutions but instead it should be a meeting where you CHOOSE a solution. I think people should come up with solutions on their own and then discuss them. This way you get more options to choose from and generally save time.

      So if we have a problem I ask team members to come up with 5-10 solutions. At the time of the meeting people will present their solutions on Slack with brief description of the solution and it’s main (dis)advantages. Depending on the number of solutions we can either discuss it or maybe use a poll on slack (there are many slack poll bots you can find) for everyone to vote. And discussing when you have summary of solutions and their advantages/disadvantages is fairly easy on slack. At least for us.

      That however is an answer from the management side of things. If you need a coding solution it might be different but I find our developers to be able to do it on Slack just as well.

      What do you see as the main problem for you with brainstorming online?

      • Marco Gaertner

        Thanks, that helps. On your question about the main problem with brainstorming, I see it being the conversation after the group has presented the solutions. Everyone thinks differently, so we will sometimes not understand the solution presented right off the bat. Or, perhaps we understand, but want to discuss further what-ifs. On those cases, I find that typing on a chatroom, or even voice conversations (specially if more than 3 people), fall short when you can’t draw diagrams real-time (business or coding). Illustrations, for visual people like me. Working in the office, we would at this point walk up to a whiteboard, and draw what we meant, what-ifs, one drawing on top of each others’ ideas. I miss that aspect the most leading my people remotely. Do you know of any solution for that?

        • Vasily Malyshev

          Hey Marco!

          Sometimes a visual representation is good indeed. I usually use Google docs and draw.io if I need something but here is also a sketch whiteboard extension: https://sketchboard.io/slack. And here is just a general browser whiteboard: https://realtimeboard.com/. Hope that helps!

      • Awesome response, Vasily.

        Too much time is spent in meetings when the conversation just goes round and round and nothing ever really comes from it. For instance, you can spend an hour in a meeting and only arrive at one solution (that might not end up working).

        When people bring multiple solutions to the table (after ruminating on them when they’re in their zone with no distractions), a much better solution can be found. In other words, debating thought-out solutions is a better approach than debating multiple “things” in an attempt to arrive at a solution.

        I’m going to start suggesting this approach to meetings and whiteboarding sessions from now on 🙂

        • Vasily Malyshev

          Glad I can add something to the great Hubstaff team! 🙂