Working Remotely: What I’ve Learned

Earlier this year at South By Southwest Interactive I attended a session by Scott Chacon where he detailed the ups and downs of being both CIO of Github and working completely remotely from Paris. He touched on imposter syndrome, making your work processes lock-free, and the importance of online face time.

Being a product manager myself, I was curious to see how remote would work for me and contrast it with what I heard from Scott. As of today it’s been about 6 months since I’ve gone remote – in a different city and time zone from both members of my product team and our clients.

Ups

1. Having remote team members really helps when identifying bugs.

For any application that has users across different time zones, or places emphasis on where things are located geographically, having people in different time zones can unearth issues that would likely escape standard testing protocol. When working on Ping Social, having team members in different time zones helped us realize there we had a bug when sending the time of an event to the server and converting to and from UTC. Since the bug was cross-platform in nature and we were about to release to a user base that was already in multiple time zones, we avoided what could have been a bad user experience by finding this early.

Being in different places also helped our team dig up a bug related to our user’s geolocation. While working on a book discovery app (Squirl) we noticed that certain locations from books weren’t showing up outside of Texas. Any location that an author added from a book that took place outside of Texas simply didn’t show up on the app’s map view. After a lot of digging we discovered this had to do with how latitude values were being stored – no book locations from a geolocation greater than 99 were being stored correctly. Throughout our beta testing, this issue had gone undetected since our launch city, Austin, had only longitude coordinates less than 99.

2. A remote team reduces distraction, and increases efficiency when the team does have face time.

When your team members aren’t just a few desks away, you’re forced to make the most of your time with one another. When remote, the team was forced to be prepared with any questions, problems, or anything blocking them from progressing with their work ahead of time, since we only had one allocated block of time per day in which we were guaranteed the undivided attention of the entire team.

3. It gives you access to a more diverse pool of users when user testing.

Another great benefit of having a remote team is being able to pull from a larger pool of locals to interview or to show your interface to. Having team members in different cities gives you personal access to people coming from a wide variety of viewpoints, as well as in-person access to users who would be reluctant or unable to sign up for an online usability lab you may be running.

It also gives the team first-person access to environmental and cultural factors that may shape product decisions – things that would be very hard to read about online or get out of a phone interview, but very obvious when you observe a person’s behavior or are able to be in the same space they are in from day to day.

4. It forces you to give URLs to your notes and to document exercises.

When working with each other in person, I found the team will often default to analog versions (post-it notes, whiteboards, pen and paper) when brainstorming interfaces, aggregating user quotations, or talking about a new feature release. We would then take a picture on our phone of what we were doing, and upload it to something like Google Drive or Trello. Although that was easy enough to do, it involved doing duplicate work, and sometimes things would get lost in the transfer.

With a remote team you are forced to document your work as you go, as normal pen+paper alternatives aren’t a viable way of communicating online. Almost all decisions and discussions now have a paper trail, and are self-documenting. When we go back to our notes to see when or why a certain decision was made, we’re looking at the primary document itself, as opposed to a replica or an abbreviated version.

Though this was a struggle at first, here are a few tools that are a goldmine for remote work:

Trello – project management, lists, catch-all, free communication tool

Mural – digital whiteboard, post-it notes, great for design exercises, free 30 day trial

Downs

1. When just one single remote team member is seeing a bug, it can be difficult to fix.

Our team strives to always document bugs with steps to replicate, severity level, and screenshots – but that’s just not always possible. Sometimes you can’t replicate a bug 100% of the time by going through the same steps. Sometimes it’s tough to communicate how your software is behaving through text and a still image. When you could normally take any team member’s device to a developer, plug it in, and start debugging, you can’t do that when the only person experiencing the bug is 500 miles away.

2. For teams that haven’t worked together before, emotions can be misunderstood.

It’s easy to sound like an ass on the internet. When you’re working with people you’ve never met, and have to make complex software decisions, things are bound to get a little intense. Sometimes simple differences of opinion or differences in objective (a project manager trying to optimize the project for quick delivery, while a designer is trying to optimize for the best UX) can create hard feelings.

The important thing here is that you talk things out via video call as soon as possible. We have also found that it helps a lot to have the entire team together for project kickoff (with the client if possible) to make sure things start off with everyone excited and comfortable working with and trusting one another.

3. Lack of water cooler discussion.

This is probably the biggest (and only, in my eyes) downside to having a hard working, dedicated, remote team: not being able to go get a beer after work or take the elevator down to leave together. Sometimes the best ideas come up during this “off work” time where no one is thinking about the product, but you’re still together.

The team and I tried to replicate this idle time in a few ways. First, don’t leave the meeting right away when it finishes. Have someone on the team declare that the meeting is over, but that anyone who wants to stick around and chat can. Second, we tried out Squiggle, which lets you start video calls with anyone who is available in just one click.

Check back soon for some specific advice on how the job of managing products is affected by being remote. It’s not just for freelancers, designers, and developers!

How has your team fared working remotely? Interested in trying to make the move to remote work but not sure how? Whatever it is, I’m more than willing to discuss in the comments!