How we communicate in our company

During the last year at buildo, we have been working on improving our internal communication dynamics. We had a clear goal in mind: to write a set of guidelines describing our company's specific communication needs and communication tools, so that each of us can communicate in the best way possible.

We wanted to answer questions such as the following:

• I have too many messages and emails. Who should I answer first?
• I need to send an urgent communication to a coworker. Which tool should I use? How do I ensure they understand that it is urgent? What guarantee do I have that they will read it?
• I have an issue to discuss. Should I call a meeting or start a digital discussion?
• How do I send a non-urgent company-wide announcement that I want everyone to read? Should I send an email and expect that everyone will read it?

Right after we drafted our guidelines, the COVID-19 pandemic happened, and we transformed into a fully remote company in the space of a day. Everything worked out without too much friction, and this was also due to the work we did on internal communication.

In this post, we want to share our guidelines and the principles we followed in writing them, so that readers can not only take inspiration for their own organizations but also give us feedback.

Taxonomy of communications

Before writing our internal guidelines, we began this work by analyzing the As-Is (or current state of affairs) at buildo. We followed a principle that we usually use to guide our continuous improvement process:

First, visualize — then improve.

We started by mapping the different kinds of communication that happen at buildo and the tools used in each case. We collected pain points and ideas from coworkers, and we studied what other companies are doing.

We realized that communication could be categorized based on different criteria and scales: some are urgent, some are important, some happen in real-time, etc. Here is how we decided to categorize them.

Synchronous and asynchronous communication

In an organization, there are usually several different ways to communicate and have discussions: for example, Slack, emails, meetings, conversations by the coffee machine, etc. Each of these means of communication is synchronous, asynchronous, or can be placed on a certain point on the spectrum between the two.

Synchronous communication

Synchronous communication means that two or more people exchange information in real-time, and expect real-time answers.

An excellent example of synchronous communication is a meeting. Attendees at a meeting participate in real-time, expecting their colleagues to process their ideas and suggestions and respond immediately.

Other examples of synchronous communication are phone calls, talk at desks, coffee break discussions, etc.

Asynchronous communication

Asynchronous communication refers to the exchange of information between two or more parties without requiring all recipients to respond immediately.

A good example of asynchronous communication is an email exchange. When you send an email, you do not expect the recipient to read it right away or to answer it immediately. You know that you cannot rely on the recipient interrupting whatever they are doing to read the email and answer in real-time.

Other examples of asynchronous communication are discussions on a ticketing or task management system such as JIRA, discussions on GitHub, etc.

What about chat apps, such as Slack or Microsoft Teams?

Messaging apps are a sort of hybrid: they are asynchronous until you receive a notification. A Slack tag, for example, triggers a notification that may interrupt your focus. Whenever such tools distract you from your current focus and try to attract your attention, they become synchronous. Furthermore, it is a matter of expectations: some people write on Slack because they expect an immediate answer, meaning that they use it as a synchronous mean of communication.

Because expectations govern how we use these tools, guidelines are necessary to make sure that everyone is on the same page.

Important is not necessarily urgent

When we think about a discussion that we want to start, it is natural to consider important topics as urgent. However, urgency and importance are two orthogonal axes in the taxonomy of communication.

Importance should drive the order in which communications are addressed. The most important communications relate to priority tasks, the team’s current focus, and items that add value to your work and help you accomplish your goals.

Urgency describes time-sensitive communications, where the value drastically decreases with time or upon reaching a specific deadline. The most urgent communications relate to emergencies on a project, a web app’s downtime, issues with a customer, or tasks that need to be completed just before a deadline. Urgent communications need to reach their target audience in a timely manner, before a given point in time.

The following matrix — the Eisenhower or Covey matrix — depicts how tasks or communications should be handled based on importance and urgency.

Eisenhower or Covey time management matrix

Most day-to-day communications should fall into the bottom right quadrant: important communications that add value to the work you are focusing on and that are not time-sensitive. Urgent communications should be exceptional by definition (e.g., emergencies) and should utilize dedicated channels and tools.

Communication guidelines

We just saw the main axes that can be used to categorize communications: they can be more or less important, urgent or not, synchronous or asynchronous. So what kind of communication should I use? And when?

Why synchronous communication is often bad

Based on what we saw, treating most of our day-to-day communications as urgent is a bad practice.

If your preferred method of communication is synchronous, and you expect an immediate or timely response, you have a communication problem. This Basecamp guide describes many of the negative aspects of synchronous communication in the specific context of chat messaging apps, and it was invaluable to us in writing these guidelines. However, the same concepts apply to any synchronous communication tool (e.g., a phone call, a face-to-face discussion, or a meeting).

Here are some of the negative aspects of synchronous communication.

🕐 Timely

• Synchronous communications, by definition, happen in a given moment in time. Anyone who misses the moment, because, for example, they missed the meeting, loses the opportunity to contribute.
• They generate FOMO (fear of missing out). Because of a fear of missing out on content, you feel the urge to attend to every synchronous communication (e.g., every meeting or every Slack channel).
• If all of your conversations follow this pattern, important communications that should reach the whole organization cannot be differentiated from other less important ones, and they risk being lost or neglected for too long.

😨 Stress and anxiety

• Synchronous communications inevitably result in having to stop concentrating on what you are doing to shift your attention to the discussion. As a result, you frequently lose focus.
• Attending numerous meetings results in time and focus fragmentation. It will be difficult to find uninterrupted time slots to focus on your priorities. Participating in several open discussions via chat is even worse: it is like attending many meetings at the same time.

⚡️ No time to reflect

• Synchronous communications force people to be reactive. If they take the time to consider a response or elaborate on a complex thought, the discussion might move on to a different topic. The result is that people lose the opportunity to express themselves. As a consequence, people tend to write shorter messages without thinking too much and to answer as fast as possible during a meeting.

🗄 Hard to search and structure

• Synchronous communications leave no structured traces and are harder to organize and search.
• During a real-time discussion, it is hard to keep track of context, and you can quickly lose the starting point of view or past discussions on the same topic.
• A considerable effort is spent to make meetings structured (e.g., minutes, recap, etc.), while a chat conversation will soon be lost in the history of the chat and forgotten. In both cases, it is hard to organize the full context of a topic in a clear and searchable way.

Real-time sometimes, but asynchronous most of the time

According to one of the guidelines in the Basecamp Guide to Internal Communication, discussions in an organization should be asynchronous by default. After considering the needs and culture of our company and based on everything described above, we decided to adopt the same philosophy at buildo.

However, this does not mean that synchronous communication should never be used. It offers some advantages over asynchronous communication in specific situations.

🏎 Synchronous communication is faster

A synchronous discussion, such as a meeting, allows a team to discuss a topic quickly and receive immediate feedback. For this reason, synchronous communication must be a part of your toolbox, and it is the right way to handle the most urgent matters, such as emergencies.

🎮 Nonverbal communication

A real-time face-to-face discussion incorporates the aspects of human communication beyond writing or simply speaking: expressions, gestures, etc. It is preferable to hold an in-person meeting when the discussion relates, for example, to people's feelings and emotions or interpersonal relationships.

🥊 Facilitation

Facilitation can be beneficial or even necessary for some discussions, and most facilitation formats are best suited to real-time synchronous communication. It is also possible to facilitate asynchronous discussions, but facilitators do best in in-person meetings.

🎭 Teamwork

Some collaboration formats are more suitable for in-person meetings, especially when they involve physical tools (e.g., post-its, boards, etc.). For this reason, some team activities work better in person (e.g., software requirements elicitation, codesign and divergence workshops, etc.).

Meeting guidelines

We have seen that meetings and in-person discussions are a powerful tool in some contexts. However, they are also expensive, and in many cases, they can result in a waste of time and effort. Meetings should not be the default communication and collaboration option: they should be the last resource.

It is also beneficial to avoid booking meetings at times when they will interrupt focused work for participants and to consider the needs of your coworkers. Our advice is to write a set of guidelines about how and when to book meetings, taking into account working hours, focus time, company dynamics, etc.

Here are some of the principles that drive our meeting guidelines.

• Make the purpose and scope of the meeting explicit. Participants need to know in advance the purpose of a meeting they have been invited to, so they can decide whether to participate or not and to prepare for it beforehand.
• Choose participants carefully. When you book a meeting, take some time to think about who should attend. The number of participants should be proportional to the importance of the decision that will be taken.
• Be clear if you cannot attend. The organizer needs to know who will attend and who will not, so that they can decide when to start and how to organize the discussion.
• Reserve some time to make a record of the outcome, either in written form or by recording a short video recap.
• Evaluate alternatives based on what was said above. Before announcing a meeting, consider if a meeting is the best way to achieve your purpose or if the discussion could start asynchronously on different channels.

At buildo, we also use Clockwise, a smart calendar assistant designed to maximize focus time and help to respect coworkers' needs when booking meetings. If you want to try it, remember that tools by themselves do not solve problems: listen to your coworkers, observe the As-Is, understand where to improve, write guidelines tailored to your company, and choose the right tools based on that.

Should I use a synchronous or asynchronous method?

It depends! You should choose based on the scenario and the parameters outlined above. Sometimes, the answer could also be a mix of both approaches: start an asynchronous discussion and then call a meeting to decide only when you have collected enough input.

The following are some examples of frequent discussions at buildo and the communication guidelines that we have designed for these discussions.

📢 Announcements

For communications that must reach most of or all of the people at buildo (e.g., announcements about important changes in internal processes or policies), synchronous communication is not the best choice: booking a meeting involving the entire company would be difficult and expensive.

Here is what we usually do instead.

• Send an email, if no further discussion is expected
• Send an announcement in a dedicated Slack channel

When we need to receive a confirmation from everyone, we also open a dedicated task in our task management system (i.e., a company kanban board), and close it only when we have received asynchronous confirmation from everyone on the task itself.

⚙️ Project-related discussions

Teamwork on customer projects is characterized by periodic moments of synchronicity: for example, a daily stand-up meeting or a weekly meeting to organize the work.

Codesign and requirement gathering activities work better if held in person, in front of a board, and with the right tools. These activities are necessary for the early stages of each project, usually in close collaboration with the customer.

It is fundamental that all decisions and discussions are recorded in a structured written record for future reference. Each decision or step forward is tracked either in a dedicated task or in the project documentation.

Once work is more defined, and a weekly or daily synchronous communication is sufficient to synchronize the team, communication should happen asynchronously by default, according to each task’s context.

The project Slack channel can be used to obtain quick feedback and for rapid discussions. It will not necessarily be read by all team members, however, and it does not leave a structured record.

If a Slack discussion results in a project-related decision, this communication should be recorded in written form in the most suitable place and using the most appropriate tool (e.g., project documentation or related tasks on the project board).

🚨 Emergencies

These are urgent by definition! They should be communicated as quickly as possible and in the most visible way possible.

A message on the project channel is not sufficient because it ends up having the same urgency and importance as other discussions that are not emergencies.

Emergencies should be separated from daily communication noise and should happen through dedicated tools (e.g., a dedicated Slack channel, a phone call).

🌷 Continuous improvement and governance

Continuous improvement discussions on company governance and policies often impact many people but are rarely considered urgent.

They are the perfect discussion to begin asynchronously.

When a consensus needs to be reached, when feedback and reactions need to be gathered from coworkers, or when facilitation becomes beneficial to reaching a decision, then it is time to move the discussion to an in-person format. At this point, enough material will have been gathered asynchronously that the in-person format will be most efficient.

Tools and SLAs (service-level agreements)

There are still some questions that have not been answered. If I need to start an asynchronous, non-urgent discussion, then what tool should I use? When should I expect people to read my messages? When is the right time to ping someone?

At buildo, we use different tools, and each tool has a specific set of characteristics that best fit the use cases listed above. We use Slack as a chat messaging app, GitHub projects, or JIRA for task tracking and contextual discussions, etc. Our guidelines do not force a specific tool. Given the principles defined above, everyone has the power to choose if and when to start a discussion and how. In the case of a disagreement, we simply ask each other. We might ask, for example, “Are you sure we have enough information to have a meeting about this? Should we start discussing on the dedicated task and collect some feedback first?”

However, we did want to set expectations for the tools that we use. If I write a message on Slack, should I expect everyone to read it? By when? If I have an emergency and want to make sure a coworker receives my communication, what tool should I use?

To cover this last part, we defined suggested SLAs for each tool that we use, so that people at buildo can choose a tool based on the type of discussion, its urgency, and its importance. When these SLA time frames are not followed, then it is the right time to send a ping or escalate to another tool.

Here are the classes we defined.

• No guarantee: tools or communication channels for which you cannot expect that a coworker will read or respond to your messages
• Must read — announcements: announcements that should be read eventually. Because they are usually not urgent, we expect people to read announcements within approximately two weeks.
• Must read — improvement and governance activities: all operational communications that are not related to current customer projects or current company focus. They should be read within approximately one week.
• Must read — focus: communications regarding activities that are the current focus of the company or of the specific team (e.g., active customer projects). Most day-to-day operational communication falls under this category, and we expect people participating in these projects or discussions to read them within one working day.
• Must read — ASAP: applies only to channels dedicated to urgent topics and emergencies

In our internal guidelines, we then mapped these categories to each communication tool and added some examples. I will not include the full list here since the content is specific to our internal dynamics and teams, but here is a hint of these guidelines:

• No guarantee is the default SLA for Slack channels. At buildo, if you write a message on Slack, you should not expect that it will be read in a timely manner in general.
• Must read — announcements applies to our Slack announcements channel. It is a channel that we expect everyone to read eventually but without any urgency (i.e., within approximately two weeks).
• Must read — focus applies to specific Slack channels dedicated to projects and to discussions on project boards and task management systems and applies only to the people that are part of the project team. If you are working daily on a feature and contact a teammate who is collaborating with you, you can expect that they will read the project channel or comments on the project board within one working day.
• Must read — improvement and governance applies to non-project asynchronous discussions. If you are working on a task related to the continuous improvement of an internal process, you can expect people who collaborate with you to read your comments on the task in the dedicated board within one week. An excellent example of continuous improvement activity is writing these communication guidelines — at buildo, we spend approximately 20% of our time working on continuous improvement and non-project activities.
• Slack calls or phone calls fall under the ASAP category. If the production server of an app goes down, it is an emergency, and you may call whoever can solve the issue and expect them to answer right away. These situations are exceptions and should not happen often.

These points are just a portion of this last part of our guidelines, but they should be sufficient to show the principles we followed and why we decided to define those categories.

Conclusion

Company communication is one of the most crucial areas of your company culture: it is the base for good collaboration, and it is part of what allows you to keep stress under control and at the same time to reach company goals as a team.

I hope that this post can help you improve the communication dynamics in your company. Do not take these guidelines for granted: observe existing dynamics in your company, understand where improvement is needed, choose the right tools, write your own guidelines (keeping in mind that tools alone do not solve problems), and set expectations for each communication channel you decide to adopt.

Communication guidelines that take into account your company's culture and needs can create a better working environment for your employees and better products for your customers.

The guidelines outlined in this post are the result of a successful collaboration between a number of us. In particular, kudos to Vincenzo Guerrisi, our Internal Communication Owner, who guided and facilitated this collaboration.

If you want to work in a place where we care about company culture and internal communication, please see https://buildo.io/careers.