We are fully distributed
For some people, it’s still controversial not to have an office where everyone must show up in the morning.
For us, this idea of a mandatory office was never appealing. Not only are you adding extra cost, but you’re also limiting your talent pool to your local area. Moreover, some people work better from home (such as my co-founder Alex), others from coffee shops or from a desk at a local office space. Personally, I like to mix it up.
The bottom line is that we don’t want to force people to work in a specific way. Most experienced people are well aware of how and where they perform at their best. Our job is to enable them do this and get out of their way. It’s as simple as that.
As of right now, our team already stretches across five countries, including Portugal, Russia, Switzerland, the U.K., and USA.
Few meetings, fewer emails, and no phones
As much as we’d like to have a no-meeting policy, it’s not entirely viable. We try to limit our team meetings to our sprint planning/review sessions (which we do every two weeks). Beyond this, we only have a daily standup for 15 minutes that we do in the chat.
Granted, if people want to jump on an ad-hoc Hangout to discuss something, they’re more than welcome to do so, but we don’t want people to be dragged into endless meetings where they are not needed. That’s a waste of their time. A meeting is the fastest way to turn a group of productive people into a group of passive listeners. Keep it short and sweet.
Another thing that is hard for some people to get used to is the notion of asynchronous communication (i.e. to expect not to get an instant response). However, when you are working with knowledge workers (like we all are), the last thing you want to do is to interrupt someone who’s deeply focused on something with a question. The truth is that unless you’ve managed to bring down the entire production environment, it can wait at least one Pomodoro, which is usually enough for the other person to wrap up whatever he or she is working on and get back to you.
Because of this focus on asynchronous communication, we don’t have any company phones. If we want to get ahold of someone on the team, we ping them in the company chat.
It is also worth noting that we more or less don’t use any emails internally. Granted, we do use emails to communicate with external parties, but beyond this, we never use it internally unless there is an external party involved.
No set hours
While this is becoming a less and less controversial topic, we’ve been big fans of this for years. In short, we don’t have any set hours for anyone involved with Screenly. If you want to take a day off in the middle of the week, go for it. Want to work less during the week and more on the weekend? Go for it. As long as you get your work done in time (which is mostly determined by the sprints), the rest is up to you. The only thing we ask from our team members is to make sure to be online during the 15 minute daily standup every day such that your colleagues can ask you questions.
Get your sleep!
Sleep is important. Sometimes it’s unavoidable to pull an all-nighter, but it should be a rare exception, not a frequent event. For far too long, it’s been viewed as macho in the tech scene (in particular in Silicon Valley) to only sleep 3–4 hours per night. And sure, some very few people can get by with that, but they are outliers. The vast majority of use need 7–8 hours of sleep.
This is why we encourage all our team members to get 7–8h of sleep each night. The reason is simple. If you don’t get enough sleep, your performance will decrease. This really comes back to the concept of that it isn’t the number of hours your work that matters, but what you get done. Not only will you be more productive if you get enough sleep, but you will also be healthier.
When you are building a distributed team, trust is one of the most important things. If you don’t trust your team members, you’ve already lost. In our experience, if you hire smart people and get out of their way, they will perform. There are of course people who cannot work in an environment like this, but it usually becomes clear in a sprint or two if they’re not cut out for it. Working remotely is not for everyone, but in our experience, the people who seek out these roles usually are the right type.
Lastly, let’s talk a bit about tooling. Since you won’t be interacting with your team members face-to-face on a daily basis, the tooling that you use to collaborate and communicate is essential. Over the years, we’ve tried a lot of them, but we are now very happy with the tools that we are using. Here are the most essential ones.
The reason why we like Phabricator is because it is a much more powerful project management tool than Github. It also provides us with the option to host our own git repositories. It allows us to do Kanban-style work boards for sprints, as well as code review and other nice functionalities.
While Slack is all the rave right now, we really prefer Flowdock. We’ve been using Flowdock for years, and it works really well for us. One of the primary reasons why we prefer Flowdock over Slack is that you can have nested conversations in a single channel. This allows you to have long-going threads of conversations without confusion or having to break them out into separate channels.
Moreover, thanks to the ‘Inbox’ feature, we are able to pull in external data (such as Phabricator and Zendesk), and discuss this in a thread without having to break it out into a separate channel. Simply put, it’s more manageable.
As mentioned earlier, we try hard to minimize the number of team meetings. When we do meet we want it to be face to face though (if virtual) to get a moment of that human connection. We’ve found that Google Hangouts (with video) works very well compared to most other tools we’ve tested (including Skype).
The only drawback with Google Hangout is that it is a massive battery drain, but that’s a reasonable price to pay in our opinion.
Since I first wrote this blog post, I’ve published the article A Decade of Remote Work on my personal blog. The article provides some additional insights into what I’ve learned over the years both managing myself, as well as building and managing remote teams.