's Remote Work Policy’s Remote Work Policy

“Remote Working Policy at”, by Liam Gooding, was originally published on Medium. It is republished here with permission.

Hiring full-time remote workers as early employees is really, really tough. Anyone who says it’s easier is lying. You have to build tons of trust, have tons of motivation, have faith in someone’s ability to know their optimum work environment, epic communication skills…

Formal rules seem untrusting, so it’s a dangerous game to publish them within your team. Fog Creek’s recent public guidelines were heavily flamed on Hacker News. If I were a remote worker at Fog Creek and I saw those rules go live, I’d be annoyed too.

Hopefully, these are some guidelines and ideas that might help you out. These are what we use right now in for a team of 6 remote workers (not all full time).

1. Use The Online Collaboration Tools To Your Advantage

Collaboration tools are essential for effective remote working. We have a few very simple tactics we use at to get the most out of these.

Log into Skype while you’re working, say hello. Log onto Sqwiggle, so your team mates get the collective benefit of a human environment. Keep your Trello cards updated, and reflective of what you’re currently working on. Complete your “write up” each morning.

None of these things are difficult. But getting buy-in on these tools is probably the most critical factor in effective remote working.

While there are more tools we could be using, we try and stick to the minimum essentials — and find Email fills the gaps fine. The fewer tools you spread the team across, the higher adoption rate will be.

Log into skype while you’re working

Honestly, seeing everyone in a Skype room has nothing to do with ‘checking up’ on anyone else.

We run a ‘15 minute’ rule at — if a developer gets stuck, you have 15 minutes to bang your head against it until you must ask someone else for help.

If there’s a Skype room always open, that means you can instantly ask for help but more importantly, people can instantly ask you for help.

We’re a team, and we have a much higher value holistically than the sum of our parts.

Log into Sqwiggle while your working

Since discovering Sqwiggle, it’s like we found the missing part of Skype. Having the ‘freeze frame’ image of your team seemed like a total gimmick at first — until we started using it. Seeing the people you’re working with, laughing when you see them spill coffee down themselves, commenting on their latest hair cut… these are social interactions that slowly build natural social bonds over time.

A much more experienced reader in sociology or psychology could put the proper theory to this argument, but trust me, it has an effect. Also, Sqwiggle has the advantage of jumping into instant conversations (very different to ringing for a phone call) which mimics the real world effect of being in an office. You don’t shout across the office and ask permission to talk to someone, you just walk over and start talking.

That’s what Sqwiggle gives us — instant chats with people/groups.

Keep your Trello cards updated

We have a bastardized agile framework at Matt and I have slowly evolved into it over the last few years of working together. It’s not strict scrum or kanban, but we do have a structure to follow. Trello isn’t the perfect tool, but it’s loose and minimalist enough that we can make it work to our needs.

Using a “(x)” in a card title is the effort in x hours, written from the perspective of a senior developer. A junior developer should add roughly a 1.5-2x multiplier to this.

A “[y]” denotes how much time has been spent so far. We’re also big users of checklists on cards, which help to give context to the effort spent value.

And optionally, a “{z}” is used if a card effort needed to be updated after work had started, but we record what the original estimate was for reporting. This is a good trailing indicator that our estimates are far out.

Having absolute transparency across the progress of each feature allows developers to work together better. Along with sensible and regular Git commits of course. Also, from a product management point of view, it’s great to be able to line up other activities such as big newsletters, customer expectations on bug fixes, etc.

We move cards around from ‘To-do’ to ‘This Sprint’ to ‘In Progress’ to ‘Done’and ‘Live’. We need total transparency about what everyone is working on, and how far along it is. Not because we want to check up on people, but because other developers want to know if they can jump onto a card. Or a card might be blocking theirs, so they want to speed it along.

Complete your daily write-up every morning

Every morning, we ask every dev member to complete a write up on a Trello card of what they did yesterday, what they plan to do today, and what’s puzzling them. It’s a useful technique, and it’s crazy simple.

We just have a loose “Write Ups” Trello card that sits at the top of our “Misc.” list, but there are dedicated apps to try and achieve the same effect like iDoneThis. But we stick to Trello to try and keep the number of tools down.

No one is reading each others “Yesterday” and “Today” sections to check up on each other, instead it’s so they can help each other. Also, by putting them out there for the whole team, it makes you aware of your own work rate. Setting targets for only the day ahead creates a realistic and finite ‘to do’ list for the day, which you can reflect on tomorrow.

It’s also a nice fresh way to start the day and a way of saying “Hey guys, I’ve now finished reading Hacker News and I’m going to start coding”.

2. Unlimited Vacation — with Notice

Like any company who wants their employees to feel trusted, we have an unlimited vacation policy. Honestly, if someone needs a break, there’s no point them sitting at a code editor and writing sub-par quality code that could otherwise be completed by a team member who is refreshed.

So sure, take all the time off you need.

But tell someone first. Taking vacation time, and not showing up, are different things. Again, this is nothing to do with trust or watching over people. But as a fast moving startup, we have a ton of stuff that needs to be done, and we set lots of internal targets. If we’re relying on someone being in the team that day, we’ve planned for their bandwidth to be added to the pool.

If we know they aren’t going to be there, we can adjust targets, set expectations for other people affected (bug fixes, journalists, investor demos) and that’s fine. Expectation management is everything.

[et_bloom_inline optin_id=optin_3]

3. Know Your Best Work Environment, and Work From There

Some people want to be in a closed door, quiet home office. Some people want to be in a buzzing and noisy open-plan coworking space. Some people prefer coffee shops, and being around people who aren’t all on laptops. Some people prefer to mix all of those together throughout the day (like me).

Everyone is different, and at we trust people to know what works for them, so it’s their call.

What isn’t appropriate, is a kitchen table while the kids run around you. That’s not remote working, that’s part time working. Again, this isn’t about trusting that you’ll always be working, it’s about trusting you to know your own ideal work environment.

This part also includes common sense things like making sure you have solid wifi and you can handle video calls. Your Skype account has credit for phone calls in case your mobile phone dies. Making sure you have nearby power so that your laptop doesn’t die.

To be honest, if people can’t figure this part out and need telling, then I need to start questioning why I hired them in the first place.

4. Make Time For In-Person Meetings

All of’s remote workers are in the UK (with the exception of 1, who’s kind of flying around between places).

We did this mostly for timezones — we want people to have as much overlap in work hours as possible. But also because we expect all our team to be able to get together each month.

We’re trying to build a culture, and that’s going to evolve from our early employees, not just our founders. We’d feel guilty asking someone from the states to fly in each month — but that’s the rules. So we ask all our team to make time for a monthly meetup in London. The people who are closer meet more regular of course.


Some of these guidelines may read like common sense to most people. And if so, I’m glad. Being a self-motivated entrepreneur for the last ~5 years, I’ve almost forgotten what it’s like to not be “on it” all the time. I struggle to fathom why someone would not want to be connected to their team. Why anyone would allow partners or children to pull them away from changing the world, one line of code at a time.

But not everyone is like that. Some people don’t “get it” right away. Hopefully, at we hire the right people, and if anyone does need to refer to these guidelines, it’s only in their first week and even then, there are no huge surprises.

But if, after a few weeks, we’re still having to direct people back to these guidelines, then it’s my experience that we’re just better off cutting loose now and going our separate ways.

Passionate and motivated people will find ways to be more effective. To get more done. To be a better team member. If you ever have to tell your team to not browse facebook during work hours, you’ve already fucked up.