We’re on a BOAT! Greece, resin.io summit ’15
If you’ve looked at our team page, you may have noticed we have people in 10 different countries, with clusters in Seattle, Athens, and London. While we started down this path by necessity, we jumped in with both feet early on and we now consider it one of our core strengths. We’re often asked about this and how we manage a team so distributed, so we wanted to write this down for everyone.
First of all, why even have a remote team at all?
To get the obvious thing out of the way, yes, there is a cost benefit. But instead of framing it in terms of “cheap labour”, we see it the other way around. Given a specific salary, we’re able to get people on board that are of extremely high quality, and for whom the salary is very meaningful rather than “just ok”. Resin.io is a complex project with a huge number of moving pieces, and not being able to get the right quality of people would mean not being able to build the service at all. On the other hand, doing distribution right also means a lot of hidden expenses, including a more complex legal structure (legal expenses!) and more travel, so while there are cost advantages, they may not be as big as you might think if you’re naively calculating based on a % of a developer in San Francisco. A deeper objection would be to challenge what makes San Francisco salaries the norm and everything else a discount to that, but let’s not go there.
There are non-obvious benefits to a distributed team though, and I’d like to put some emphasis on these. Having someone working remotely, means you can’t be looking over their shoulder all the time. This in turn means they will have to be self-managing to succeed at all, which allows us to have a team that is pretty self-organising and light on management. While needing self-motivated people does tighten the filter a bit, we’re also fishing in a dramatically larger pool.
Another benefit is that having a distributed team means having most communication online, which in turn leads to most things being written down. If there’s one thing developers hate it’s documentation, but the remote setup makes the need for this much more obvious, so that it’s easier for people to do it of their own volition, just to communicate their work to the team.
When combined with our support-driven development model, the distributed model also gets us incredibly close to 24/7 support. The multiple timezones may be an organisational headache, but with people from Asia, Europe, and the Americas on the team, they also mean someone is usually around 20 hours a day if not more. Support is another of our big strengths, so we value this advantage highly.
By disassociating work from workplace, we also allow people who need to focus to choose their environment. For the business end of the company (which also includes me) that often needs to travel, we ensure they’re not out of the loop but can participate in the conversation no matter what hotelroom they wake up in. In fact, we’ve actually seen people move away from the company hubs, given that working remotely is so effective that being in a big city loses a big advantage.
Florin, Lorenzo and Praneeth, resin.io summit ’15
So how do we do it?
The first thing to say here is that you have to be committed. Trying for a hybrid “local/remote” setup usually ends up with the remote employees feeling like they’re getting the short end of the stick. You need to be absolutely sure you are making everyone feel like a first-class member of the team. In this, we take a lot of inspiration from open source projects and the way they work. Besides the fact most of our code is closed-source (which is changing soon!), one would be hard-pressed to differentiate us from an open source project when looking from the inside.
In terms of tools, we have a core set use, and we have a culture that ensures that the tools are used. One of our engineers came up with “the four maxims” and we teach them to every new member of the team:
- If it’s not on chat it didn’t happen
- If it’s not in the issue tracker it won’t get done
- If it’s not on the wiki we won’t remember it
- If it’s not on the blog it’s not released
Oversimplified? Yes. Works? Absolutely. It’s important to note however that the maxims were (mostly) describing reality on the ground when they were coined, rather than an aspirational situation we wanted to realize. Having the maxims simply makes sure we don’t lose track of these realities we collectively value.
The core message of the maxims is to write things down and embrace asynchronicity. With a team spanning 15 timezones, it’s hard to get everyone in the same place at the same time. The good news is that remote working technologies are getting better every day, which means the world is working in our favour. We have a core set of technologies we use to manage our work. While we’re constantly re-evaluating our choices, here’s our current set:
- Issue tracker: JIRA
- Wiki: Confluence
- Source hosting: Bitbucket
- Team chat: Flowdock
- Voice chat: Mumble
- User support: Intercom / Zendesk
- CRM: Salesforce
There are of course many other valuable tools, and Zapier deserves an honourable mention for helping us tie a lot of the above tools together. As part of our transition to being an open source company we will probably move one or more of the above to GitHub, and in general we’re always open to suggestions in the comments!
We try to keep things light on meetings, but we do have a single, one-hour, all-hands call once a week, that people are heavily encouraged to attend. In this call, we summarise progress from the week before, and plan the next. We also try to resolve any issues that can be quickly resolved or set a time to deal with more complex situations.
A long-standing tradition of the team is to bring everyone together at least once a year for the annual “Resin.io Summit”. It’s always fun to see people who may have collaborated closely get together face-to-face. It’s very very interesting to see diverse cultures come together, and it’s actually eye-opening how easily people connect and make the events the most memmorable moment of the year.
What’s the catch?
If you’re setting out to build a team like this, you’re going to need a kickass operations team, and a good stomach for legal bills. We’ve lucked out in having Apostolis deal with a lot of the unglorious work of keeping up the illusion that everything’s easy, when in fact it’s everything but. A remote team will force you to deal with complex structuring issues much earlier than otherwise, but we are convinced it’s been worth it.
Undoubtedly a challenge we are facing is the outsized gender imbalance in the team, and it’s one we’ll work harder on this year. While we’re off the charts for every other measure of diversity, getting female contributors, especially in product-building roles, is not something we’ve done well at. Possibly due to our applicant sourcing process, less than 5% of the applicants we get are women, and even though we make a special effort to promote more women to the interview stage, we haven’t yet been able to add a female coder to the team. We’ve had several ideas on how to address this, and we’re seriously considering the idea floated by Glowforge to pay for referrals.
The remote model is not for everyone, but teams around the world have made it work, and as more blaze the trail and solve challenges, it’s getting easier and more tempting every year. What’s more, it has the characteristic of being very hard to give up once you’ve jumped in. Seeing things from that point of view, it’s getting harder and harder to imagine the future as anything other than a place where remote working is the norm, and the world is better for it. But this isn’t about science fiction. If you’re starting a company, accommodating remote work is one of the big decisions you’ll make early, and I’d definitely like to encourage you to consider it seriously.
Chat to the team on gitter.
