Why fully distributed is by far the best way to run a software team
At Red Planet Labs we’ve been operating as a fully distributed team for about a year. We have employees in New York, California, Ohio, and Quebec. Before starting Red Planet Labs I had only worked on colocated teams for companies ranging from tiny startups to big corporations. From my prior experience I felt there had to be a better way, and I learned a lot from talking to other Clojure-based companies with fully distributed teams. Though I still had a bit of uncertainty on the specifics, I saw enough advantages that I decided to found RPL as a fully distributed company. One year in, I now feel the “argument” between colocated and distributed for software teams is so stacked in favor of distributed that it’s not really even a debate.
I want to cover a few things in this post. First I’ll explain the plethora of advantages distributed teams have. Then I’ll go over the details of the processes we use at Red Planet Labs to operate our distributed team.
The case for fully distributed
At Red Planet Labs we’re building a cutting-edge product that’s extremely challenging to build. The scope of our product is immense and I think it’s one of the most ambitious endeavors in the software industry today. Building this product involves tons of open-ended design decisions that require a lot of discussion and coordination from the whole team. We can’t go off and spend all our time working by ourselves — collaboration is critical to everything we do.
With that said, here are the advantages of distributed I’ll be diving into:
- Collaboration and communication are better
- Ability to focus / way less interruptions
- Flexible working hours
- No commute
- Recruiting overwhelmingly better
- Can optimize personal work environment
- Less illness
- More scalable
Some of these improve the well-being and work/life balance of employees, which I strongly believe pays dividends back to the company.
Collaboration and communication are better
Most of the arguments I’ve heard against distributed have something to do with the supposed difficulty in collaborating when you’re not in the same room as your coworkers. They go something like this:
- “It might be good when the company is more mature and doing incremental work, but in the early days you really need to be in the same room to figure things out.”
- “When you’re in the same room you can overhear your coworkers and can sometimes spontaneously contribute to their conversation. You might know something that helps them, or they might give you a great idea.”
There’s two problems with statements like these: they assume distributed can’t achieve the same things, and they completely discount what you get with distributed that colocated fundamentally cannot achieve.
Statements like the first one are basically saying distributed doesn’t work well for tasks that require a lot of coordination. There’s an implication that you can’t figure things out unless you’re at a whiteboard brainstorming with your teammates. I think people who say this either have only worked on poorly run distributed teams or simply have a lack of imagination.
At RPL we do open-ended work that requires lots of coordination all the time. Between online chat, video calls, screen sharing, JIRA tickets, and pull requests, we’re able to communicate and discuss however is most appropriate at any given time. It’s true whiteboarding isn’t as good when you’re remote, but the tools out there to fill that purpose are actually pretty decent. They take a little longer than actually having a marker in your hand, but they get the job done.
The second statement assumes spontaneous moments of inspiration are not achievable in distributed. However, in distributed overhearing your coworkers is replaced by seeing what your coworkers are writing to each other in the shared chat room. Unlike overhearing something verbally, you can “overhear” something online a minute, an hour, or a day after the conversation happened. Additionally, the conversations are stored and searchable.
Where distributed gets one of its biggest advantages is how it modifies what forms of communication are most convenient. Specifically, in distributed synchronous communication is less convenient than asynchronous communication. In colocated, the most convenient form of communication is usually to interrupt your teammate when you have a question. In the process you may have interrupted your teammate out of deep thought, and the subsequent conversation is ephemeral. In distributed, you would leave a comment on a pull request, comment on a ticket, or send a message in the team chat. In all cases anyone on the team could help you, the conversation is recorded, and in no cases is someone forced to be interrupted out of deep thought. That distributed makes better and more open communication more convenient in this way is absolutely invaluable. And this leads to better collaboration.
Ability to focus / way less interruptions
When I used to work in offices I heard this “joke” many times: “I get most of my work done after working hours.” Any programmer can immediately identify with that, and it’s an unfortunate indictment of how much a colocated environment interferes with programming — especially open offices.
There are incredible numbers of distractions and annoyances in an office: people chatting, chewing, sneezing, walking, opening/closing doors, tapping you on the shoulder, and more. Programming requires intense concentration for long periods of time, so it doesn’t make any sense that the most common environment for programming — the open office — is the default.
When you work distributed, you’re in a quiet environment where it’s easy to tune out distractions — just don’t look at chat. So instead of waiting until 5pm to have quiet time to focus, you have it all the time. And this leads to massively increased productivity.
This cartoon sums it up:
Flexible working hours
In a distributed team using lots of asynchronous communication, you don’t have to work the same hours as your teammates. At RPL we have some synchronous meetings, like daily standups and pair programming, but we limit those to at most two hours a day. Beyond that, you’re free to allocate your time however is best for you. So if you want to go exercise for two hours in the middle of the afternoon, or you have to go take care of your kids, nothing is stopping you.
Working from home eliminates commuting, which frees up a lot of time each day — commonly one to two hours. That’s a lot of extra time every day that can be spent working, on hobbies, exercising, spending time with your family, and so on. This is really significant.
Over the course of a 30 year career, freeing up two hours every day frees up 600 days in total. That’s like getting another 1.5 years of waking life for free.
Recruiting overwhelmingly better
When you recruit for a colocated team, you’re limiting yourself to the people who live in your town or who are willing to move to your town. One city is a tiny fraction of the surface area of the planet. When you recruit for a distributed team, you’ve now opened the entire planet as candidates for your team.
In reality, time zone issues will limit you somewhat — at RPL it is important we’re able to sync up sometimes for things like standups and pairing. But this still gives you access to a massively larger pool of candidates than colocated does.
Had I gone the traditional route of founding a colocated company in SF, I would not have had access to most of my team. Therefore it would have taken me longer to build my team — and likely I would have ended up with a weaker team since I would have been recruiting from a much smaller pool. This is an absolutely massive advantage of distributed.
Can optimize personal work environment
When you work from home you can optimize your work environment totally for your needs. For example, I work on a walking desk at 1mph. It’s a much healthier way to work that’s usually not accessible in an office.
Many people say working from home is problematic because you can easily get distracted. I do get distracted sometimes working from home, but that’s a lot better than being distracted all the time in an open office.
Eliminating commuting and not being around sneezing teammates means you get sick less. That’s an awesome advantage. Additionally, the extra time and flexible working hours means it’s easier to find time to exercise. And since you’re working from home, you can control your diet much better. All this leads to the opportunity to live a much healthier life.
In a colocated team, you inevitably outgrow your office as the team grows. For a time, you’re packed into an office which isn’t really big enough for the team until you find a bigger office. Moving offices takes awhile and can be highly disruptive. When I worked at Twitter we moved offices before the new office was fully finished, and there were jackhammers in the office all day for weeks.
Distributed doesn’t have any of these issues by definition.
I would pay a significant premium for all the advantages I listed — a higher quality, more productive, and happier team. But it turns out running a distributed team is cheaper than running a colocated team. The only comparable expense to an office are the team onsites we do twice a year. The cost of flights, hotels, and activities for those onsites is much less than the cost of renting office space all year round. This is the cherry on top of an already superior way of working.
There are some tradeoffs with distributed, though these mostly depend on individual employees. Some people prefer to be in an environment where they can shoot the breeze with coworkers or hang out after work. Personally I would question whether that’s really worth the commute, the distracting environment, the less flexible working hours, and getting sick more often.
For the company, distributed is just overwhelmingly better. The increased productivity, superior recruiting, and greater scalability are game-changing benefits. Employees who don’t want to work in a distributed environment won’t apply, and this doesn’t matter because the overall pool of candidates is so much bigger for a distributed company. At RPL we have had no issues finding strong candidates.
Distributed does come with increased legal and HR burden for the company, especially if you hire internationally. RPL has employees in both the US and Canada. US employees are easy to manage through Gusto, and figuring out the intricacies of hiring in Canada wasn’t too bad with the help of our lawyer and accountant. I could see how hiring across many more countries could quickly become very complicated though.
How distributed at RPL works
In a colocated team, you naturally gain a feeling of camaraderie with your teammates — you eat lunch together, take breaks, or hang out outside of work. This feeling of camaraderie is important but you don’t get it for free in distributed. It’s not hard to achieve, but you have to consider it explicitly.
We regain that camaraderie at RPL through daily standups and pair programming. We do our standups in a group video call rather than via chat so we get a little bit of face time with the team every day. A silly thing we do at the start of standups that I think is actually really important is “question of the day”. Every day we rotate who asks a question to everyone on the team. These questions have ranged from “What do you think is overrated?” to “What was your best vacation?” to “What’s your relationship with Rubik’s cubes?”. They usually inspire about 15 minutes of conversation that goes a long way in us getting to know each other as individuals.
Of all the processes we use, I think pair programming is the most important. The goal of pairing is twofold: gain that feeling of camaraderie with your teammate, and share knowledge. The goal is not to share equal responsibility for a project. When we pair, whoever owns the project drives on a video call by sharing their screen. The other person is there to talk things over, learn, and maybe help a little bit. We iterated a little bit on the frequency and length of pairing sessions, and we ultimately settled on pairing one or two times a day for 45 minutes a session. On days where we have another team meeting we pair once, and on days where we just have standup we pair twice.
There are two kinds of pairing: random pairing, where you switch pairing partners every day, and dedicated pairing, where you pair with the same person driving every day for a week. Random pairing gets you great exposure to everything going on at the company, while dedicating pairing gets you a deep dive into one person’s project. Since you don’t always have a week’s worth of coding, opportunities for dedicated pairing are sporadic but we look for opportunities when we can.
Process-wise, standups and pairing are the core of how we operate. Because of these processes we don’t feel distant from each other even though we’re hundreds of miles apart.
We do onsites twice a year where we all work together from NYC for a week. The focus of these onsites is more on hanging out and team-building than working, although we do still get a lot done that week. Some of our favorite activities have been escape rooms, playing ping pong, going to a comedy club, and board game nights. The twice a year schedule is something we decided as best for our group, though I have heard of other companies doing them more often.
There’s two team meetings we do over a shared video call. The first is our weekly team meeting on Fridays. I send out an agenda email the day before and anyone is free to reply to the email to add agenda items. We discuss anything from administrative things like holiday schedules to process adjustments to technical design issues. It’s a good chance to sync up as a team and have deeper team discussions.
The second is our quarterly meeting. There’s two parts to our quarterly meeting: first we review our goals from last quarter, evaluate our performance, and make goals for next quarter. The second is we review and discuss every process we use and decide whether to keep, modify, or remove the process (including the quarterly meeting!). This is the crucial feedback loop that lets us optimize and eliminate waste from our operations.
Since RPL started with me doing five years of research on my own, when I brought more people on board there was a huge knowledge gap. Some of this knowledge gap was addressed through our shared wiki which currently has 98,000 words of documentation on it.
We found that wasn’t enough, so for a time we did a weekly meeting called “Storytime” where my teammates would request topics for me to dive into over video call. After a few months we ran out of things to talk about, so we replaced that meeting with “Reverse storytime” where an employee would learn some core topic and teach it to the rest of the team. This has been a great process — the best way to learn is by teaching, and my teammates teach things in a totally different way than I would because they come at the topic from a much fresher perspective. Since Reverse storytime is a big time investment to prepare we only do it every four weeks.
Lastly, every six weeks everyone does a presentation on the work they’ve done in the past six weeks over video call. This is a great chance to do an organized deep dive into someone’s work.
Although I’ve listed a lot of meetings, because most of them occur relatively infrequently most weeks we only have standups, pairing, and our weekly team meeting. Our day-to-day development process is asynchronous and revolves around making pull requests and asking for code reviews as necessary.
Every month we spend one day dedicated to cleaning up our codebase, paying off technical debt so those small issues don’t accumulate to slow us down.
You can’t measure programmer productivity, and that’s not for lack of trying by the industry. Just because you can’t measure something doesn’t mean it isn’t important, and for a software team programmer productivity is crucial. When you try to quantify too much you end up optimizing only for what you can measure, which can inadvertently sabotage what’s most important. I call this the “tyranny of quantification” and I think it goes a long way in explaining the popularity of open offices. The counter to the tyranny of quantification is to learn from experience, which is what I’ve tried to do as founder of Red Planet Labs by forming a distributed company.
I’m confident we’ll be able to scale our distributed team at RPL to however large we grow. Companies like Elastic and Gitlab have proven it can be done. Undoubtedly we’ll have to evolve or replace many of the processes we use. For instance, question of the day will probably become unwieldy when we become much larger. But I’m sure we’ll find alternative, more scalable ways to achieve the same goals.
I love working on a distributed team. It’s pure joy to be so productive all the time and collaborate so smoothly with my teammates. Though I think it would be difficult to convert an existing colocated company to a fully distributed one, I hope more and more new companies see the light and help advance the culture of our industry into a new generation.
Want to join us on our mission to radically change the economics of software development? We’re hiring!