Working Remotely

When I moved back from Vancouver, BC to Regina, SK there was a bit of a transition period where I was still a member of the product team in Vancouver, working remotely. To be honest, it didn’t go so well. There’s a few things I would change if I had to do it again.

The team I left in Vancouver was a 10-or-so person mix of designers and developers with a sprinkle of QA. When I moved, I had a pretty good idea of the current state of the project and the features and issues we’d be addressing in the coming weeks, so there wasn’t any sort of confusion on the problem space. We had really good processes around deployment, release cycles, and work management, so it wasn’t that either. The main problem was communication.

Non-functional Depedencies

You don’t realize how closely you work with your co-workers until you’re not in the same office as them anymore. I had experienced a sample of this when I had gone home for two weeks but worked out of the Regina office before. We still had our daily scrum meetings in the morining which I attended, but then I had 7 hours after that to “do whatever”. It’s not that I didn’t have work assigned to me, it’s that our workload is so interdepdendent on other co-workers that it’s hard to get anything done by yourself.

We tried remote pairing a few times, where someone in Vancovuer would share their screen with me and we’d use voice chat to communicate, which worked pretty well. But even then, I was just watching someone else code, not achieving anything else myself. Every morning my scrum update would be “I’m working on this, but I’m waiting on someone to finish X”, and then I’d spend most of the day waiting to hear back from that person.

Dependency on Communication

This isn’t a fault of the person or team I was waiting on, it’s just was a side-effect of our team structure. Most of the work we got done was by direct communication thoughtout the day with our team members, something that you can’t easily reproduce with a remote employee. While there are things like skype and instant messaging, your gut reaction isn’t to start a voice chat session every time you have a random work-related thought you’d like to communicate.

If I could do it all over again, I’d take over a specific feature or area of the software to work on remotely by myself. Of course there’d still be an element of collaboration with the project team, but because I’d have an entire function of the software there’d be less of an interdependence on other team members that would prevent me from getting work done.

Remote Culture, or lack thereof

Another thing I missed was the direct interaction. Our company has a very strong sense of culture, and every team has their own flavour of that. By being away from the team I was working with, I missed out on all the team interactions that were happening day to day. Even worse, because I was on another team, I wasn’t really a part of any of the interactions that were happening around me in my home office either.

“Companies That Support Remote Workers Win Against Those That Don’t” has a good list of things your company should provide in order to support remote employees effectively, including clear expectations, clear communication channels, a teaching culture, and a results-only-work-environment. I believe our company has all of those things to one degree or another, it was just the “pipeline of work that is actually ready to be worked on” that my team needed to work on.

After a few months I ended up moving to another team, which has ended up great. It’s not that our company can’t or doesn’t support remote workers (we do have a few people that work from home on a regular basis), but I think there’s a large interdependence on each individual team’s ability to support remote workers. There’s quite a change from the natural “water-cooler” workplace mentality to making sure you include your remote workers as much as possible that requires a focused effort.