Working in a remote company makes it more difficult to have the regular “tap the person on the shoulder” interaction that sometimes leads to knowledge transfer. You also don’t have the (sometimes noisy) osmosis process that can take place when you are physically co-located. Instead of relying on water coolers and FACs, in a remote company you need to be explicit about your knowledge sharing. Here at Culture Foundry, we’ve found the following to be helpful.

• documentation. We have a playbook where we write up standard operating procedures. Every project has a google drive folder that has documentation about it. Almost every github repo has a readme. We’re not perfect, it’s not always up to date, but it’s an effective way to transfer knowledge.
• dev only slack channel. This is a place for developers to hang out and ask any questions they have. We prefer slack over email for adhoc conversations.
• lots of zoom channels. we have a number of zoom channels so that if at any point in a slack or email conversation it makes sense to have a higher bandwidth discussion, we can say “hop on zoom” and in 2 minutes be looking at each other, talking and sharing a screen. From a browser, with a one time install.
• a culture of helpfulness. This is probably the most important point. (Talk about burying the lede.) We are extremely open about what we know and don’t know and have a culture of solution, not blame. Yes, there are times when a developer needs help and other folks can’t, but they are few and far between. Most times if a dev needs help, folks chime in and try to help. Of course the help offered depends on the problem. Sometimes it is something that others have seen before. Other times it is something new and all others can offer is a way to rubber duck.
• regular syncs. we have regular, weekly, biweekly or monthly syncs across the development team, both between members of the team and with other parts of the company. These are typically 30 minutes where the parties can discuss anything on their minds. We use video conferencing for these.
• training budget. Culture Foundry gives each developer budget for one conference a year. Books and online courses are in the budget as well.
• training time. We have a line item in our time tracking system for personal training and this can be used at the developer’s discretion.
• developer club. This is an weekly hour long meeting where all the devs join in. Discussion topics are entirely emergent and directed by the team. Past topics include tailwinds css, how a rails migration works and troubleshooting craftcms. This is a key meeting for building collegiality between developers.

Remote work is far more flexible, but that very flexibility requires designing processes and customs to promote sharing knowledge. Keeping up to date on evolution of technologies is an important part of being an effective developer. Sharing knowledge across a team when remote doesn’t happen by chance, but can happen effectively and efficiently with tooling and commitment.