We are fully distributed
From the very first day, Screenly has had a distributed team. It’s in our DNA.
For some people, it is 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 for rent, utilities, and transportation, but you are also limiting your talent pool to your local area. Moreover, some people work better from home (such as my co-founder Alex), and others people work better 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 do not want to force people to work in a specific way. Most experienced people are well aware of how and where they perform their best and are most productive. Our job is to enable them do this and to get out of their way. It is as simple as that.
As of right now, our team already stretches across five countries, including Portugal, Russia, Switzerland, the UK, and USA.
Few meetings, fewer emails, and no phones
As much as we would like to have a no-meeting policy, it is not entirely viable. We try to limit our team meetings to our sprint planning/review sessions (which we do every two weeks).
Granted, if people want to jump on an ad-hoc Hangouts call to discuss something, they are more than welcome to do so, but we don’t want people to get dragged into endless meetings where they are not needed. That is 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 is deeply focused on something. The truth is that unless you have managed to bring down the entire production environment, a interruption 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 do not have company phones. If we want to get in touch with someone on the team, we ping them in the company chat.
It is also worth noting that we more or less do not use any emails internally. Granted, we do use emails to communicate with external parties. However, we typicall do not use email internally unless there is an external party involved.
No set hours
While this work policy is becoming a less controversial topic, we have been big fans of this for years. In short, we do not 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 every day such that your colleagues can ask you questions.
Get your sleep!
Sleep is important. Sometimes it is 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.