We Actually Built A Remote Team, And It Rocks!

(A counterpoint to http://blog.statuspage.io/we-tried-building-a-remote-team-and-it-sucked.)

The LonoCloud team at ViaSat has been remote for its entire existence. We started in October 2011 with myself in Atlanta, and quickly added Aaron and Jonathan (New Hampshire), Joel (Dallas), and Chris (Fort Wayne (Indiana)). LonoCloud was acquired by ViaSat in April 2013, and was allowed to continue intact as a remote team. Today the team includes over a dozen developers, representing all of the time zones in the continental U.S.

Why has our experience been so much more positive than that of the StatusPage team? I have no idea. There is no one-size-fits-all, your-mileage-may-not-vary, Philosopher’s Stone playbook for achieving Remote Team Nirvana. To mix a metaphor. I simply present our team as an existence proof that the StatusPage.io experience is not the only one available.

Pros/Cons

The StatusPage story is actually spot on here. On the plus side, we do get to draw from a larger hiring pool. We do take advantage of the ability to work from our local coffee shop, or in our hammocks, or by the pool. We do enjoy not having to get up at 6:00 AM so we can leave by 6:08 AM so our thirty-mile drive to the office takes only one hour instead of the nearly two hours it would take if we were to leave at say 6:15 AM.

[Author’s note: This was my actual commute when I worked in an office in Atlanta. Perimeter area, not downtown. Not that I’m bitter.]

The cons, however, are a different story. Yes, it can be harder to communicate. We could have weaker ties between employees. We might struggle with work-life balance.

Notice the use of the subjunctive in that last paragraph. All of the benefits listed in the StatusPage story are actual, and they are a given. Start a remote team, get all of the benefits. Boom. Done.

The cons are potential only. Our team has no problem communicating. We are fiercely proud and supportive of our teammates, and we genuinely look forward to the few times a year we get to catch up in person. We work hard when we can, because we enjoy our work, and we never begrudge anyone a chance to take a break, or play with their kids, or take their spouse out for Date Night.

Remote Teams and Collaborative Work

The StatusPage story talks about how being remote stifles their collaboration. They cite having to deal with time zone differences, [unfortunate] video conferencing software, and scheduling conflicts.

We are perhaps better off when it comes to time zones, because we have multiple devs in each (except Mountain; sorry Paul!). But we have no problem collaborating across time zones when needed or desired. Does this mean folks on the west coast are up early sometimes? And folks on the east coast up late? Sure it does. But it’s not a hardship, because we care about each other. And there is absolutely no recrimination if someone cannot be online at any given time, for any reason. We either reconfigure, or we press on alone if need be.

Which brings me to the biggest disagreement I have with StatusPage:

“Remote Doesn’t Work for Generalists”

It does for ours.

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

-Robert A. Heinlein

“Generalist” is a trait we eagerly hire for, and greatly value. “Problem solver” is another. In my experience, they tend to go together.

Do we have individual preferences? Of course we do. Don’t get us started on Emacs versus vi. But we also have a shared drive to make progress, and a shared preference for using the best tool for the job.

Technically, we are a Clojure shop. We all enjoy Clojure’s special blend of pragmaticism and elegance. But we also have competence in Ruby, Python, JavaScript, C, Forth, Perl, and the like. And we are not afraid to use them. Okay, maybe Perl.

Choice of programming language is only one of several axes of potential specialization. Chef? Puppet? Ansible? Our answer: “Yes”. We happen to have standardized on Ansible for intra-team work, but we will happily help your team with Chef or Puppet if that’s what you’ve chosen.

Front-end. Back-end. SQL. NoSQL. REST. Docker. Mesos. Onyx. AWS. OpenStack. Everything is on the table. If we can bend it to our will and it gives us the results we need, we will use it. If it doesn’t, we will know soon enough and we will try something different.

The drive to figure out how to maximize a tool’s effectiveness, and the enjoyment of doing so with like-minded professionals, knows no boundaries.

Now What?

Remote just isn’t for us.

-StatusPage.io

This does not have to mean that remote just isn’t for you. No, there is no guaranteed recipe for success. Okay, one: hire this team. But, frankly, what are the odds of that?

Here are some of the things that we at LonoCloud believe have helped make our remote team successful.

• Invest in high-quality, hardware VoIP phones. We use Polycom SoundPoint IP 335. Everyone on the team gets one, and it’s our most effective tool for clear, immediate communication. We also use HipChat for continuous presence, but typing is relatively high-latency. We have a standing daily conference call, which gives everyone a chance to sync up. We can also talk directly (and frequently do, especially while pairing), or set up ad-hoc conference calls for any subset of the team, for any duration.
• No videoconferencing. We just don’t seem to need it, given the immediate, reliable voice comms we get with the Polycoms.
• Be intentional about getting the team together. We try to get the entire team together in one location for a few days at least once a quarter. When feasible, we dovetail these meetings with conferences of interest to the entire team. This helps address concerns of minimizing travel while maximizing professional development.
• Hire the right people. Not very helpful, I know. If I could codify this one, I’d be writing it in a book, not a one-off blog post. And I’d be fabulously wealthy. Good luck with this one.
• Hire good people. “Good” in the sense of “decent”, as well as in the sense of “good at what they do”. When I was discussing hiring strategy and process with the executive team in the very early days of the startup, my favorite phrase was that we didn’t want to hire “Jerk #1”. We still haven’t.
• Be excellent to each other. Speaks for itself.