> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration.

This is not an implication by all means.

Low-skilled not very well incentivized junior team (let's call it so in absence of better terms) needs more/most "in-person collaboration". Team of experts to whom the goals and the overall vision have been conveyed, who knows how to put it to practice, will give the shortest latency in async flows.

Don't take it as a personal attack, but people valuing high live discussions, are frequently those on the receiving end of it.

That's one thing that can happen, but it's not the only thing.

What you're describing is a push model. Somebody on high creates a vision and assigns goals. Workers are just seen turning that into outputs. It's a common way to work, especially in "known problem/known solution" projects, but it has its flaws. See Cutler on "feature factories", for example. Or Blank's "Four Steps to the Epiphany".

But what if the solution or perhaps the problem is unknown? Push systems don't work. Instead, I favor cross-functional teams that pursue outcomes (as opposed to outputs). In that context, the vision is a living thing, created collaboratively, as is the plan. Problems are explored, and solutions discovered. The speed at which a team can learn and test solutions is limited by communications latency.

And of course experts aren't born that way. Even if you're in a "known problem/known solution" space, sustainable companies need to find ways to turn novices into experts. Again, that's about learning, which does not work well in high-latency environments.

If that were true, why does every director/principal/VP/ceo spend almost the entire week in meetings?

The cynical take is that this is a rhetorical question.

> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration.

First, it's high latency, not extremely high latency. Second, it has huge advantages: 1.) While latency (in terms of how quickly you finish task) will increase, your bandwidth will increase too. Everyone get more done. 2.) With asynchronous communication, you are not interrupted by communication, you can do it in bulk.

In case there is something urgent, you always can do a call, or synchronous chat.

> 1.) While latency (in terms of how quickly you finish task) will increase, your bandwidth will increase too

It has to increase to make up for the round trips you can't afford: you try to communicate more information in one batch. Whether this is good or bad really depends. On one hand, I think it just forces communication to be better, on the other hand you might waste time communicating things that you'd immediately find to be unnecessary if you were interacting live with the other party.

It sounds like you're focused on maximizing output. I'm more interested in maximizing outcome.

As to high vs extremely high, I'm not sure arguing over relative terms is useful. But just so it's clear what I mean:

If I'm working in a team room with colleagues, my average latency between request and response is, say 15 seconds. But in globally distributed remote work situations, a much longer lag is not uncommon. E.g., when I was working with European colleagues, it was typical to get a response the next working day. That's about 5000 times longer, which seems pretty extreme to me.

> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion.

But even when you work in the same building you still have to find a time slot that fits for a meeting. Of course, you can also drop by the other's office and hope to find them ready for a chat, but there's no guarantee.

And for remote companies I imagine that people actually have more time slots open for (video)chats, because people don't have to allocate extra time to travel between meeting rooms.

Of course, the dynamics of a live discussion are somewhat different from a digital discussion. But I think the availability/latency issue is a misconception.

> But even when you work in the same building you still have to find a time slot that fits for a meeting.

That is definitely not the only way to work. A cross-functional team sitting together and focused on outcomes can be much more organic than that. Think of the writer's room for a show, for example. That can sound weird, but Devin's "Artful Making" does a good job explaining the parallels between knowledge work and how theater/TV/movie people work.

> I know that some remote-first companies tend to group related work by timezone, so that teams can be both distributed and low latency. I take it Gitlab isn't one of those?

Probably depends on the team, individuals being able to self-organize and their experience. While some companies may see timezone distributed teams as disadvantage, I believe it is an opportunity to have a continuity of work and getting things done faster than if you had a single 6-8h time slot.

Having experienced a manager with a "sun-never-sets-on-my-empire" fixation, I'm skeptical. In theory, you can get 3 shifts in where there was one before. But this isn't a factory. For knowledge work, there's a big problem with handoffs.

If somebody is going to pick up coding right where I left off, I need to transfer a lot of state from my head to theirs. At best, this takes a lot of time. But what's more likely is that things get In software our true enemy isn't time, it's error. It takes seconds to create a bug, but often takes hours or days to remove it. It takes minutes to misunderstand the purpose of a feature, but days or weeks to rework the code to match actual need.

I think if we want to get more people at the coalface, the right solution isn't working in shifts. (If it were, we would already be working in shifts without regard to timezone, just like factories do.) Instead, it's to increase collaboration, which requires much more synchronous communication. E.g., techniques like collective code ownership, pair programming, frequent pair rotation, cross-functional teams, small units of work, continuous delivery, and very frequent releases (daily or more often).

Since very few people work like that, I think it's reasonable to assume that faster results are not in fact a priority for most businesses. So the "distributed timezones are an advantage" to me sounds like an after-the-fact justification, not an actual solution to a problem.

With async communication it’s hard to know if everyone got it. If you’re in some kind of synchronous meeting, everyone knows what everyone knows, and it’s usually more clear if people are confused or come from very different POVs, or don’t have the time, attention or other resources they need to get things done. Async communication often feels like shouting into a void, hoping that the right people saw it in time and prioritized it appropriately.

> If you’re in some kind of synchronous meeting, everyone knows what everyone knows,

I feel like while that's generally true, it depends. Not only because you might underestimate my ability to sleep with my eyes open. I've seen quite a few projects where in-person meetings were either badly planned, went overboard in terms of frequency / number of participants, or people were simply inattentive for other reasons. There's lots of scenarios where communication devolves to the point of asynchronous communication despite meeting face to face. Quite a few meeting forms type up notes or minutes for a reason. Many meetings in my experience are just superfluous "I felt like talking" scenarios, which is fine but it certainly does not make for a great communication strategy.

I'd say it depends on who would meet, for many groups other forms of communication like e-mail/IRC/slack work just fine for a majority of issues without introducing much friction. But sure, for others it might break down completely.

Amen. I've had meetings where 15 people showed up, and everyone walked out with 15 different recollections as to what was done. At least one of those 15 isn't going to read the meeting notes that get emailed out after the fact, so we're going to have to rehash the same shit in a week or two.

You don't have to "hope". You can just ask them to read and reply appropriately (even if it's just with an "ok" or equivalent). Initially you might have to prod them explicitly, but people adjust rapidly and start acknowledging on their own.