I have noticed that a lot of startups are fully remote and hire globally, so I'm just wondering what the solution to this communication problem is.
Sometimes that's not avoidable, but if both parties recognize the situation and change styles, it can help in most situations. Provide all the relevant information in the first message; read the whole message before and while responding. Expect to not get instant feedback.
It's like writing a letter vs having a phone call.
Otherwise, have realtime sync up at the edges of the workday.
This is the way. If you adopt the same communication style as the old scientists (euler?), you’d get a lot done. You write clear, detailed requests, responses, and notices and the delays with the back and forth won't matter that much. Maybe that's why most of the scientists we know of have been people with good communication skills.
Then schedule meeting with a clear agenda when synchronous collaboration is needed.
In general, open ended exploration can be hard by letter as well.
Synchronous: A single time zone is designated, and all team members adapt accordingly. Although, this can be a pain for people far away.
Asynchronous: Flexible “overlap” periods are defined where everyone must be online.
In practice, though, remote teams I've worked in just seem to understand and accept that: A) You don't need a 'call', 'quick chat' or 'meeting' over video or voice most of the time B) If you are in a remote team, there is shared acceptance that there will be A LOT of asynchronous communication and people will reply when they can or are available. C) The situation changes the more time-zones you cover. Be flexible.
Those with roles that are 'mission-critical' or 'perpetually online', are usually on call or have a phone that is always available.
A handy resource for aligning schedules: https://www.timeanddate.com/worldclock/converter.html
1) Things like code reviews should be more extensive if feedback loops are long. One should be clear whether something is blocking or not. A lot of people use (and came up with) https://conventionalcomments.org/. Personally I really like to assign someone in the States or APAC and come back the next day haben my code reviewed.
2) regular meetings are often being alternated to be friendly between different time zones. e.g. one week APAC/EMEA friendly and another EMEA/AMER. All meetings have agendas and everyone can add points, even if they cannot attend. Also all meetings should be optional.
I noticed that it emphasizes the importance of documenting work to prevent bottlenecks in asynchronous communication. It also discusses choosing the most effective form of media for conveying messages.
What does this look like in practice? How easy is it to find relevant information in the archives or documentation? Are there times when you cannot locate such information and must wait for the appropriate person to be online to get an answer? If so, what types of communications typically cause these delays?
There are basically _four_ systems where we store information: Recordings of Meetings, good if you want to re-watch a meeting you missed. Google Documents which I would consider more ephemeral, (but then our Frontend Meeting goes back hundreds of pages as a Google Doc). Slack is used, we have hundreds of channels. Actually information is not retained forever in Slack, which I like because it forces people to document things elsewhere.
The biggest benefit: git + issues / merge requests. Most of our handbook and company policies are markdown files in git. So even with renames and reformatting you can track the MR that changed it and 99% of the time find the reason _why_ someone changed it. Either the assumptions are still valid or you can propose another change if they aren't. If it is really dubious as to why something is the way it is, there will be someone responsible for that thing and you reach out.
> How easy is it to find relevant information in the archives or documentation?
Very. (Most) of the handbook is public, so any search engine is your friend. Google Docs search is alright. Otherwise checking things out locally is easy too and the history / relevant things are right there. Furthermore we have dozens/hundreds of Slack channels, where you ask your question and usually you get a relevant answer which you can document in a better and relevant place.
> Are there times when you cannot locate such information and must wait for the appropriate person to be online to get an answer? If so, what types of communications typically cause these delays?
As an employee it happens from time to time, think Finance, or Legal, or Compliance or Human Resource issues.
As an Engineer, you get used to it. You never work on "one thing" any given day, but you kind of adopt a strategy where moving slow means moving fast. It sounds like a contradiction, but if a lot of people have kind of equally important streams of work going on at the same time, each person can move forward and we always have enough relevant things being finished every day/month/year for our users and customers.
So personally I look at my highest priority for the next week / day, try to identify whether I need input from others early (no better: earlier) and make sure I get this feedback and resolve blockers. If I run into new blockers, I solicit new feedback as early as possible, e.g. by pushing a broken/unfinished MR and pinging the relevant people on it, asking their opinion. Once the code is ready, fan out and get all the approvals needed. I think a small bug-fix is mergeable within a day, medium sized addition 3 to 5 work days and big feature better be chunked into Feature Flag + a few of those medium sized additions.
I forgot to mention GitHub, used for issues, PR reviews, and documentation.
We encourage developers to work through problems rather than stop and wait for answers. Stub in some code and keep going if they need clarity on requirements. Expect most code to get revised iteratively. That keeps everyone moving.