Two years of predominantly remote engineering work has produced a clearer picture of what distributed teams do well, what they do poorly, and what practices change the outcome.
Asynchronous communication as a skill
Remote-first teams where communication is primarily asynchronous require a different skill set than co-located teams. Writing a clear specification for a design review, a precise bug report, or a comprehensive architecture decision record is more important when the reader cannot ask a clarifying question synchronously. Teams that invest in writing quality produce better decisions and knowledge retention than teams that treat async communication as a weaker substitute for meeting.
Documentation as infrastructure
In co-located teams, undocumented knowledge lives in people's heads and can be retrieved by asking. In distributed teams, undocumented knowledge is inaccessible. The teams that function best in distributed environments treat documentation as infrastructure: runbooks for operational tasks, architecture decision records for design choices, and onboarding documentation that enables a new hire to contribute without having to extract knowledge from individuals.
Synchronous time as a resource
When synchronous meetings require scheduling across time zones, their cost is higher than in co-located teams. The highest-value use of synchronous time: complex technical design discussions where real-time give-and-take produces better decisions faster than async debate, production incidents where real-time coordination is necessary, and relationship-building that is difficult to replicate in text. Everything else can often be handled asynchronously.
Engineering culture at a distance
The cultural elements that sustain a high-performing engineering team, psychological safety, clear standards, shared understanding of quality, can all be maintained in distributed teams, but require explicit attention. Team norms that are absorbed implicitly in a co-located environment need to be written down and demonstrated visibly in distributed environments. Leadership at a distance requires more communication of context, not less.