Introduction

In the fast-paced world of modern business, effective communication is the linchpin that holds teams together. Asynchronous communication has emerged as a powerful strategy, providing flexibility and efficiency for companies with distributed teams or diverse working hours. This article delves into the principles, tools, and best practices for fostering effective asynchronous communication within companies
It does not matter if your company has a working-from-home option if you need to stay in meetings the whole day.

Written First

To enable asynchronous communication, you need to move from sync meetings over video/audio to written communication.
Moreover, any synchronous meeting needs to output a written resume, so if something wasn't in the meeting it can catch up later on.

Issue templates

Clarity of writing is key for communication.
We use issue templates to enforce consistency among our team

Our current issue template:

## What is the objective of this issue or task? 
Provide a clear and concise paragraph explaining the purpose and significance of the task. Clearly state the problem or need that this issue aims to address.

## How will we measure the success of this task? 
Define specific, measurable, and achievable success criteria. These criteria should help determine if the objective has been met. This could include functional specifications, performance benchmarks, or user acceptance criteria.

## How are we implementing this?
Describe the proposed implementation in detail. Include any technical specifications or architectural considerations. If there are multiple ways to achieve the objective, discuss the pros and cons of each. If the implementation is not yet clear, provide a first draft or outline to initiate discussion.

## What is referenced in this task?
List any files, modules, or components that will be affected by this task. Include links to relevant documentation or external references. This section should help developers understand the broader context and potential impact of the changes. Company, User, Charge, Transaction, Support Chat, screenshot

RFC - Request For Comments

We moved all planning to written RFC (Request For Comments).
A document that outlines a change or solution for a given problem.
After the document is written by the RFC leader, the team reads the document and provides feedback and reviews.
Anybody can write an RFC, we don't have architectures.
The decision-making is distributed across the team.
The more seniors need to review and make sure we don't deliver a flawed solution.

You can read more about how companies are using RFC here: https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs

Review

We review everything that is being built.
From simple issues, to pull requests, to RFC, to system design, to product design.
We also revalidate if our prior decisions were good enough, and change them if needed.

Updates

Every day and every week we add more updates to our documentation.
The updates show how we are progressing every day and week.
This update is very useful to catch up when you are out of the office for a few days or vacation.
If you only have this information on sync meetings, you would lose all this information.
It is like you are writing to a queue of updates, and you stop reading the update from where you stopped.

Documentation

Any knowledge needs to be written down in our documentation.
Any questions from the customer or our team need to be in the documentation.
All RFCs need to be in the documentation.
Every process needs to be in the documentation.
Our documentation is like our GPT.
It is the knowledge of our company.
You should be able to learn anything about our company, our product, and our codebase by reading our documentation.
If you don't know what to do or how to prioritize, the documentation should provide you with the principles to take the right decision.

Synchronous Meetings

We still have synchronous meetings.
We still work together in the same office once per month.
We have one daily with the senior team to prioritize work.
We also have one daily per squad.
We have customer support daily at the end of the day to catch up on all customer bugs and demands.
We have a lot of synchronous meetings with our customers. This is by design. We want to really know our customer, their needs, and how they are using the product.
We also fall back to synchronous pair programming to share knowledge faster among the team.
Synchronous communication has its place in the remote and asynchronous world. It can help us share more context faster, or explain what is hard with only text and video.
We also bound more over video/audio.

In Conclusion

Woovi
Woovi is a Startup that enables shoppers to pay as they like. Woovi provides instant payment solutions for merchants to accept orders to make this possible.

If you want to work with us, we are hiring!

Image By WangXiNa