March 1, 2022
With Form3’s Engineering Teams being 100% remote, synchronous communication usually takes the form of video calls. We spend a lot of time on calls with our fellow engineers. Fortunately, most of that time is spent collaborating, focused on solving problems with the help of techniques like pair programming. Asynchronous communication typically takes place over Slack, our main messaging tool, and GitHub in the form of discussions on issues that define problem statements and requirements.
At Form3 we work across time zones ranging from Eastern Europe to the Americas so the time we have for synchronous communication is naturally limited. Throw in our flexible working and emphasis on not working unsociable hours (rightly so!) and things get even more difficult. I'd like to share a little about how we work together at Form3, and some of the various adaptations that I’ve seen within my current team.
With the recent addition of Canada based engineers to our predominately Europe based teams, some team members only have only two hours overlap in their standard working day. It’s important to us all that this time can be used to collaborate as effectively as possible without one party having to compromising their work life balance.
Asynchronous communications are generally more inclusive. They allow everyone involved to consume and engage on topics on their own time. This gives team members more autonomy over their own work schedule, which in turn better supports work life balance and those who need flexible working hours.
A key factor in the success of asynchronous communication is a culture that fosters the importance of writing things down and a culture of strong ownership. As a team, we put a lot of focus on writing clear problem statements, documenting our research, findings and decisions in a way that can be easily consumed by our colleagues. There are many great examples of this but one practice that has become a de facto Engineering wide standard is the usage of Architecture Decision Records [https://adr.github.io/] (ADRs).
The result of this focus is that Engineers can use their naturally occurring downtime to asynchronously engage in discussions and our natural curiosity means that we’re all up to date with work we’re not actively involved in.
Transitioning from synchronous to asynchronous communications at the right time can result in much more valuable contributions. In the Tooling Team, we’ve found that identifying a clear boundary between the problem and the solution is key to our team.
During team discussions we try to focus on identifying the problem. Once we’ve found consensus on underlying issue, we ask someone to write it down. Anyone is then free to work on a proposal on their own schedule. Naturally the more concrete a solution, and the more consensus we have, the more likely it’ll get picked up. This allows Engineers to have the agency to progress problems they are passionate about.
As raw ideas are hard to communicate and hard to digest, by taking a step back and separating the problem from the solution, we end up with much more valuable contributions.
It’s always hard to know who has valuable input on a given topic. With synchronous communications you must decide up front who contributes and who doesn’t. Invitees generally feel obliged to join meetings when they’ve been invited, regardless as to whether they want to contribute. The result is ultimately lower quality collaboration.
In contrast, async communications can be shared far and wide. This can engage a larger audience than would be possible with a video call. The Tooling Team’s role is to tackle cross cutting concerns that impact engineering productivity, so we often want feedback from other Engineers. To support that, we’ve developed special interest groups that centre around instant messaging channels, for example, #sig-deployments and #sig-observability. These are our go-to places to share key announcements and proposals, allowing us to cast a wide net for feedback.
We’ve spoken about some of the challenges that synchronous communications pose, but that’s not to say we throw synchronous communications out of the window – far from it in fact. We meet once a week as a team to share an overview of each workstream, meet daily for an optional team coffee and a demo on a variety of topics. We also have a timeboxed slot for miscellaneous team discussions and retrospectives that allows us to improve our team processes. As a result, the overwhelming majority of an Engineer’s time is self-managed, usually spent closely with their peers progressing towards a common objective.
Every day each team members post a daily update on an instant messaging thread, with a short description, and links to further reading. Eventually, this completely replaced our traditional daily stand-up format. It allowed us to focus on more important discussions as a team and over time we’ve managed to make these meetings feel valuable to us. We haven’t stopped there and we’re still experimenting with ways to get more out of less time. For example, we’re now trying to streamline our retrospectives by sharing discussion points and voting on topics prior to our call.
By replacing large team meetings with async communications supported by small, focused meetings, we’ve found more time for the aspects of the job that we find fulfilling. What generally pulls people to Form3 is the prospect of collaborating on complex technical challenges with talented peers. It’s important for both morale and productivity that we get that.
All of this means that on most days, even engineers at our most distant time zones have a solid pairing session before one engineer ends their workday. With our focus on asynchronous communications, it means that they can seamlessly pick up again the next day where their pair left off. Or at least that’s what we’re constantly striving towards!
This article is written from the perspective of Jan Akerman, an Engineer on our Tooling Team. Due to the autonomy of team’s at Form3 experiences can vary, but the underlying values remain the same.