I've seen a stark divide in engineering teams after three months of remote work. Some adjusted remarkably well, while others struggled hard. What made the difference was fascinating and practical to witness.
The teams that adapted best to remote work had solid documentation cultures in place before the transition. Architecture decision records, runbooks, onboarding guides, and API documentation that existed before March 2020 lessened the burden of knowledge transfer in a distributed environment. Teams that relied on implicit knowledge transfer through proximity were hit hard by the documentation debt. My takeaway: documentation isn't something you tackle in a specific phase; it's a continuous effort.
For instance, I recall working with a team that used Confluence for documentation and Notion for knowledge management. They had around 500 pages of documentation, which seemed overwhelming at first, but it paid off when they had to transition to remote work. The team was able to reduce the time spent on knowledge transfer by 30% and onboard new members 25% faster. This experience taught me that investing in documentation tools and processes is crucial for remote work success.
Effective remote engineering organisations reduced their meeting load, not increased it. The anti-pattern I've seen is swapping office collaboration for back-to-back Zoom meetings that leave no time for actual engineering work. The effective approach is to shift status updates to written async formats (like standups in Slack or weekly written updates), reserve synchronous time for decisions that genuinely require real-time discussion, and protect dedicated deep work blocks in calendars. I've seen teams that adopted this approach reduce their meeting time by 40% and increase their engineering productivity by 20%.
Another key aspect of effective remote work is establishing clear communication channels. This includes using tools like Slack for async communication, Zoom for video meetings, and Trello for project management. It's also important to define clear expectations around response times, communication protocols, and escalation procedures. For example, a team I worked with established a rule that all async messages should be responded to within 2 hours, and that all urgent issues should be escalated to a designated channel. This helped reduce misunderstandings and ensured that issues were addressed promptly.
Written-async communication serves status, decisions, and documentation well. However, video-first is better suited for complex technical discussions where whiteboarding, real-time reaction, and collaborative problem-solving are essential. Architecture reviews, complex debugging sessions, and 1:1s for sensitive conversations benefit from synchronous video, even in an async-first culture.
Video-first communication also requires careful planning to ensure that all participants are on the same page. This includes sharing agendas, meeting notes, and action items beforehand, and using tools like Mural or Google Jamboard for collaborative whiteboarding. I've seen teams that adopted this approach reduce their meeting time by 30% and increase their decision-making speed by 25%.
The team rituals that translated well to remote work include weekly team retrospectives (structured, with asynchronous pre-work), team 1:1s on a consistent schedule, virtual coffee chats for informal connection, and asynchronous recognition (shoutouts in team channels). On the other hand, the rituals that didn't make the cut were unstructured office hangouts, impromptu whiteboard sessions, and hallway conversations that surface blockers early. To replace the latter, proactive manager check-ins and low-friction async blockers channels are a must.