Managing Remote Teams: How To Start

May 04, 2015Giles Bowkett

Talent is crucial to running a tech company, and hiring remote workers can be a spectacular advantage. In places like San Francisco, with fierce and constant competition for engineering talent, it can be a shock to say “ok, we’ll try hiring remote,” and suddenly get inundated with amazing resumés.

But managing a distributed team is completely different from managing a co-located team.

Start With An Asynchronous Culture

Let’s say you’re running a conventional company and you want to experiment with remote work. You have a team with no experience working remotely whatosever, but hey, how hard could it be, right? You might be tempted to say, “OK, from now on, anybody can work from home.” Resist that temptation.

Asynchronous, distributed work cultures are different from co-located, synchronized work cultures. Those differences are important. Expecting your team to suddenly transition from one mode to the other, without preparing them for the culture change, means neglecting your job as a manager. It’s irresponsible.

Before you start telling people they can work from home as much or as little as they want, you have to make sure your culture can handle it.

Here’s a simple checklist:

Distributed version control’s pretty much taken over the world, so I’ll skip evangelizing it here.

Wikis

But wikis are still an underused technology. If you don’t have one, don’t go remote yet. Instead, set up a wiki, and get your whole team into the habit of using it to record important information. You’ll need this later, when your team’s working remotely, to keep everybody on the same page on a long-term time scale.

Here’s an idiotic but very common problem at technology companies: important architectural decisions which revolve around subtle details, and can make or break your company, get decided by whoever can express their logical fallacies the most loudly, or with the most confident smile, or — in severe cases — by whoever happens to have the most impressive head of hair. Putting every decision in writing doesn’t guarantee a more rational process, but it certainly helps.

You’ll also pick up one of the nice side effects of working remote: putting your decisions in writing prevents you from later accidentally reversing them, because you forgot why you made the decision in the first place. (I’m using “you” in the plural sense here.) As silly as that sounds, it happens.

Consider architectural decisions, decisions about what tools to use, decisions about coding style - they all depend on fine detail, and they often mean a lot personally to the engineers involved. At a lot of companies, it’s very common to have a conversation like “why aren’t we using [my favorite technology] for [some use case]?” on every new hire’s first day. Onboarding becomes a lot easier in general with a wiki, because it’s natural for new hires to share a lot of the same questions, but it’s especially valuable when the reasons for an architectural decision are counter-intuitive, surprising, subtle, or otherwise not immediately obvious at first glance.

Always-On Chat

People need to be able to ask each other questions informally, and IRC keeps people on the same page on a short-term time scale. IRC also makes it really easy for your team to ask each other questions. For that reason, it’s basically a required technology anyway if you’re doing any work with open source software.

People think of distributed work cultures as zero-meeting cultures. But most distributed companies have a permanent meeting running at all times, from the day the company is founded, which you can join or walk out of whenever you want. It happens in chat software, so all participation is asynchronous. It’s kind of like all the benefits of an open-plan office, without all the terrible fail.

Videoconferencing

If you’re managing a team which wants to explore remote work, run a few meetings over videoconferencing software first, even if you have everybody in the same building. Just have everybody sit at their cubicles and hop on Skype, or something like it.

Video meetings are something you should be comfortable with before you hire anybody to work remote. They’re essential, but they’re also a little awkward and weird at first. You and your whole team should be used to videoconferencing’s unique quirks and rhythm, and you should all know which tools work well for you. (Often, at a given company, your choice of videoconferencing tool may depend on something as subtle or idiosyncratic as a particular network configuration.)

Antipattern: That One Remote Person

The first experience that a lot of companies have with remote work is to bring in one remote employee, and give them unimportant projects to handle solo. This is a terrible idea. That employee will simply vanish off the radar, nine times out of ten, and afterwards everybody will say “remote just doesn’t work.”

All work cultures involve agreed-upon ground rules, and asynchronous work cultures need ground rules that encourage a lot of communication. A new remote employee should be collaborating closely with at least one other, more established employee. This is true even of experienced remote workers in a fully distributed company. There will always be particular ways you do things at any given company, and your new employee will have to learn what they are.

But if you don’t have experienced remote workers, and you aren’t a fully distributed company, pairing that one remote person with a collaborator makes even more sense. The thing to do is rotate collaborators, because every time you partner a remote dev with a dev physically located in your office, that physically-present developer is learning how to do remote work. Rotate your whole team through collaborating with the one remote worker, and they’ll all get a taste of remote collaboration.

Go Remote The Right Way

Remote work drives countless successful projects, both open source and commercial. Becoming a remote company makes it easier to find and hire terrific talent. But if you’re exploring it for the first time, don’t just leap in. Set yourself up to succeed.