Teams

Cabify teams are organised around problem spaces. We seek alignment between all the people needed to make progress on those spaces, regardless of their discipline and reporting lines, to create value for our customers and our company. For example, to solve the Rider problem space, we need different disciplines such as User Research, Product Management, Engineering, Design, Data Analysis and Business Managers.

The following are our current groups and squads. You can learn about their mission, metrics, rituals and many more in their links below:

We know (from experience) that dependencies slow us down. Waiting for another squad who have other priorities, to complete something before you can continue to work on a feature is a recipe for delay and frustration. So, we strive to maximise the number of squads that can operate independently, making coordination easy in a problem space within the same group and squads, minimizing competing priorities.

We also recognise that people band together around shared topics of interest/technologies. We use the name Chapters for those groups.

Disciplines

We identify disciplines as different expertise areas with low overlap. They work together to provide a diversity of skills and approaches.

  • Data Analysis
  • Data Engineering
  • Data Science
  • Design
  • Software Engineering
  • Growth
  • Customer operations
  • Product Management
  • User Research

Roles

Product Managers and Engineer Managers/Head of [area]

  • Product Managers are responsible for defining what should be done next. Engineer managers (IV and V)/Heads(VI) are responsible for defining how it should be done. To put it another way, the Product Manager is responsible for ensuring that the Squad does the right thing (to add value to the user/business), whereas Senior engineer managers (V)/Heads(VI) are responsible for ensuring their engineers do the thing right. Produce managers are here to ensure that your work comes with the context of the needs and problems of the user or the business. The “Manager” in their title is not to manage up-down, but rather to manage interactions and relationships between other teams and departments so that you can get your job done effectively.

  • Engineering Managers are the ones who represent the team outwards (concentrating interruptions and meetings, peeking at things that may never happen…) and care for the team wellbeing (career progression, individual needs, salary changes and promotions…).

They are able to understand how new needs can be solved and provide rough estimates. To achieve this, they need to write code outside of the critical path, be involved on all development activities and get support from other engineers.

They are part of the reporting lines and also approve leaves, budgets. They are present to create an environment, processes and policies so the team(s) can work productively towards achieving the goals of the business.

Group leaders (Group EM and Group PM) Alongside the PMs and EMs on their group, they help to set both the product and technical vision for their area of the product. They also make sure there is alignment within the teams of their group, but also across groups. They are responsible to mentoring PMs, EMs and other leaders of their respective disciplines on their group to help them grow into strong leaders themselves. They also play an important role in making sure the teams identify hiring needs and they are responsible for securing staffing for their groups. Their ultimate goal is to make sure people in their group have what it takes to execute their vision and roadmaps.

Heads are group leaders for at least one group and their scope is big enough that let’s them have the company-wide impact expected for an L6.

In both User Research and Data Science we use the scientific method to generate a positive business impact. That can be done through qualitative or quantitative research. I’ll use the term researchers to refer to both of them from now on. Researchers value work diversity quite a lot. Being able to work on different problems, with different tools and in contact with different people is one of the most alluring perks of the job. The inherent diversity comes at a cost of lower project ownership and business knowledge of specific problem spaces.

In order to try to balance both things out we want to propose an organisational shift. It’s already happened informally with time but we want to make it much more explicit and official. Members of both squads of a certain level of seniority can act as a Research Link between a particular group, squad or region and the Data Science and User Research teams. This position can be understood in many ways so we will try to describe it as much as we can in the following enumeration:

  • A Research link is proactive and with a high level of ownership
  • A Research link knows about the problem space of the group/squad/region
  • A Research link is involved in comms channels for the squad/region
  • A Research link should participate in rituals they deem useful and helping taking decisions
  • A Research link happens at group, squad or region level (i.e. Match and Pricing for Data Science, Latam and Europe for User Research)
  • A Research link have certain level of seniority, and the role will be included as data point for career path
  • A Research link are meant to be stable over time, but can change to accommodate needs of User Research and Data Science teams
  • A Research link is expected to interact heavily with PMs, Design Managers (especially User Research), Engineering Managers (mostly Data Science) and business and local/regional stakeholders
  • A Research link is NOT a resource expected to just execute on squad backlog
  • Not every researcher is a Research link
  • Not all research work related to an squad/group/region is executed by its Research link

The assignment of researchers to groups and squads has room for flexibility and will follow the natural workload and importance of those groups/squads/regions. For instance, User Research is mostly involved with user-facing groups such as Rider, Driver, Marketplace, C4B, Spain and Latam. Data Science however has a wider scope in principle, since it is involved in more groups such as Finance & Compliance but its workload is heavily skewed to particular squads such as Pricing, Rider Growth, Match, Maps or Financial Fraud. Besides this, not all groups/squads/geographies will have a Research Link assigned from the very beginning due to hiring constraints and therefore some iteration will be needed in the future to accommodate everyone in this new structure. This does not mean that those groups/squads/geographies work will be de-prioritised or ignored in any way. We will take care of them as a team until new hires are assigned to them. We appreciate your patience and understanding :)

Guilds

At Cabify, bias to action and user centric mantras have led us to choose a problem-space oriented organization within the Tech Team: people with different skills (eg: designers, devs, analysts…) try together to solve certain problems (eg: rider growth) coordinated by a Product Manager.

This allows us to move very fast as it empowers squads and groups to autonomously move forward with iteratively better solutions to a problem, as opposed to having to coordinate roadmaps of classic skill-oriented teams (eg: design team, dev team, systems team…). However, we are aware that to succeed in the long run we need to make sure cabify is an awesome place to work for all disciplines involved in product development.

The idea of people with similar skill sets gathering together to establish better ways to practise their arts is far from new: in ancient Rome, and more prominently in medieval cities, the most experienced craftsmen of a certain art gathered together in guilds and came up with rules and processes not only practise their expertise, but also to enable new members to progress and gather experience.

Create a guid

We at Cabify aim to push ownership, so creating a guild have similar resources as a team has:

  • First and most important, pick a name for the guild <guild name>
  • Create these Slack resources: #a-<guild name>-test, #a-<guild name> and @<guild name>-ops.
  • Define the guild in the Org Chart and assign at least 1 member to the guild.
  • Create Chapter channel in the format defined in the Chapters section where <chapter name> will be <guild name>.
  • Create a GitLab group <guild name> to group the respositories for the guild.

From now on you can use the <guild name> to create new resources and share knowledge, libraries and so on.

List of Guilds

  • Design System.
  • Elixir.
  • Frontend.
  • SRE.

Guild mission

We use the Design System guild as an example of guild, but guilds might exist for any disciplines within the tech team:

  • Design System
  • Product Management
  • Data Analysis
  • Data Science
  • Engineering
  • User Research

The Design System guild mission would then be as it follows

Our mission is to improve the quality of our products and the efficiency of the teams designing and building them.

Chapters

A Chapter is simply a group of people who share a skill set, area of competency or topic of interest. Chapters may organise periodic meetings as opportunities to share knowledge, even though they may not be in the same team. Chapters often also have a Slack channel and should be found with the format #t-ch-[chapter name] Eg. #t-ch-elixir