Communication & knowledge sharing

Cabify is over 1.000 persons, with 300 of them working on the Tech department. In this context, communication becomes key, not only inside the product team but also between other departments and key people in the organization.

Whilst casual conversations are the easiest way to pass information in a small group of people, hallway conversation do not scale as the company grows and excludes people who are not working from the office. Thus, we need to ensure some communication flows to other teams and departments.

Language

Cabify is a particular company. It operates in Spanish speaking countries, but we want Tech to be open and diverse, which means using English. This section tries to clarify when to use each of them.

• Tech uses English: English is the lingua franca of the technology industry and, as part of it, Cabify uses English inside Tech for all public communications: Documents, presentations, chat messages, emails, video recordings, code… anything that can be used in the future by a new joiner or third party (like an auditor) needs to be in English.
  • Example: State of the Tech events are english-only
  • Exception: Some teams in tech, such as User Resarch, deliver their work directly to local teams more often than to other Tech teams. In this case, their deliverables can be in Spanish when producing two versions is too costly.

• Local teams use Spanish: Access to English education is not equal all over the world, and Cabify would be at a competitive disadvantage if it forced local operation teams to interact in English.

• Global teams mix both: Global teams interact with Local and Tech, so they adapt to the audience. Global deliverables are created in English, although presentations are usually in Spanish.
  • Example: All hands meetings happen in Spanish, with a translation for English

This use of different languages by different audiences reflects on the language used on the diferent communication media.

Slack

We live and breathe on Slack and most of our inter-team/department synchronous communication happens there so we include remote people.

But people need space and time to produce quality work, so they shouldn’t be constantly interrupted. Feel free to turn off Slack or just notifications as needed to focus. No one will be mad at you for not replying immediately.

We are also large enough, and hire frequently enough, to not be able to know all other persons on the company. Because of that, remember to update your Slack profile with your Group, Squad and Position, to give some context about you to the people you interact with.

To organize conversations, we use multiple Slack channels, some of them are critical and everyone should be following them, and some are a bit more purpose specific. These specific channels follow a pattern that ends up making them self descriptive.

Following there’s a list of these channels and some samples of the topic specific channels:

• #announcements: this is a company wide channel. Anything that our teams are changing, adding to our products that might be of interest to everyone or anyone in Cabify is announced here.
• #a-[team]: a channel that integrates automated alerting from our technical services
• #t-announcements: the channel in which we announce things that affect the whole product organization. If it’s announced here it is considered the law and it is considered that everybody is aware. It’s our boletin oficial for product and development.
• #t-eng-announcements: the channel in which we announce all things tech. You’ll find deprecation paths, tech-glue summaries, and tech-only announcements like new platform features in this channel. If you are an engineer it is considered mandatory that you join this channel to be up to date with the things that are going on with the tech side of the company as things announced here are automatically considered known.
• #t-questions: a way to raise your hand to ask whatever. We encourage you to use this channel to share any concern or clear any doubt you may have about any topic. And we also encourage you to contribute back by replying to questions helping other people.
• #t-production: channel where we discuss all things production. It could be an ongoing incident that hasn’t escalated to an emergency, or announcing some change that will happen in production. Join this channel and pay attention to it as it will give you the pulse of what’s going on.
• #t-emergencies: channel where we get in sync when there’s an ongoing incident. Avoid posting here unless there is an actual emergency (people has alarms set in this channel). Prefer #t-production if you think that there may be an event.
• #t-[team]: a squad, fireteam, organization, or relevant product topic channel. Some examples:
  • #t-platform for the Platform group.
  • #t-billing for the Billing team.
• #t-ch-[topic]: a Chapter channel for cross-team discussion on a specific programming language, technology or technical topic. They should be quite self explanatory, but a small selection with the most used ones is:
  • #t-ch-couchdb
  • #t-ch-devops
  • #t-ch-elasticsearch
  • #t-ch-elixir
  • #t-ch-gitlab
  • #t-ch-golang - Where people complain
  • #t-ch-pubsub - Google’s: Pub/Sub
  • #t-ch-mysql
  • #t-ch-observability - Observability stands for metrics, logging and distributed tracing.
  • #t-ch-postgresql
  • #t-ch-proglangs - Programming languages
  • #t-ch-redis
  • #t-ch-rust
  • #t-ch-cybersecurity - Security all the things
• #t-e-xxx: a channel to discuss a particular Epic
• #m-xxx: a mission channel where we communicate with people from other departmants about a particular project/theme.
• #tmp-p-xxx: a temporary channel that is used for a particular effort
• #product-announcements: the place to communicate new features and problems in our product
• #issues-[team]: channels where excellence or logistics report urgent issues affecting our business operation. If not urgent, a ticket should be created at Zendesk.
  • #issues-driver - issues affecting drivers or inversionistas
  • #issues-rider - issues affecting riders
  • #issues-business - issues affecting companies or API integrations

There are also some special Slack handles with different purposes:

• @[team] This is a handle that will notify an entire product team
• @[team]-ops The purpose of the Ops handle is to avoid distracting the team by centralizing the non urgent technical operational issues on a single person during working hours, this is a role that rotates weekly. Examples of this are informing about changes announced in the tech billboard, fixing broken testing environments, answering technical questions or forwarding production issues to the appropriate on-call person.

Beyond Slack: meetings and calls

Although most of this communication takes places on Slack, it’s important to understand that Slack is a low bandwidth communication channel.

If you find yourself in a conversation that is having too much back and forth, seriously consider dropping to fully sync by talking face to face with the person that you are chatting with.

As we include more and more remote people it becomes challenging to be in the same building, so just use Zoom to start a call, or schedule a meeting if there’s no other option.

If you have to go the meeting way, it’s important to schedule meetings with relevant people inside the organization to speed up solutions or understand business problems. But try to keep meetings to a minimum and with the least amount of people present. Please refer to the following guidelines to scheduling effective meetings.

If you think other squads, organization or fireteams are affected by changes you or your squad are doing, fail on the side of over-communicating so everybody is on the same page.

When in doubt, over-communicate.

After a conclusion has been reached, update the meeting agenda and then publish the information in the relevant channel, or write this decision wherever you are tracking the effort. If it’s not written down, it doesn’t exist.

Google Groups

Google Groups is our main tool for grouping people around an email address. Just to give some example, we use them either to send an email to a specific group of people, to invite a whole team to a meeting or to share a document to a product group.

Due to Google Groups emails are widely use in the Product team, we have to create them following a pattern that makes them self descriptive. It is important that they can be reachable.

To avoid complexity when adding a name to a Google Group email, we will use the same pattern used on the org-chart-9000.

When creating an email for a team, we will use the t.<team>@cabify.com nomenclature. For example:

• For the Fleet team, the Google Group email will be t.driver-fleet@cabify.com
• For the Billing team, the Google Group email will be t.billing@cabify.com

To manage any Google Group email except the automated ones (see below), you will have to request it via this form. The IT department will handle it. Do not create any depersonalized google users unless justified, as that would be a security risk (allowing SSO access to our services).

Automated google groups management

Some small subset of google groups is managed with terraform automatically. This allows us to ensure that the permissions and memberships are consistent and that there are no manual changes applied to the group settings.

We use automated google group management for the following use-cases:

• 1. Owners groups for 3rd-party services. Requesting such a group is almost self-service:
     • Please create an MR with a group definition according to the instructions
     • Make sure the pipeline is green (that means that you have passed all the linters, and the group configuration is consistent)
     • Assign the MR to @ilya.frolov for the review, merging, and applying.
• 1. Team group emails. If you want your team’s group email to be managed automatically, please follow the same process.

Handbook and Announcements

To ensure awareness we communicate any matter about the organization in the #t-announcements channel. Once something has been announced there it can be considered widely known.

To encourage people proposing changes to this handbook and grow the company together this handbook is considered as the single source of truth for the product organization.

To keep everyone in the loop we have automated announcing changes through merged pull requests.

To automatically announce a MR in the handbook in #t-announcements all you need to do is prefix the title of the MR with [announce]. Then, on merge, it will be immediately posted in #t-announcements.

Handbook and Tech Announcements

When the scope of the communication is limited to tech, the channel that we have to use is #t-eng-announcements.

In this particular case, to automatically announce a MR in the handbook in #t-eng-announcements just add the prefix [tech-announce] in the title of the MR.

Meetings

Meetings are really expensive as they are the ultimate representation of sync work by forcing all the attendants to be in the same place at the same time, they should be avoided as much as possible.

If we still find ourselves in the need of a meeting we should make sure that we get the best out of them by following some rules.

1. Every meeting must have a clear agenda.
   1. To make it accessible and simple create a google doc and write the points that will be discussed in the meeting using numbers so they are easy to refer to during the meeting.
   2. If a meeting does not have an agenda, request it. If there still is no agenda on writing, reject the meeting.
   3. During the meeting use the agenda to take notes. This is useful to document the conversation, to gather decisions and to catch up to speed or review them after the meeting.
   4. Use the agenda before the meeting to add comments or context. Doing this can lead to shorter meetings or even to not needing having the meeting at all.
2. Every meeting must start and end on time.
   1. Whoever joins late to the meeting can catch up using the agenda -> if you are late, we don’t wait.
   2. When the meeting agenda is fully covered, the meeting must be ended.
   3. Speedy meetings should be preferred. This leaves time at the end to finish writing down notes and to be on time for your next appointment.
3. Every meeting could involve remote people. Because of this, every meeting should be handled in a remote friendly way.

As meetings are really expensive (consider the large time investment), we need to make it count. It’s extremely important that everybody in the meeting be completely involved in the conversation, with active listening and free of distractions. If you are paying attention to an email or a Slack conversation at the same time a teammate is explaining some point, probably your comprehension wouldn’t be the best and your contributions won’t be so significant. If you are paying attention to anything else but the meeting, so priority is in another place, and you should not attend.

Shared Agenda Document

A good agenda starts with a google document that fulfils the following requirements:

• It is shared and allowed to edit by every person invited to the meeting (at least). For simplification just share it and allow edits to everyone at Cabify with the link.
• It has agenda points with an owner or presenter that are explicit in setting the context and expectations.
  • It has the name of the person who is presenting the subject.
  • It briefly mentions the subject.
  • It provides context explaining why we are going to talk about the subject: what is the need behind making this decision?
  • It explains what the expected decision is and already has a section to write it.
  • It documents who the owner of the further actions is. Because without ownership nothing will happen.
• If the agenda point is about informing people, it starts the line with FYI (for your information).
• If the agenda point is about asking someone to do something, it starts the line with FYA (for your action).
• Use the agenda to ask questions. This allows the presenter to read them, to reply to them without being interrupted, to prepare the meeting better, and also to automatically document them.
• When asking questions, replying or simply taking notes, prefix the note with the name of who’s talking.

Remote Friendly Meetings

1. Every meeting must have a meeting link, and it should be respected. Don’t start a Slack call if the meeting has a meeting link, this is the equivalent of telling some people that the meeting is in a room and then going to a different one without communicating it.
2. Use Zoom as a meeting technology.
   1. It is a proven technology that can scale to over 150 people in the same room with video enabled. Slack calls require lots of bandwidth to show only one video, Hangouts require lots of CPU, drain the battery really fast, and don’t scale over 3 people in bandwidth usage.
   2. It has really powerful screen sharing.
   3. It as a really good gallery mode that allows people to see everyone’s face.
   4. It supports changing the host of the meeting in the case the host has to leave.
   5. It supports recording the meetings to your local host, or the cloud.
3. Use one laptop per attendant, with video on. This will level the meeting and everyone will be able of seeing everybody else’s face. This has the psychological effect of making remote people feel in the same room as the rest of the people.
4. Use headphones with mic. This improves the sound you hear and produce quite a lot by reducing ambient sound.
5. Configure Zoom to mute when you join a call, then mute when you are not talking. This effectively removes all the ambient sound.
6. Consider not booking a room. Because you don’t really need it.
7. Use a shared agenda to write notes and decisions as the meeting is happening.
8. Use visual cues to communicate: raise you hand if you want to talk, show a thumb up to say yes, thumb down to say no. For example: to the question “can you hear me?”, show a thumb up.
9. You don’t need to ask everyone if they can hear you or if they can see your screenshare. If they don’t then they will let you know.

If you use the Zoom Scheduler browser extension, consider setting the following options to improve the meeting experience:

With those options, you solve the following problems:

• The Zoom room is specific for this particular event, and not tied to the host.
• Participants do not need to wait for the host to join the Zoom.
• Participants who join late, do not introduce noise when joining since they will be muted.

Tech and Product recurring meetings

We also run some recurring meetings to ensure engineers, product managers and engineering managers are aligned, working towards cross-team goals, and have the opportunity to share relevant updates/blockers with other teams. All these meetings are Zoom calls:

Engineering glue (#t-engineering-glue)

• When?: Weekly (Event in the “Engineering Events” calendar, the groups engineering@cabify.com and data-engineering@cabify.com are automatically invited).
• What?: Incident Reports, Technical issues important for the whole company.
• Who?: Everybody welcome.

People Management glue (#t-people-management)

• When?: Bi-weekly (Ask a manager to invite you).
• What?: Questions/announcements from/to top management, Share experiencies and best practices in management, management doubts.
• Who?: All managers with direct reports.

Groups Managers Sync&Share

• When?: Depends on each group, but mainly weekly/bi-weekly. (Ask a fellow manager in your group to invite you)
• What?: Sync between managers within the group, share best practices/doubts in management, select topics to be shared on the Management glue.
• Who?: All managers of the group.
• Suggestions
  • Recurrent point in the Group Meeting agenda Topics to be shared in People Management glue: Any manager can propose something to share or poke another manager to share an interesting topic.

Synchronous and Asynchronous Communication

Synchronous communication means I walk to your desk and tell you something, you consume the information at the same time I’m sending it.

Asynchronous communication means I can take a step out for lunch and catch up on transcripts when I get back. Asynchronous communication means I can ask my coworker a question in-chat and not worry about bothering them since they’ll get back to me when they’re available. Asynchronous communication means I can go to rural Minnesota and feel like I’m working from the office like normal.

A simpler explanation:

• Synchronous: Respond immediately.
• Asynchronous: Respond later.

We should prefer asynchronous communication over synchronous because it scales better, it leaves a trace of documentation so other people can use to catch up later, and it allows people from different time zones to work effectively without requiring them to work way too early or way too late. This doesn’t mean though that we should abandon all other non-asynchronous communication methods.

Approaching other teams

A typical example of this is when approaching new teams. At Cabify every team is encouraged to use their preferred methods for internal communications. As such, there isn’t a generic guideline that fits everybody: some prefer a more synchronous way of communicating, others work almost entirely asynchronously. You should be mindful of these differences when approaching teams, especially when you are looking to collaborate.

It is good practice to default with an intermediate tool like Slack and agree on the best way to communicate. That is, establish a protocol after a handshake.

Then provide context for your request. Assuming that the other part knows what you are working on will almost inevitably end up generating frustration and incomprehension, which should be avoided at all costs. Most importantly, provide a general level of urgency of your request. Is it something that can wait for a month? Should it be done in the next hour else we’ll be impacted?

If you are the receiving part, it is important to be clear about expectations. If you are busy, you should say so. Ask if it’s OK to wait for a bit or redirect the request to some of your team mates who has context and available time to help the requester. If no one does, then escalate to your manager. Doing so will avoid distracting you from delivering what you are expected. The other part will understand, so it’s OK to say you are busy.

Always be ready to switch to a more synchronous communication, like a Zoom call, if you sense misunderstandings. Likewise, you can switch to a more asynchronous method if the communication is proceeding flawlessly, so you can both improve efficiency.

Always remember: communication happens between people so try and imagine how would you react if you were the receiver of the request.

GitLab notifications

For developers, receiving the right GitLab notifications is part of a successful asynchronous communication.

Working asynchronously

• Avoid meetings as much as possible. Meetings are the ultimate synchronous event.
• Important meetings should be recorded for later consumption.
• If you have to have a meeting, use a shared agenda.
  • Take the time to write what you want to talk about and share the context.
  • Take the time to reply on the agenda before the meeting, do this enough and you will not need the meeting at all.
• Have a bias for action, don’t wait for consensus if you can make a decision, but build things that are easy to replace.
• Reduce noise in slack - avoid using @here or @channel. Only mention the people or team that you need attention from.
• If possible, move conversations out of Slack into PRs, Issues, RFCs and Experiment proposals. This will force you to think and write things down.
• Follow the how to write in plain english rules to improve communication.
• Use communications streams by using DMs in Slack. Post a comment or question, don’t expect the answer immediately, allow the conversation to flow through days if necessary. Use threads for sub topics.
• Consider using a Slack channel for stand ups instead of a stand up call.

Pro Zoom Accounts

Pro Zoom accounts allow Zoom users to start calls that have no time limit. This makes it a valuable tool and you can ask for a Pro Account if:

• You are a technical manager or a product manager.
• You are a qualitative user researcher.
• You have OnCall dutty.
• You are full remote.