It's been three years since my last post where I talked about my experience working in a distributed team, and I shared some recommendations on how to make it work.

Since then, distributed work among software engineers has become significantly more common. I've moved on to my second role on a distributed team at Desk.com, with colleagues in all four US timezones, one in Canada, and two in Australia. This post share some of the things that I've learned after three years of working exclusively in distributed teams.

Chatrooms with ChatOps

The chatroom is here to stay and it is often the main way that distributed teams communicate. Most people are using either Campfire, Hipchat, or the popular newcomer Slack.

Regardless of which product you use, integrating a Hubot has gone from a novelty to a mission critical tool for many teams. At GitHub, the Hubot is the command line interface for the operational teams to quickly determine where things stand. They can monitor servers, look at traffic patterns, even deploy releases right from the bot. They've coined this powerful technique "ChatOps", and you can read a slide deck about it here.

Audio Conferencing

Unfortunately, there hasn't been a lot of progress in the area of audio conferencing. Skype is still the most reliable way to go, as most of the chatroom solutions don't offer anything nearly as robust for one-on-one audio calls. Some screensharing tools offer decent audio calling, but I've found it to be buggy, especially over long distances or shaky VPN connections.

Video Conferencing

Video conferencing has come a long way, and Google Hangouts has really made it more mainstream. In organizations where Google Apps are used, Google Hangouts makes it very easy to just add a Hangout to a meeting, or type in a URL to create one on the fly. This has been a game changer for distributed teams to get that human touch and connect with colocated team members. The one thing that's missing is the ability to record Hangouts out of the box to share with team members that couldn't attend a meeting or presentation. There are some clever hacks around this, but it's not built into the product.

Remote Pairing

In larger distributed teams, everyone uses a different IDE or editor, so standardizing on a single, console based editor like vim may or may not be practical. Screensharing tools like Screenhero are a great fit for such teams.

Pairing remains an important part of remote work, especially when onboarding new hires. It also helps build camaraderie between team members that will come to rely on each other without having ever met in person.

The Workstream

Between the chatroom, emails, and a solid project management tool, you may not need a visible workstream to share updates with your team. But if this is still valuable to you, iDoneThis comes highly recommended.

Crossing streams is inevitable

Since my last post, more teams around the world have chosen to augment existing colocated teams with distributed team members. As companies grow and scale, sometimes it is inevitable for in-office cultures to evolve as colocated hiring increases. With these changes, I've come to accept that in growing companies, crossing streams is inevitable and it's just another obstacle to work around.

Ideally, it's best to keep teams within a timezone of each other to take advantage of any geographical advantages that you can. And don't be afraid to re-organize teams occassionally as you grow along geographical lines.

Facetime remains crucial

Our technology may be better, but we are still humans and a certain amount of facetime is still very important. Carve out time for team members to physically meet at least once per quarter. If you can't afford to fly everyone in at once, stagger it among smaller groups.

For major events like a new product launch or a hackathon, fly everyone in to make everyone feel like they're a part of something bigger. Make sure some outside work activities are part of these gatherings.

Hiring isn't much easier

Hiring distributed team members can be a significant challenge, despite the increased acceptance of distributed work and the attractiveness of remote work for candidates. It's hard to interview someone remotely, and it's even harder to build trust in someone that you've never met or worked with before.

Even more difficult is hiring junior folks remotely. Many teams aren't comfortable hiring junior folks and trying to mentor them from afar. This tends to skew the population of remote workers to those with 5 or more years of experience.

Companies that build very large teams generally rely on hiring junior folks to fill their ranks. Being a primarily distributed team can impose a constraint that prevents this approach to hiring.

These challenges are significant and shouldn't be ignored. Remote work was originally pitched as the solution to everyone's hiring woes, but now that it's gained more mainstream acceptance, hiring is again difficult.

Final thoughts

Remote work has gone from an occasional hack for companies desparate for talent to a full blown movement among successful, modern software companies. If done right, the performance of a distributed team can be on par, or often better, than one that is colocated.

There are still significant challenges with building distributed teams, and these should not be ignored. Good people will always be in demand, and now that location isn't as big an issue, the hiring market has caught up.

That being said, the tools have gotten better and the global mindshare around making distributed teams successful has increased. So there's never been a better time to go remote.

About the author
comments powered by Disqus