When you're building or scaling a software engineering team, you naturally run into a choice at some point: will we all be in the same office, or will we do this "remote work" thing? There are a lot of factors that go into whether or not remote work will work for your team, like if you know how to work remote. Another consideration, to make it more complicated, is which form of remote work you want to consider.

There are four different "topologies" of remote work that I've observed:

1. The Linux model: fully remote, fully asynchronous
2. The Basecamp model: fully remote, somewhat synchronous
3. The hybrid model: half remote, half colocated, fully synchronous
4. The traditional model: colocated team, possibly with some remote team members

I've been on three of these types of teams, and I've seen the other quite a bit. Let's take a deeper dive into each of them, and then talk about how to make a decision at the end.

The Linux model: fully remote, fully asynchronous

This model is common in open source software projects, due to practical concerns: people work on it at odd hours and cannot be expected to be on chat all at the same time.

You can get a lot of great work done this way. This blog post was written using software that was mostly created this way. The Linux kernel certainly was, at any rate: Linus Torvalds uploaded the source code and sent out some emails on a mailing list, and then other programmers were able to send patches in. As far as I know, the Linux kernel developers don't hop onto Slack to talk all day and to have video calls, so most of their communication is through asynchronous means like email.

This model will work for you when the people on your team work very well with high degrees of autonomy. Since it's asynchronous, they have to be able to do this, or they will run into periods of indecision and stall out.

This is the model which I haven't lived first-hand. My evenings aren't filled with open source contributions (I'd rather spend the time cooking or reading a good book or writing English). I haven't seen this at a lot of companies, although there are some companies where it's debatable if they fall in this category or the next one.

Personally, I find this one suboptimal; it's really nice to have a couple of hours each day where you overlap with the coworkers you're working closely with so you can bounce ideas off them directly, whether it's for debugging or for designing a new feature or for solving a gnarly architecture problem. But it can work and it emphasizes deep work, so there's a big benefit there.

The Basecamp model: fully remote, somewhat synchronous

This model is probably the prototypical commercial fully remote model. This is how I'd categorize companies like Basecamp, GitHub, and others. They're almost entirely remote but they tend to have at least a few hours of overlap of timezones between people who are working closely together to allow for those immensely valuable interactions where you put two people together but get more than two times better solutions as a result.

This model works well when people on your team can work with high degrees of autonomy but they don't have to be quite as autonomous as when it's fully asynchronous, since you have some overlap to bounce ideas off of people and get input from them and talk about where you're going next.

The pitfall in this model is that some activities are simply harder. To the best of my knowledge, there is no great way to whiteboard together with remote employees, and that's a great technique for designing software. It's also difficult to pair program, and mentoring junior engineers just has higher friction when remote.

That said, this is an incredibly fun and productive way to work. I did this on a contracting project, and it was really great for the freedom of it, since you could be offline at any time as long as you were getting your work done. The biggest drawback, on our project, was that it was difficult to get a rhythm going due to all of us having different schedules (despite all living in the same timezone, we actually had few overlapping work hours), which just emphasizes the importance of overlapping work hours and also how hard schedules are, even for a handful of people.

The hybrid model: half remote, half colocated, fully synchronous

For pragmatic reasons, more and more companies are adopting this pattern. The company I work for, Remesh, does this: we have engineers at our HQ in NYC, but we actually have a slim majority of our engineers spread out across the US. We got into this model because the team had two engineers and needed to staff up, so they brought me on as the first remote engineer; it went well, so we gradually hired more remote engineers.

In general, this model is charcaterized by a very strong geographic presence in one location but with a large number of remote engineers. Because these teams have a lot of colocated engineers, they tend to emphasize having a lot of overlap in their days, prioritize synchronous communication, and have high team cohesion.

This configuration has a lot of benefits. Having a lot of colocated engineers makes it easier to build team cohesion. But by having so many engineers remote, you are forced to adopt remote-work patterns. The whole taem benefits from better documentation and more location indepependence. Not to mention, you also reap one of the biggest benefits of remote work: the gigantic pool of talent out there, since most of the talented engineers don't live where you live.

The biggest difficulty here is keeping cohesion between your colocated and remote team members. The colocated engineers will tend to form tighter bonds because they see each other every day. There are some ways around that, like having frequent meetups for the remote team members, but it's a risk factor you just have to be aware of and have to work to mitigate.

If you go this route, make sure that you actively engage the remote engineers, and consider forcing all the engineers to spend some time remote to build empathy and stronger habits on the team as a whole. Think of it as chaos engineering for your team: if you randomly prevent people from working inside the office, you will force your team to document better, be remote friendly, and be more independent and autonomous.

The traditional model: colocated team with a few remote team members

This one is easy to identify from a distance: everyone is in one location except for a few loners who are remote. This usually happens in traditional work environments when something major changes: either an employee is going to move to another city and the company makes this work to keep them on; or they need to bring on talent for a specific skillset and they cannot find it locally.

I don't recommend this model. The benefits are minimal, and are just centered around a specific person that you want to be able to work with. But the drawbacks are huge. You will have a lot of difficulty integrating the remote person in, since your work patterns are all set up for colocated engineers. You will struggle to retain this remote employee for a long time, since you will in all likelihood alienate them or they will simply feel left out by being unable to participate in local team events. It can work with people who you have a really good rapport with or who are already very, very good at remote work, but it usually does not work well.

The only situation I'd recommend this for, as the employer or the employee, is for short-term contracts. For anything beyond that, if you want to embrace remote work, go all in and at least embrace the patterns that will make it work well, since those will benefit your colocated employees and you will broaden your talent pool.

Recommendations

Of these, the "traditional" model is to be avoided at nearly any cost since it is painful with few benefits, and the Linux model is ill-suited for most businesses since you sacrifice agility of decision making which is critical to launching good, fresh products.

So we're left with two realistic models: fully remote but mostly synchronous; or half remote and half colocated. If you execute either of these well, you reap tremendous benefits, so the difference comes down to how much you value colocation. I personally don't find it intensely valuable, so I'll always vote remote; others do find it valuable. One way to make this decision, to find out how much colocation is important for you, is to simply try to be fully remote. With your existing team, close the office for a month and see how you all get on; or if you're scaling up, require half the team to work from outside the office half the time, so you don't have to get that bigger office space just yet. It will be difficult at first, but it will tell you whether or not you truly need colocation and it will expose what you were getting from it - and what it was costing you. And then you will know which way you should go.

Personally, when I start a company, I'm going to go all-in on remote work from day one.