Losing the remote – 3 things I learned building a distributed team from scratch

March 2018

Minutes after posting a job ad for our first remote team member, we had almost 100 applicants. We were looking for our first full-time employee at our bootstrapped SaaS company Boords, and the excitement was palpable.

The following morning, I eagerly checked my email to find we had over 500 applicants. The next day it was 1,000.

People with experience at some of the companies we admired most were in there. We couldn't believe it. We were giddy at the prospect of what they could bring to the table.

But there was a problem. A big one. It turned out we could hire almost none of them.

Not because the applicants weren't qualified, the vast majority were, but because we hadn't done our homework. We'd fallen into the first of the three principal challenges we've faced as an early-stage distributed team.

You'll need to know who you can hire

One of the most often touted benefits of working in a remote team is that you get access to very highly qualified people without any geographic restrictions. This is true but doesn't take into account the legal angle.

For example, if you're a UK company, it's very challenging to employ someone full-time who doesn't have EU citizenship. We found this out the hard way and wasted 1,000 people's time in the process. Not cool.

Timezones matter in small remote teams. If there are 3 people in your company, do you only want a 1-hour overlap where you can all talk? Probably not. Specify timezone restrictions when you're writing your job ad. Find this kind of thing out ahead of time, and you'll save everyone involved a lot of hassle.

Practically speaking, we found the best applicants using Remote OK and We Work Remotely. Workable is the best way of managing applicants as it's quick to publish a job and provides some nifty templates for moving people through the interview pipeline.

You'll need to be noisier

Good communication is fundamental for any organisation, but it's particularly critical for distributed teams. With vastly-restricted non-verbal cues, all other communication needs to be turned up.

If someone is sitting on the next desk, it's clear if they're having a tough time or running low on motivation. However, if that person at the other end of an internet connection, it's much, much harder to get that feedback.

If in doubt, say something. Ask a question, or just check in to say hey. I've never regretted sending a message to someone to see how they're getting on, but I've regretted staying quiet.

You'll need to create structure

Physical working conventions can be restrictive, but they also help give the workday structure. None of this exists for distributed teams. If you want to give your team structure, you'll have to create it from scratch.


Start every day with a video chat with the whole team. We use Zoom. There's no substitute for face-to-face time. Put a regular 5-minute meeting in the calendar, and stick to it.

Like many other distributed teams, Slack is at the centre of our workday. If you need to step away from your computer during the day, set your Slack status to let your team know where you are. There's nothing more frustrating than not getting a response from someone with no idea where they've gotten to.

It's useful to hook up integrations from services you're using to post activity into Slack. For example, whenever someone purchases a Boords plan or sends a message on Intercom, a message is sent to the relevant Slack channel. Similarly, we have our various Trello boards connected to Slack, which helps increase visibility across the team. Zapier is very useful for this kind of thing.

At the end of the day, it's nice to bookend things with a little "cheerio" message before leaving. You wouldn't just walk out of an office without saying goodbye, so don't do it in a distributed team either. It's a good opportunity to call out any successes the team have had that day, too.

The weekly sprint plan

Every Monday morning we have an extended video call to plan the upcoming sprint. This usually takes between 30 minutes and 60 minutes. During this call, we:

  • Review what was achieved during the last sprint
  • Go through anything which is in progress
  • Run through user feedback or bug reports
  • Set a concrete goal for what we want to accomplish during the sprint

Our sprints run for a week or two. Having tried a few alternatives, Trello has proven itself the most efficient way of managing our sprint backlog. It's simple, quick to learn, and versatile.

One of the more useful integrations we've set up is a Typeform feedback form, which is connected to our current Trello board. Whenever someone leaves feedback or a feature idea for the app, a card is created. We then go through these as a team, together with any feedback which has come in through customer support. It's a great way of allowing the whole team to see how users are feeling about the product.

Reviews and 1-to-1s

As we're a small team, we all speak with each other very regularly, sometimes several times a day. Nonetheless, it's important to make time to have a focussed 1-to-1, where any thoughts or concerns can be raised. These happen every week or two. We use Lattice to run all our 1-to-1s and review cycles, and I can highly recommend it.

We're a small team of 3 people, and I've no doubt we'll be adding to this list over the coming months.

I'm also sure that our challenges are different to those faced by other early-stage distributed teams. If you're in the same boat or equally have had a different experience, I'd love to hear about it. Just let me know in the comments.

Ever wish you got more email?

Neither do I. You're busy, and so is your inbox. I'll only be in touch when I publish something new. And of course it goes without saying your email will be kept completely private.