As American as Tapas and Apple Pie 1

Every morning, double decker bus after double decker bus shuttles engineers from all over the Bay Area to the GooglePlex, the Facebook compound, the Apple spaceship or the Yahoo campus. Yahoo infamously ended its work from home privilege. Google pulls out all stops to bring engineers together in the same and crowded place, showers them with perks, all to make magic happen.

“It is best to work in small teams, keep them crowded, foster serendipitous connections” – from How Google Works

What do you do when you are not one of these tech behemoths? What do you do when the skillset you seek is highly specialized and all over the world? When you find the masters in building real-time distributed systems, do you require them to move to the Bay Area, one of the most expensive places on earth? Housing prices throughout the larger Bay Area are astronomical. Do you make them slug through the busy Bay Area commute, even if that means that some will sit in traffic for over an hour each way?

As a small software company building real-time infrastructure software (“data distribution software”) for the industrial internet of things (IIoT), headquartered in Sunnyvale, California, we opted for a hybrid approach. We have two main development sites: Sunnyvale, CA and Granada, Spain.  Engineers have a flexible schedule to arrive at work to avoid the busy commute times. They all have the option to work from home occasionally. Most often, they choose a fixed schedule to work from home: e.g., every Wednesday. We also have remote engineers all over the US: Massachusetts, Florida, New Hampshire, New York, Virginia, and Minnesota. Managing the team, I stress about how to blend this team together, as if they were all in the same location and “foster serendipitous connections”? How do you cross the many time zones and yet leave no team behind?

The key to making this work is to establish the right team habits which build trust and are based upon transparency. We experiment often with new collaboration tools. If these tools do not foster more transparency or build trust, they will fail. Use tools and establish habits which emulate what happens in a traditional office setting, where you can drop into somebody’s office of a chat or for help. We’ve found that the following set of tools providing video, group chat and shared documents, paired with good team habits, to be the most effective.

When you want help debugging a problem, don’t default to sending an email. Email is impersonal and can get snippy (remember the Have you ever kissed a girl? email). Instead contact a remote engineer by video chat (You may still provide the log message via email). We use a lot of video these days, so much that we had to upgrade our internet to handle the many concurrent calls. We use Google Hangout for small group meetings, and installed a Google Chrome Box in several conference rooms. For example, our weekly bug-court meeting is a hangout with folks in Sunnyvale, New Hampshire, San Francisco, Maryland, Massachusetts and sometimes New York and Granada. For larger meetings, we use Webex and ask folks to turn on their camera when talking. In our large conference room, we have a remote controlled camera so remote participants can pan the room to the speaker. Yes, using video has it challenges (is my remote office clean?, CPU usage of Google Hangout, etc), but it is a key habit which help build trust.

An important practice are virtual (daily) scrums, through hangouts or group chat. We do this in individual development teams, and since recent, across the entire team. In individual development teams, the synch up meetings are more detailed and cover progress, plans, specific blockers or needs. When it comes to the entire team, we ask folks to post in a group chatroom specifics of what they will be working on that day. Initially we experimented with IRC (which failed on some platforms as it wasn’t as easy to use), and now we use Atlassian HipChat. Our rules for using HipChat are simple:

  • Rule #1: When you start your day, you say a virtual good morning and mention what you will work on in the GoodMorningGang room. This is similar to walking into the office and chatting with your colleague of what they will be doing that day. No good morning, no more soup for you: you don’t get to be part of HipChat. This rule has brought folks a lot closer. You get a sense of folks are working on, what they level of stress and frustration is, and you get to celebrate and chit-chat, as if folks were all in the same office.
  • Rule #2: move the conversation to the right room: e.g., don’t launch a discussion about platforms in the GoodMorningGang room; take the platform related discussions to the All Things Platforms room.
  • Rule #3: memes and animated gifs are allowed and encouraged. All work and no play makes Jack a dull boy. It’s ok to goof off, have some fun and create silly memes or celebrate with a little dance.

Very little of what goes on in the engineering team is a secret in the team or in the company. All our weekly meeting notes, team summaries or discussions are posted in internally available Google Docs. The engineering meeting notes are posted weekly to the entire company. We use Atlassian’s Jira to keep track of what we work on, or what type of bugs people have encountered with our products. This is accessible to the entire company. During weekly tech briefings, we educate each other about cool technical developments in the development and research team.

There are many more habits and tools which helps us work more efficiently as a distributed team: from a reasonably flat organization where the people doing the work are encouraged to make the decisions, to transitioning to a better revision control tool (git), to being able to power cycle all embedded boards in our lab from anywhere in the world.

Making a remote team work efficiently as if they are in the same office is not easy and takes constant adjustments and experimentation with habits and tools. When experimenting with a new habit or tool, always start small. Create pockets of excellence, succeed and then copy to another group. Be patient in the process. The combination of restlessness (aka we need to look for better tools to work as a distributed team) and patience (make them work) is important. Live the behavior.

One comment

  1. Pingback: Baker, bake me a cake! « RTI Blog

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s