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, everyone at Cabify needs to update their Slack profile with your Group, Squad and Position, to give some context to the people they 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.

Required reading channels

Messages published on these channels are asumed to be read by their whole audience and to be common knowledge.

• #global-announcements: this is a company wide channel. It is a one-way channel for the company to share most relevant pieces of information for the whole of Cabify. Engineering publishes information about severe incidents here.
• #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 in Tech is aware. It’s our boletin oficial for product and development.
• #t-eng-announcements: the channel in which we announce all things Engineering. You’ll find deprecation paths, police alerts, 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.

Important and useful channels

• #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-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-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-[team-name]: every squad has a public channel following this format where it can be reached.
• #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. Language is Spanish 🇪🇸 .
  • #issues-business - issues affecting companies or API integrations
  • #issues-logistics - issues affecting the logistics operations
  • #issues-rider - issues affecting riders

On the specific case of the Driver audience the previous bullet point doesn’t apply, we use El Reportero to report tickets and we have the following important channels:

• #issues-driver-announcements - high impact issues reported through el reportero affecting drivers
• #tmp-elreportero-doubts - doubts or suspicius of issues affecting drivers

Channel naming conventions

Channels follow a prefix convention to make them easier to navigate:

• #a-: channels for automated alerts, usually per-team (#a-[team-name])
• #t-: channels related to Tech (as opposed to other company areas).
• #t-ch-[chapter]: a Chapter channel for cross-team discussion on a specific programming language, technology or technical topic.
• #t-e-[epic]: a channel to discuss a particular Epic (a sizeable cross-team project)
• #t-tmp-[longish-description]: temporary channel on a Tech topic, typically used for teams to collaborate outside of a project (like a handover between teams, or collaborations smaller than an epic)

Slack handles

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 or organizations 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 Tech 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

Unlike regular email, messages sent to a Google Group are not restricted to a single person inbox. Message history for groups, along with information on membership, etc… can be accessed on the web (depending on the group permissions), which makes them useful for preserving and continues conversations by any other current or future member. For instance, when communicating with a 3rd party, it is good practice to cc your team’s group both for team awareness and for bookkeeping of the answers.

Automated google groups management

Currently, management of google groups used in Tech is done with metatron using terraform. 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.

Manual google groups management

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).

This is the legacy approach and all groups inside Tech should be managed in the automated way. If your group is not yet automated, do the initial setup.

Explora and Personio

Explora is the company-wide intranet. Official documents, procedures and announcements are done via this platform (plus email).

It also has subsections for specific communities, like one for Tech.

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 Tech organization. When appropriate, the handbook references Explora to avoid duplicating information.

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.

ℹ️ We strive to make the handbook (most of it) public. So it should contain enough information for a new-joiner or candidate to understand Cabify, and no more. If you find yourself documenting your team process, consider other options such as using a runbook or your lobby.

Runbooks

We tend to repeat some processes at work. Sometimes is routine, and sometimes it happens under pressure during an incident. To make it easier for everyone at Cabify to perform at their best, we have a collection of runbooks.

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. Use Google Calendar to easly create a Google Doc for the meeting, and write the points that will be discussed in the meeting using numbers so they are easy to refer to during the meeting. Make the document writable by all attendees.
   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.
   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.
2. Use Zoom as a meeting technology, and record the call if the contents of the meeting could be reused or watched later (people on vacations or incompatible time zones).
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 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. Use a shared agenda to write notes and decisions as the meeting is happening.
7. 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.

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

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 synchronous communication methods.

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.

Approaching other teams

It is good practice to default with an intermediate tool like Slack and agree on the best way to communicate.

At Cabify every team is encouraged to use their preferred methods for internal communications. Common practice is to use the team channel (#t-[team-name]) for brief interactions that can be replied on an slack thread. If the topic cannot be resolved this way, move the topic to an issue on gitlab. Teams have a lobby project under their namespace where the issue should be created (unless instructed otherwise).

When approaching other teams, provide context so they can better be on your shoes. Also provide a sense of urgency (or lack of it) to help the other team prioritise.

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. When taking action on a request, always say so. It is ok to answer with «We will look into it and come back to you».

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 or requires more space than Slack allows, 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.