A Few Tips To Make Distributed Teams Work Well

An increasing number of startups seem to be building distributed teams, particularly in engineering. But making a distributed team work well isn’t easy. From what I’ve seen most distributed teams are less productive than their centralized counterparts. Here are a few things from my own experience that I think are crucial to the effectiveness such teams. If I had to summarize all of the below I would do it as: Remove synchronous communication, and when in doubt, over-communicate.

Hire people who thrive in remote environments

An otherwise excellent hire may underperform in a distributed environment. This has nothing to do with skill, it’s mostly a result of past experience and personality. Some of us enjoy the social atmosphere and tighter supervision of an office environment. Others thrive with little or no supervision away from all distractions. I found that the latter type of people tend to have experience with starting or managing their own projects, e.g. an open source project, side project, or startup. Explain the company’s goals and they will figure out the little details themselves, without the need for a lot of meetings. Look for these people.

Be proactive, not reactive, in giving access to resources

Communication in a remote environment is asynchronous, so your goal should be to minimize the need for synchronous communication. For example, a developer may be blocked by not having access to a code repository or SaaS service the company uses. In an office environment this isn’t a big deal, she can just walk over to a manager or teammate and get access. In a remote environment she may have to wait several hours to get it. If this happens frequently it adds up to a lot of lost time. Be proactive in giving everyone the resources they need to make their own decisions.

Don’t be a hybrid

It’s not uncommon to simultaneously run a distributed team and a “core” team in a centralized location. This is appealing, but it’s also difficult to get right. It only works if everyone follows the same procedures. It’s tempting for members of the core team to make quick decisions through in-person meetings and neglect discussing them with people who aren’t there. If everyone talks in Slack then the core team should do the same. Not doing so will result in an imbalance of information, or worse, frustration of people who are not “in the loop”.

Focus on process, not outcome

As long as a centralized team is small you can run it without a lot of formal procedures. Not so with distributed teams. An example for engineering teams would be creating formal procedures for Pull Requests. What should be in the title/description and acceptance criteria? Who should review/merge, and when? Defining all of this formally seems like overkill, but in a remote environment it ensures that everyone is on the same page and knows what to expect. More generally, your goal shouldn’t be to ship the next version of your product as quickly as possible (though that’s a nice side effect). It should be to build a scalable process , get out of the way, and make your team productive without requiring a lot of supervision. Formal processes help do that.

Have the right technology stack in place

There’s lots of software that makes working in a distributed team easier. It would be foolish not to use it. Use Slack for team communication. Blossom or Pivotal Tracker for task tracking . Screenhero for screen sharing. Google Hangouts for meetings. And so on. Of course the above are just examples, use any software that meets your needs. Again, make sure that you have processes in place that define how to use your software stack (e.g. how to manage and reviews tasks).

Get everyone on the same page

I found that many inefficiencies in distributed teams stem from the fact that team members aren’t on the same page about company priorities, or that they don’t know what everyone else is working on. This is absolutely crucial. Processes that I’ve found effective include using company and team OKRs, regular standups (either in Slack or via video chat), and doing weekly retrospectives of what has been accomplished, what didn’t go so well, and what the goals for next week are.

Consider Transparency

Buffer is probably the best example of a company that’s incredibly transparent. Transparency works well with distributed teams because it removes the need for communication. If something is open to everyone, employees don’t need ask around for access. You don’t need to become as transparent as Buffer is, but it’s worth considering what you could be transparent about both publicly and internally.

 

Why I’ll never go to an office again

Over the past few years I’ve had the chance to work with many distributed teams. Most of them were startups, but I’ve also done remote projects for larger corporations. I honestly have never been happier with my work-life balance and I firmly believe that distributed teams are the future of engineering organizations. I can no longer imagine living and working any other way. In this post I want to discuss what about remote work had the biggest impact on my personal happiness as well as some of the things I’ve learned along the way.

Increased productivity

Working remotely has helped me to better understand my body. Previously I didn’t have much choice in setting my hours. By tracking my productivity over the course of the day I found that I am most productive in the morning (6-11am) and early evening (4-6pm). I essentially can’t get any intellectually demanding work done during noon or late at night. Being in the office from 11-3 is a waste of time for me and for the company I work for. I don’t produce any output and I feel horrible. Setting my own schedule means that I can take a break at noon, get lunch, work out or go for a run, take a nap, and run some errands. Afterwards I feel happy, re-energized and ready to get stuff done again. I know plenty of people who love to work late at night. So why not let them?

While some centralized teams offer flexible hours with they usually come with limitations. If you have a long commute (next point) what can you really do within 4 hours of free time? What if there’s no gym or track around your office? What if you want to buy groceries for your home? What about the peer pressure of eating and hanging out with co-workers? If you’re the only person in the office at midnight what’s the reason to being there at all?

No commute

Studies have founded that a long commute has negative effects on life dissatisfaction. The longer the commute the more pronounced these effects are. Some people succeed in setting up a home office but for many (including me) it’s rather difficult to get serious work done at home. I typically work from a co-working space pretty close to my house. So it isn’t quite true that there is no commute, but usually the commute is much shorter and doesn’t feel like a commute. For example, I walk to my favorite coffee shop in the morning and enjoy getting some fresh air. That’s pretty different from a 1-hour drive and being stuck in traffic.

Reducing the commute has been huge for me. You may have gotten used to it already, but don’t underestimate the stress that comes from commuting. I no longer worry about when exactly to leave home, whether or not there’s traffic, or when I will arrive at my office. As result I feel less stressed and more productive throughout the day.

Flexibility and ability to travel

Centralized teams have setup a structure of synchronous communication where not being in the office at usual times breaks processes like scheduled meetings. Distributed teams typically designed their communication structure to be asynchronous and less reliant and people being available at the same time. This means that occasionally changing the times you work isn’t such a big deal. When I have an appointment, errands to run, or want to show a friend around town I simply change my hours to make room for it. I can also satisfy my urge to travel to other places or countries. My favorite places to live in are currently Japan and Thailand, and I’ve been traveling back and forth between them.

Office politics and gossip

This point isn’t really a result of working remotely but rather of how distributed teams or typically setup and run. Humans are social animals and as the team grows it’s inevitable that office politics and social hierarchies develop. I am not talking about professional relations, these are usually pretty clear, but interpersonal ones. Things that are seemingly unrelated to work, such as forgetting someone’s birthday, deciding what to get for lunch, or not going out for beers with the others inevitably spill over to professional interactions (sometimes just subconsciously). While some people benefit from these things, they can become a huge factor of stress and work dissatisfaction for others.

Distributed teams don’t avoid office politics completely, but almost. Restricting in-person social interaction and focusing on trackable results and metrics leads to significantly less politics and stress. Separating work and personal life is much easier when working remotely.

What about the employer’s perspective?

To make distributed teams the norm we need to make it lucrative for both sides, the employee and the employer. This post is written from the employee’s perspective and that’s arguably the easier side to convince. The benefits for the employee are pretty well understood and there are enough people who want to work remotely.

However, making distributed teams more productive than centralized ones is hard. Asynchronous communication is probably the main reason for this. Most distributed teams I’ve worked with were probably less effective than if everyone had been in the same space. But I don’t think it has to be this way. With the right processes in place I believe that we can make distributed teams work for both employees and employers. I’ll discuss some of the things I’ve learned from the employer’s side in a future post.

I’d love to hear about your experiences with distributed teams.