When Working Remotely Fails in Practice

Working remotely has been lauded as a great opportunity–and in some cases, considered better than working in an office. I submit that this isn’t always the case, depending on the work being done and the people involved.

During September–November of 2017, I had the opportunity to work remotely for Atomic Object. This is a rare occurence at Atomic, where we advocate having an open office and co-located teams.

Story Time

I started working for Atomic at the end of May as part of the Atomic Accelerator program. I was part of a large web development project which would span the rest of the year. The team included a few employees from Atomic and co-located developers from our client.

I was fairly new to web development and largely learned on the job, but it was quick for me to dive into my work and tasks, adding a lot of velocity to the project.

Before I joined the project, everyone knew that I would be returning to California to finish my master’s degree. Whether I would be working during that time was unknown, but we had discussed a few possibilities.

Because of my demonstrated tenacity and willingness to throw myself into some difficult problems, it was agreed that I would continue to work from California. I was to work a maximum of 20 billable hours, focusing only on stories that could be completed in that time since we didn’t want to have an open story that might not be actively worked on for a few days.

These guidelines were meant to reduce any pain on rest of the team and myself. The Delivery Lead and I agreed that I would only be required to attend certain meetings, so they wouldn’t cut into my productivity.

Pain Points

Initially, everything seemed to work out well. I was able to work on stories that were simple enough for my allotted time, talk with teammates when needed, and attend stand-up and other required meetings.

But a few weeks in, I started to feel some pain. Though I was adding velocity to the project and doing much-needed tasks, it was clear that I was pretty much on my own. A large number of the stories were contained in a small section of the code that no one else on the team was involved in. This meant I didn’t get any time to pair program, and I didn’t need to communicate much beyond indicating what I had been working on.

I talked this over with the team, and we decided to make some changes. My new focus was to work on newer features and possibly some bugs. This would give me more opportunities to work with others on the team and help me stay up-to-date on the code.

Again, things started out well, but they quickly deteriorated. New challenges arose that became harder to work through. Though I was communicating with the team more regularly, it still wasn’t ideal because of the three-hour time difference and the meetings I was missing.

From 9-10am, I was often unable to work much because the team was on lunch. I had blocks of regular time each day where progress became limited due to meetings, especially when I needed direction with a particular bit of new code.

As a team, we were crushing stories and had great velocity, but I mostly got left behind. No one did anything wrong, and in many respects, we tried making the best of the situation. In the end, I still grew apart from the code, and in early November, we decided I should focus full-time on finishing my master’s degree.

The Pros and Cons of Working Remotely

Pros

  • No commute.
  • Work and home life are easier to manage.
  • Hours might be more flexible.
  • Can work from anywhere.

Cons

  • Can be hard to communicate effectively with team.
  • Pair programming is difficult.
  • Possible to grow apart from the code base.
  • Working in the same time frame as the main team may create schedule conflicts.
  • Less likely to socialize and bond with coworkers.

Takeaway

Though the situation wasn’t ideal, there are things that I can take away from this experience. It may have been better if I been able to work a full 40 hours, since not having the time for meetings was a main cause of losing touch with the code base.

The time difference, though not extreme, still made my schedule a little difficult. The larger the time difference between a remote worker and the main team, the more this would cause problems.

Working remotely for long periods might not be ideal for software development and consulting work. This likely depends on the type of work, but a week or two is probably a safe amount for remote work.

Overall, I don’t think remote work would be a good fit for Atomic Object unless it was for a limited time frame. Atoms do work from home on occasion, for various reasons and sometimes for a few days in a row, and this seems to work out.

In the end, we like working from the office as it’s most suited for the work we do. It allows us to grow together and foster a healthy social life while making great software and products.