[chimeracoder]

> Take for example a few jobs ago when our servers went down because of a local internet outage.

That's not a great example, because that's a problem that's already caused by over-centralizing. If you used colocated servers or cloud hosting, that doesn't sound like a local Internet outage would have been a problem.

More broadly: at some point, every successful company will need to handle workflows of people who aren't in the same physical space. It's much easier to bake these habits in as a small company and grow with them than it is to retrofit them onto a company once it needs to open a second office in a different city or country.

[throwawaydbfif]

People are used to working with others far away constantly in daily life. I don't think it's much effort to say "yeah the guy that sits across from you, from now on youll have to call him" .

Especially if most of the employees in the new office are new, I don't think it's much or any real work needed to teach people to work with remote employees.

I'm just arguing that decentralizing has a fixed cost of more difficult communication, not something you can save up for or build into your company from the start.

[chimeracoder]

> I don't think it's much effort to say "yeah the guy that sits across from you, from now on youll have to call him" .

Let me start by saying that I'm not speaking hypothetically. I'm speaking from experience here, having worked for companies both remotely and not-remotely, and seeing where that's succeeded and failed.

It is actually difficult to make that adjustment, because working in the same space breeds a lot of bad communication habits which don't scale.

Working remotely from the start, you end up being forced to document work (even minimally), or to make decisions over a medium that is readily archive-able like email or Slack[0]. This is particularly true if you're working across timezones, even a small difference like east/west coast in the US (3 hours). Reading through an email thread to reconstruct history isn't the ideal form of company documentation, no, but it sure beats not having it at all because all of the discussions happened in real-life and nobody felt the need to send out an email afterwards to formalize it.

If you develop a collective habit of never making important (or irreversible) decisions without some sort of asynchronous and archiveable communication, and always having canonical internal documentation and runbooks for internal systems (because some of the the people who may need to operate them are working different hours), you don't run into the situation where your company has suddenly hit 300 people and needs to open an office in Europe, but can't break the bad habits of relying on information held in people's heads and exchanged in ephemeral, synchronous form.

[0] Lest anyone misinterpret what I'm saying: Slack is emphatically not a replacement for proper documentation. It can, however, be a helpful forcing function to bootstrap proper documentation, and it serves that role far better than meatspace interactions or even video conferencing ever do.