As a long time remote worker, I've found that what seems like a hair-splitty difference can actually be a deep insight into the company's culture, and how it will affect your work experience.
Distributed teams develop a culture of communication that does not rely on frequent face-to-face contact. I personally suspect that they tend to be even more productive than completely co-located teams, because, based on a sample size of one, I've seen that the communication methods they develop will require fewer person-hours to share more information at higher fidelity.
"Remote" tends to imply a large chunk of the team is co-located, and one or more of the members are not. My experience here is that the remote people tend to not get the memo, or people fail to invite them to meetings because they don't want to bother with the conference room's videoconferencing equipment, or they do invite the remote folks but then the first 15 minutes of the meeting is devoted to figuring out how to work the Polycom system, etc.
I had the pleasure of working on a distributed team that became a team with remote workers as a result of being acquired by a company that decided to only hire new people to work in their home office. It was impressive how quickly things fell apart after that.
(Edit: This isn't to say that P's team isn't working well with a flexible approach, but it sounds like there's a big difference between it and many other non-distributed teams that have remote work: Everyone is in it together.)
I've seen it even within teams in the same corporation: some are used to working distributed, for whatever reasons (e.g. working on truly open-source projects/ with external collaborators); others highlight the "efficiency" of co-location, and try to get everybody working on the same project in the same office.
In my experience, the former is far more effective, for a very simple reason: informal communication channels quickly break down. In the latter approach - you have decisions discussed between some people, with others not informed, not documented properly, forgotten after a while, shifting agreements etc. Because the team can be more "agile" it's less structured, and while on the short term it may seem to be a good thing, on the long term it really hurts it (working on the wrong things/ on things that are not needed anymore, constant overhead for on-boarding new people, loss of team knowledge with every "old" team member that leaves, etc).
I'd say the distinction between "remote" and "distributed" workers is on how serious the team is about enabling remote work. If it treats remote workers as a secondary, "extension team" - things don't work well. If that's the primary mode of operation - things actually end up working _better_ than in co-located teams, in most situations(read: as soon as the team/product grows big enough).
There’s not enough pressure to prevent tribal knowledge from becoming the pattern. If you have to write everything down at least once, you’re part way to solving the problem.
> "Remote" tends to imply a large chunk of the team is co-located, and one or more of the members are not. My experience here is that the remote people tend to not get the memo, or people fail to invite them to meetings because they don't want to bother with the conference room's videoconferencing equipment, or they do invite the remote folks but then the first 15 minutes of the meeting is devoted to figuring out how to work the Polycom system, etc.
Add in the "sneakernet" of communication: Heading over to another's office or cube, and the event/conversation/information never gets captured in a form that can nor is communicated further.
"Oh, we talked about that... when was that, three weeks ago?"
I don't view this, per the example, as a positive pattern. Such things become anti-patterns.
They're also another reason that meetings become long, confused, and drag on. The first one third, one half, maybe even two thirds can be spent syncing the team up with all these conversations and their data, that have taken place out-of-band.
I guess agile, scrum, and the like are supposed to reduce this. But when people go to training to become certified "scrum masters"... Bureaucracy is winning, once again.
(I remember one big, corporate "agile" name coming to speak at our campus, back when it was new. I think it was "agile"; the waves up corporate uptake start to blur, after a while. People actually showed up for it. And were rather disappointed: Same shit, new name.)
>Add in the "sneakernet" of communication: Heading over to another's office or cube, and the event/conversation/information never gets captured in a form that can nor is communicated further.
This is a strategy and culture fail, in my opinion. Our team has a rule that sneakernetting is allowed but anything substantive that comes from it must be communicated immediately on our collaboration platforms (Slack/Box/etc). No "meetings after meetings" when people aren't connected and over-communicate whenever possible/necessary. If you discuss something and there is information that's needed that you're not communicating to people effectively, that's on you, not on the people working remotely.
If you need to meet face to face, it's because you have to "arm twist" people to get things done. And/or it's because you have a knowledge/learning/teaching impedance -- a disparity between these abilities in roles and co-workers -- that is too large. Speaking of "knowledge work".
In the physical world, an example can be worth a thousand words. But when you have to keep showing someone the same thing over and over...
In knowledge work, I find frequent, repetitive meetings to be a version of that "over and over".
While I think your points are valid, in my experience many people are more comfortable communicating face-to-face. They've had decades of practice at it.
They will talk about "body language" and fail to recognize how often such cues are interpreted wrong. They fail to see their discomfort as a flag of a problem and instead see IT as the problem. They (and many if us that prefer text communication) fail to realize that communication is a skill like any other that requires deliberate practice to improve in any great degree.
An example: dont ask a question with two alternate examples, you'll get a "yes" or "no" that isnt helpful and require at least one more cycle for them to clarify (usually more than one, because THEY know what they meant, so unless you explain your confusion well, it is 1+ cycles to explain your confusion and then another to get the answer. )
DON'T: "is the shutdown this weekend or next? "
DO: "the shutdown is this weekend, correct?" Or "the shutdown is this weekend and not next, correct?"
You wouldn't expect a "yes" answer to the "or" question, but it happens all the time. Conversations are "time-delayed" - our minds are constantly back filling guesses at the meaning, and often we respond when we have the wrong guess.
Changing this is HARD. I seriously think modern conversational practices have a lot of redundancy in them for error correction, but this also makes people find any impediment to communication (such as the quality of a call or having to wait for someone to pause so you can actually be heard) more annoying.
Good distributed/remote development certainly doesn't happen without effort. I work remotely (9 hour time difference from the main team!). I was one of the first people on our team to go full time remote and it was difficult at first. These days I have practically no problems, but it took us a year or two to get the bugs worked out.
I think the main key is that you need to have management on board. It is trivially easy to cut a remote developer out of the loop. Any kind of petty office politics around remote work can sour the deal pretty quickly. Our biggest improvements came when management decided to transition from "Core development at the office with remote workers" to "We're remote first with some limited ability to work from the office if you want". That change in mindset made it much easier for people to make appropriate decisions.
Since the company I work for is growing rapidly, I don't think we can even go back to the way it was -- we don't have enough desks. Management is loving the cost savings and even those that were opposed originally seem to be big fans now. We've even started having some of our call centre work remotely from time to time (which, if you know the culture of a typical call centre is astounding).
Despite enjoying working remotely (and being grateful that I can), I've always preferred office work. However, with very few exceptions remote work is just superior. Communication is explicit (if it's not written down in an accessible place, it didn't happen). Work is inclusive. Generally things are more focused. However, it's really important to work hard on the social aspect of the job (because people can get isolated quickly).
A couple years ago, not long after moving into their South Lake Union headquarters, they overfilled the offices to the point that they had too many people and not enough bathrooms. I heard stories of people being forced to work from home so they didn't violate the building code.
I very much agree that you want to work at a company that embraced remote working instead of one that reluctantly agreed to it.
This is much easier in a company that is 100% remote. The OP suggests using the word distributed company. I noted that many companies with multiple locations. So we used the term 'remote only'. We didn't like the sound of that so we changed it to 'all remote' https://about.gitlab.com/company/culture/all-remote/
Distributed teams develop a culture of communication that does not rely on frequent face-to-face contact. I personally suspect that they tend to be even more productive than completely co-located teams, because, based on a sample size of one, I've seen that the communication methods they develop will require fewer person-hours to share more information at higher fidelity.
"Remote" tends to imply a large chunk of the team is co-located, and one or more of the members are not. My experience here is that the remote people tend to not get the memo, or people fail to invite them to meetings because they don't want to bother with the conference room's videoconferencing equipment, or they do invite the remote folks but then the first 15 minutes of the meeting is devoted to figuring out how to work the Polycom system, etc.
I had the pleasure of working on a distributed team that became a team with remote workers as a result of being acquired by a company that decided to only hire new people to work in their home office. It was impressive how quickly things fell apart after that.
(Edit: This isn't to say that P's team isn't working well with a flexible approach, but it sounds like there's a big difference between it and many other non-distributed teams that have remote work: Everyone is in it together.)