I've seen remote-first engineering become the norm in 2020 and now the patterns for leading distributed teams are clearer. The teams that thrived made intentional choices about communication, documentation, and inclusion.
Distributed teams that rely on synchronous communication for every decision and update create problems. They interrupt each other's work and create timezone-inequitable working conditions. I've found that defaulting to async communication helps.
Async communication means using written documentation, Loom videos for walkthroughs, and GitHub discussions for design decisions. Synchronous time is then used for relationship building, complex discussions, and problems that require real-time interaction. For example, at one company I worked with, we used Confluence for documentation and Notion for meeting notes, which helped reduce the number of synchronous meetings by 30%.
In a co-located team, institutional knowledge is shared through conversations and informal hallway context. But in a distributed team, that knowledge disappears as team members come and go. That's why I think writing is crucial. In fact, a study by McKinsey found that companies that documented their processes saw a 20-30% increase in productivity.
Decisions should be written in ADRs, processes should be documented in the team wiki, and onboarding documentation should be maintained as a working document tested by every new hire. This requires investment, but it's worth it. I've seen teams spend up to 10 hours a week on documentation, but this pays off in the long run when new hires can get up to speed 50% faster.
When implementing async communication, it's also important to consider the trade-offs. For instance, while async communication reduces interruptions, it can also lead to slower decision-making. To mitigate this, teams can use tools like Slack or Microsoft Teams to set up async discussion channels with clear expectations for response times, such as responding to messages within 2 hours.
When a distributed team has a majority in one timezone, the minority participants are disadvantaged. To mitigate this, meeting times should be rotated to share the timezone burden, and important meetings should be recorded. I've seen teams use tools like Zoom or Google Meet to record meetings, and then use Otter or Trint to transcribe the recordings, making it easier for team members to catch up on missed meetings.
Written summaries of decisions should be shared broadly, and input should be sought from timezone-minority engineers on asynchronous channels before synchronous meetings. This helps ensure everyone's voice is heard. In one team I worked with, we used a tool called Docusaurus to create a knowledge base that was accessible to all team members, regardless of their location or timezone.
Weekly 1:1s between manager and direct report are not optional in a distributed team. They're the primary channel for understanding how each engineer is doing, what blockers they face, and where their career is heading. These meetings should be scheduled at the same time every week, and the manager should come prepared with specific questions, such as what are the engineer's goals for the next quarter, or what support they need to overcome current challenges.
In a 1:1, the manager's job is to listen 70% of the time. The agenda should be owned by the engineer, and the manager should use this time to understand their team members' needs and concerns. I've found that using a simple framework like the START method - Situation, Task, Action, Result, and Timeline - can help structure these conversations and ensure that both the manager and engineer are on the same page.