Ten years ago, it would have been unlikely for a developer without prior job experience to be accepted into a remote role. However, today, there is a strong likelihood that you won't need to commute to your first workplace.

I've been working remotely since 2015. It was one of the best choices I made as a developer. Thanks to this experience, I did many remote interviews, worked with companies and hired contractors across the globe, participated in seminars, and gave talks, all from my living room. Or sometimes the kitchen because it's a few degrees cooler there and I can see our garden. Just to mention one of the perks of working remotely.

Like office work, remote work performs best if both parties agree on some ground rules.

This is not a comprehensive list but rather a compilation of what I have discovered to be some of the most critical factors that can occasionally make the difference between sustaining or terminating a remote collaboration.

So, let's dive into it! Rule Zero:

Ask

The one that goes without saying.

When something is unclear, ask. Depending on the issue's importance, ask immediately, through Slack or in a follow-up email. Remember: there are no dumb questions, only dumb answers.

Follow the Rules

Stick to the team's existing principles.

When you join your first remote team, most likely, you aren't the first one, and the team already knows how to handle a remote staff – if they don't and you're indeed the first one, just make sure you both read this blog post til the end 🙃

I like to kick off my remote work collaborations with a neatly formatted list of the core things we follow as a functioning remote team.

That's pretty much these points summarized, plus a few things on how we work with issue boards and pull requests.

But imagine a bullet list with 4 points.

It's not rocket science – on purpose. It feels like you already know all this. As a result, I noticed people glance over the list, thinking, "I've got this."

Except they don't.

They'll follow the first and last points, but I never expect miracles here.

The reason why I have a list like this is that I know exactly what are the routines and the procedures that are going to make or break a collaboration.

Better to follow them as they are. But even if you follow all the rules and listen carefully, you'll be running into problems during your work. This is why it's essential to:

Communicate Often and Early

Nothing's worse than hours or days spent without progress because we're in different time zones, and by the time I could formulate my question correctly, another day had passed.

I couldn't work on my top priority issue because I got no answer on time, and because of this, I had to do some minor tasks that won't move the needle for the company.

It's a terrible feeling for both me and the client.

Delayed or inaccurate communication can be costly.

Because of this, make sure to communicate often and early.

Provide as detailed context as possible, link to issues, pull requests, chat messages, screenshots, screen recordings, and whatever it takes to give the most context possible for the client to decide the next step.

When you see something is not going to work or you've been in a similar situation and already know the drawback, let the project leads know. They don't know every little detail, but they'll welcome (and remember!) if you come forward and say, hey guys, just FYI, I already tried this in another project, and it doesn't work. Most likely will need a different way to solve this. This saves time that makes everyone happy, just as this next point:

Respect Each Other's Time

Whenever I do calls with clients across the globe, we always spend a few minutes talking high level about the project. Where are we headed, how's everyone, and talk about things other than the weather - I have long-term clients. Some are 6+ years!

But when the time comes to discuss the real reason for our gathering, we're concise and well-prepared.

There's nothing worse than jumping into a call unprepared.

The client went out of their way to organize it with you, and now you're sitting in Zoom, and you realize you didn't switch branches.

You didn't load the data that's needed to reproduce the issues, and you already forgot what's the issue anyway.

You just lost 2x10 minutes. That could have been only 10 if you had come prepared.

Make Yourself Available

Remote and async work is the best, but sometimes we need to organize calls to brainstorm, discuss high-level stuff, or debug a problem that can only be reproduced on the clients' Windows machine in Opera.

Let others know when your core working hours are - if there is such a thing, but if there isn't - when you're open to taking calls.

Nobody loves sitting on calls. Calls are blocking, so I prefer to use them as a last resort, and if I feel something doesn't have to be a call, I say that, say why, and what we could do instead.

Summary

Bookmark this guide as a reminder you pull up once you land your first remote job. Take 5 minutes to read through this, and you'll be off to a great start.

I promise you, all this is much, much simpler once you get the hang of it. It's certainly easier to follow than to write about it. 😄 And getting to work remotely is worth it 100%.

My goal was to give you a taste of what kind of problems can occur in remote teams that can hinder the work or worsen the quality of collaboration for both parties.

I hope it helps, and good luck with your next remote opportunity.

- Akos