Exactly this. Assume nobody knows anything and explain everything 500 times.

Also quick 5 minute call on Slack can save 4 hours to 4 days of sending emails. So prioritize fast issue solving rather than "process".

Imho key things are:

* Communication.
* Biz + Technical PoV from devs.
* Ownership / ability to make decisions.

Full remote is not for control freaks. It is for people who wants to get shit done. If you can't trust anyone you can't do remote.

1. Communication is key

Ability to talk and exchange info in processable way is king. This means no 5000 esseys. But not 1 line 4 word summaries. Communication should assume 0 knowledge on the reader but start with easily digestable summary / TLDR so person reading it can skip explanations he already knows.

Your english doesn't have to be perfect, but when you speak you can't sound like a broken acordeon. If your english is on level of ability to laugh from a pun you are good. Always learn and never assume your english is perfect.

2. Biz + Technical PoV from devs

Developers should know entire domain, how the app works in a biz sense. What is important. IF you are selling voice services and birthday card generator services from which cards generate 3% of income. Dev should be aware where the focus must be. This might be simple example, but this knowledge lets developer asses damage in dire situation and help prioritize things.

I know it might be shocking but sometimes developers can generate a good biz idea that will propel more profits.

Technical pov from devs. This is trivial and i assume every dev has technical pov but it might not be 100% true always. Simply to put it. This means understanding code in platform and setup / deployment. Sometimes developer can spot some easy optimization in other areas that just code. For example in the deployment sense.

3. Ownership

Teams / Developers have to have decent level of ownership. Possibly 100%. The decision-feedback-loop should be fast and simple. It doesn't mean devs call all shots but if they need to do something or get info it shouldn't take 3 weeks to get response.

All questions not answered are waste, all meetings about follow up to this questions are waste, all emails without answer or with bad answer are waste.

Imagine this situation:

Your team has 3 devs in 3 different countries. Lets call them D1,D2 and Dave. There is a product owner in 4 time zones behind him. Dave asks a question "how do we want handle service deletion?" he has to wait 4 hours to get the response, if product owner don't have to ask higher up. If PO has to ask up the response might be after 2 days. The response might be "in a good way" which prompts another set of questions. etc...

ofc Dave can ask the question like this:

"How do we want to handle service deletion ? Option A: just remove everything. Option B: marked it as deleted and keep in archive"

This might prompt Product owner response

"Adding in Steve from finance and Karolina from GDPR department. What do you guys think ?"
^- this solo can freaking prompt a week of delay because Karolina will respond "we must delete it" and Steve "i'm on holidays until March" etc....

Short feedback loops are ideal even if solution isn't ideal. It will be ideal most of the time. but the key is that a lot of this comms was just useless waste of time. And when PO involves multiple people and they start to disagree it is full scale setting up money on fire.

ofc Karolina is correct about GDPR handling but Steve might say "no no, we never delete" xD classic Steve.