Many of you are probably fed up with discussions of remote vs. hybrid after the last couple of years. Nevertheless, this is one of tech’s most essential and culture-defining parts of organizational leadership. Since I’ve seen many teams globally go through transitions and learn what seems to be working better, I decided to share with you a short three-part series about the typical cases where I’d recommend to a client to choose one of these over the other, as well as list out tips and pitfalls. Let’s get to it with the ostensibly most obvious of the bunch, the colocated team. Today, it is no longer as apparent.

The Good Ol’ Office

For most in our industry, this is still the default and how we’ve learned to do what we do. It feels like a safe choice, and it still is, relatively. However, I am not sure this is the best choice for all situations. Here are (ideal) conditions for choosing to work in a colocated office, where teams that work together all sit in the same office five days a week.

You’re not planning on hyper-growth: Less common now than it was a year or two ago, but still a strategy for many growing companies. The problem with such scale-up organizations is that they require a constant stream of candidates and new hires, which will always be harder to find in a specific geographical location.

You’re in a talent hub: Is there enough of a talent pool around you to rely on locally hiring? This is even more important in case your company uses a tech stack that’s less popular.

You don’t need world-class people: This is related to the previous point. Don’t take this wrong; I’m not trying to belittle your team or plans. If your novelty relies on some deep technical knowledge and you need someone from the core team of known open source projects, a world-renowned expert, etc., then you are considerably less likely to find all those people and have them in the same office.

You have money: I might be pointing out the obvious, but colocation only works if you do not need to consider offshoring (or even near-shoring) to cut costs. Some teams consider themselves as colocated even when they have some offshore contractors. Personally, I think this is a fallacy.

R&D is close to the users: This one isn’t as solid of a condition, but I’ve seen it matter enough times to make it worth mentioning. Sometimes we start with an R&D team located somewhere on the globe while the product is aimed at customers in other geographies. That is often alright at the beginning, but with time becomes harder to maintain, and some R&D offices are opened closer to the business. For example, it is widespread for Israeli startups to have an R&D team in Tel Aviv but have most business people in the US. Many eventually add engineers in the US (or “in between,” like the UK).

Making This Work

This is relatively straightforward, but everyone who decides to have a colocated team should consider the implications. First, given the rising popularity of hybrid work, teams that are solely colocated will have a more challenging time regarding diversity. Many parents have realized they no longer want to commute to the office five times a week, for example. That can result in a team gravitating toward younger, less experienced personnel.

Second, I recommend tailoring your hiring strategy to use colocation as an advantage. This should be used to attract those for whom such a workplace is more appealing, as opposed to those who see this as a shortcoming but would come work for you despite it.

Lastly, even for colocated teams, there might be logic in accepting some remoteness. The problem is that most compromises immediately devolve into a hybrid culture. One solution you might consider is having “remote weeks” during frequent vacation times. After all, many like the idea of remote work for travel but won’t use that option more than once or twice a year during the holidays.

This is the “obvious” setup, and yet I’m assuming you just learned some new things. Subscribe below to get the next articles about remote-only and hybrid teams!