We were founded as a remote-first company, some might say before it was cool™. But what does remote-first really mean?
Almost 18 months ago I joined the company as a software engineer. While I’d worked as a remote employee for office-based teams before, this was my first role for a remote-first engineering team. We have engineers spread across many European countries including the UK, Germany, France, Italy and Czech Republic.
I want to talk a little about the processes that make us an efficient, happy and productive remote team and why it’s significantly different to “we offer remote working a couple of days a week” or you can work remotely “when you need it”.
Excellent written communication is at the heart of our company. When a new team member joins they may or may not get an in-person induction, but they will definitely have plenty to read! We want to empower people to get started quickly and so, if you want to know how to do something, there will be a page for it in our company wiki.
We aim to record and write down all important processes because we don’t want information to be silo-ed in a few people’s heads. It’s important that the information is right there when you need it, as we don’t assume everyone will be available to answer questions all the time. We use Github’s wiki feature, everyone has write access and is encouraged to keep it up to date.
We have lots of technical documentation covering topics such as database migrations, our approach to testing, how our internationalisation has been implemented, details of all our provider integrations and lots more. It also includes more routine things like how to claim expenses and various company wide policies.
The daily stand-up
It’s become fairly common practice among software development teams to have a daily stand-up to check in with each other. This is to let everyone know what you did yesterday, what you intend to do today and raise any blockers.
Our stand-ups involve us leaving a message each morning in our stand-up chat room on Slack. We find this allows us to convey the information we need to our team members, without requiring us all to be online and available at exactly the same time.
Stand-up meetings can be easily side-tracked by tangent conversations between only a few developers and this can be a real time sink. One benefit of these written messages is that you can look back to see what people wrote on previous days (great for catching up when you've been on holiday or off sick).
Get in the flow
As a distributed company you might assume that our messaging platform (Slack) is super busy with messages flying back and forth. However, we place great importance on the periods of uninterrupted time required to achieve flow. It’s not uncommon for people to go offline completely to ‘get some work done’ and there isn’t an expectation to be reading every message all the time. Our culture encourages respect for a co-worker if they have put a status on Slack such as ‘concentrating’ or, indeed, ‘gone for a short walk’.
One of the ways we keep the noise down in our Slack channels is to move important discussions to other tools that are better suited to the job. Like most software development teams, we use a hosted solution for reviewing our code (Github). Discussions about specific tasks that involve product managers or designers occur on our project management tool (Trello). However, I think that our usage of Basecamp message boards to conduct long-form discussions asynchronously is what really helps reduce the Slack chat.
Obviously it's not practical for us to have in-person meetings but, even with advances in video calling technology, we generally we try to keep all meetings to an absolute minimum. Long-form Basecamp message threads play a huge part in that. By communicating over Basecamp, respondents can catch-up on the conversation when they’re ready and be considered in their response. This really benefits the personalities in the team that don’t necessarily ‘shout loudest’ during an in-person meeting. It gives everyone a fair chance to contribute, not just those who happened to be in the office that day or on the Slack channel at the time. It also means the lines of communication are always open, not just when you can schedule everyone to attend a meeting.
With all this communication in Basecamp there is a wealth of information on how decisions were reached, as well as showing any concerns that were raised and alternative approaches discussed. This is really helpful for new team members to catch up on recent decisions.
As someone used to lots of in-person meetings and chat over Slack, I was initially surprised and somewhat sceptical of this approach. I had assumed discussions would take forever and it would be inefficient compared to the immediacy of chatting in-person. However, I now can see how critical this asynchronous method of communication is to a remote team. Longer, more considered discussions often result in a decision that has more "buy-in" from the team. Anecdotally it also feels like we reach well thought-out solutions which, in the end save us time.
As a distributed team we have to trust and empower each other to do our best work when no-one is watching. Good documentation, communicating asynchronously and focusing on outputs enable this. Everyone gets to optimise their work day to suit when they're most productive and blockers become less of a problem, as everyone knows how to spend time productively on parallel tasks. I'm not advocating that remote working is the only way or always the best way for every team, but I do believe that many co-located teams would benefit from adopting the practices of remote work.
If this sounds like the kind of team you'd like to join, check out the careers page on our homepage.