It's certainly tricky. I personally found pairing to be pretty helpful when I joined a new company during covid.
There's an app called Tuple which made pairing online pretty easy (if only it didn't ask permission to install updates every day)
100% remote here. It's not the same as spontaneous "over the shoulder" learning, but scheduled Lunch & Learn sessions can be a great way to let team members share what they know. Building a good lunch & learn presentation is also a very useful exercise and generally helps the presenter refine their skills as well. Pair programming or debugging, especially where there's an opportunity to share new tools/techniques can be good in one on one meetings, but are also worth documenting and bringing to a regular standup or equivalent.
We’re distributed, about 15 people now. 1/3 devs, 1/3 sales & 1/3 ops.
We get by with frequent and non-fussy use of screen sharing in slack or zoom calls.
If someone is leading on a project / bug / sale we expect some quick and dirty Looms or just Mac/iOS screen recordings into a shared drive for a simple knowledge base.
I record a LOT of our calls and will do at least brief readme write ups that often end up in our git repos with links to the resource.
I think the big cultural step is just being open to ask for advice on tooling and quick to share little finds.
I've made tutorial videos in the past at organisations. How to install stuff, good things work. Nothing to long but it lets people watch any rewatch
Hey there - you might want to fix the title ("remote-first")
I've never worked in a remote first environment but interviews with such companies has revealed to me that they generally try to cultivate a culture around screensharing (often coupled with pair programming) to facilitate this kind of learning.
A culture which prioritizes writing things down will allow for this type of pattern.
For example, engineers who solve problems should tell stories in their commit messages, providing context, they should output ideas in Slack, and when they have questions, they should provide context and link to references they have explored (tickets, external resources)
It sounds like a lot of work, but in my opinion it's not. That deliberate slow down by one person allows others to grow at a more healthy pace, ultimately progressing the entire team/org (sizing dependent etc.)
I'm not saying Slack should be a knowledge share but it does become a great portal to more information, and ultimately the git log is one of the more important areas in a business to provide learning opportunities for other engineers.
That type of culture will naturally be better at writing documentation and taking care of it because they are practising well formed communication on a regular.