Building a Successful Remote Team
I have been on the both sides of the table. I worked remotely. I have managed remote teams. This has given me a unique perspective on building and managing a remote team.
Tasks
Some things are very hard to accomplish remotely. Pair programming is one. Any task that requires many people to work closely together is hard to do remotely. You need face time and a high bandwidth discussions in front of a whiteboard.
For a project to be suitable for remote work, it should be easy to clearly separate tasks. A good way to accomplish this is to have a kanban style task list. For example, a remote developer can take a task from a list, work on it, and once the task is accomplished, the next card can be picked.
JotForm remote maintenance team works like that. We have a ticket system with hundreds of enhancement requests and bug reports. A remote developer takes a task from the list, completes it, closes the ticket and notifies users about it.
We don’t try do everything remotely. Like all development teams, we have some tasks which can be done better remotely in a focused environment while some tasks need passionate high-bandwidth discussions and pair development in the same room.
Visibility
The most important thing that helps a remote team succeed is visibility. The work accomplished by a remote developer should be visible to other teammates and to the manager.
There are many ways to accomplish visibility: a development dashboard, daily emails to the team, mailing list, team chat and code reviews.
Our homebrew Developer Dashboard is where we can all watch the activity on our remote team. It works like a twitter for code commits. You can watch to recent commits or you can drill down by developer or project. It is integrated with github for things like looking up diffs.
At the end of a work day, each remote developer sends an email to a mailing list. Similar to a standup meeting, you talk about the tasks you have accomplished that day. It is pretty motivational to tell others what has been done.
Continuous Deployment
Coordinating releases in a remotely working team is hard. A better model is to have a culture of shipping as often as possible. If a new feature is not completely ready, simply hide it from users. But, always ship it immediately.
Continuous deployment also helps developers be in sync with each other. Since they constantly commit their changes and update their local copies, conflicts happen very seldom and double work is prevented.
How do we keep things sane while releasing 50 versions of our product every day? We have a simple rule: if you brake the site you must first fix it quickly and then you must write a test that will catch it if that problem ever happens again. All tests run during the deployment and we stop the presses when a test fails.
Finding great talent and building a world-class team is hard. If you can build a great remote team you will be ahead of competition who only hires locally. It does not have to be a choice between remote or local. You can and should have both.
