Driver engagement

• Driver engagement
  • About
    • Mission
    • Vision
    • The team
  • How do we work
    • Who is who
    • Framework
      • Standup / Daily meetings
        • Why both?
      • Sprint planning
      • Retrospective
      • Kickoffs
      • Refinements
      • 1:1
    • Tools
      • Parabol
      • Miro
      • Shortcut
      • Gitlab
      • Figma
      • Zoom
      • Slack
      • 1Password
      • Phrase
  • Contact us
  • Tools \& Useful links

About

Driver Engagement is about knowing the needs of our drivers and adapting our products to them. We work on providing our drivers with a complete product that makes them choose us over the competitors. That’s why we are focused on engagement instead of retention. We are not focused on simply bringing drivers back to our app. We are focused on making drivers perceive the interactions with our product as meaningful interactions because they meet their needs, so that drivers can choose to keep performing actions with our product that are significant for them and for us.

We recommend these articles related to engagement vs retention: froged.com, medium.com.

Mission

Our mission is to grow our active drivers base by keeping them with us in a scalable way by building a relationship of loyalty and trust and by empowering them to the decision making so they repeatedly choose Cabify over the competitors.

Vision

Our vision is to be the first ride hailing app choice for drivers.

The team

We consider that we are a multidisciplinary team composed of Tech team (Product, Design, Engineering), Growth, Data Teams (Data Science, DANA), DRM and UR. Also, we understand the driver experience as a whole, with multiple touchpoints that can create engagement, trust and loyalty. That is the reason why we identify, plan and develop initiatives together to make drivers’ interactions with Cabify more meaningful for them. Some of these initiatives are product-based (adding or improving features of the driver app or Durga web), others are enablers that the tech team develops to allow other teams work on their own initiatives, and others are business initiatives.

How do we work

Who is who

Driver engagement is not a small team; rather, it is a team comprised of individuals playing different roles based on their expertise and circumstances.

• Engineering Manager
• Product Manager
• Design
• Engineer
  • Frontend
  • Android
  • Backend
• DRI: (Direct Responsible Individuals): They are the feature owners responsible for bringing initiatives to fruition. Typically, this role is assigned to 2 or 3 engineers (at least one for backend and one for frontend). An Engineer typically fulfills this role.
• OPS: The members assigned to OPS take responsibility for handling issues, bugs, and alerts during the current Sprint. They document and address reports and new alerts, focusing on addressing them rather than working on the main features of the Sprint. An Engineer typically fills this role.

Framework

Driver Engagement operates within the Scrum framework, with some modifications tailored to our specific needs. While we adhere to a set of rituals, we remain open to reviewing and adjusting them based on their effectiveness and relevance.

Standup / Daily meetings

We have two types of daily meetings:

• sync: These meetings take place on Tuesdays and Thursdays at 10:15. During this time, we discuss our progress from the previous day, our plans for the current day, and any obstacles or challenges we may be facing. We utilize our Shortcut Iteration Board to review the iteration objectives, issues, and other pertinent details, shaping the direction of each item.
• async: These meetings occur on Mondays, Wednesdays, and Fridays. At 09:40, an automated Slack message is triggered, providing a space for each team member to share updates on completed tasks and upcoming work. This is also an opportunity to communicate any blockers or request assistance.

Why both?

We have decided not to completely eliminate morning meetings, and currently, we are utilizing both approaches concurrently. This allows us to assess and determine which method works best for our team. Based on our observations and feedback, we will eventually transition to utilizing the most effective approach full-time.

Sprint planning

This meeting serves to prioritize and select the objectives that have been refined in the previous sprint, determining which ones will be included in the upcoming sprint.

Retrospective

The objective of this meeting is to acknowledge accomplishments and identify areas for improvement. To conduct successful retrospectives

Kickoffs

This initial meeting brings together the Engineering Manager, Product Manager, Design, and DRI’s to discuss a feature. Following this meeting, the team can begin brainstorming technical solutions to address the identified problem.

Refinements

While Kickoffs mark the beginning of discussions regarding a feature, Refinements serve as the final meetings to ensure that everything has been discussed and agreed upon. At this stage, the DRI’s can create epics and stories that provide specific details on the work to be done, enabling any team member to tackle the associated tasks.

1:1

These confidential meetings occur between each engineer and the engineering manager every two weeks.

Tools

Parabol

We use Parabol to make the best of our retrospectives.

Miro

We also use Miro for some dynamics and presentations.

Shortcut

Shortcut is our primary tool for tracking work and monitoring progress.

We utilize Shortcut milestones, iterations, epics, user stories and tasks to define, estimate, assign, and ultimately organize our team.

We have made adjustments to Shortcut to align it with our specific requirements. In our context, we define:

• A milestone is a complete feature.
• An epic as a collection of stories that delineate an iteration within a feature, which can be completed within a sprint.
• A user story as a set of tasks that deliver value to the end-user, involving collaboration across all team layers.
• A task as a technical step within a user story.

Gitlab

We utilize Cabify’s Gitlab instance for hosting our codebase and documentation. Additionally, technical discussions are conducted using Merge Requests or Issues. We also receive automated issues and alerts from other sources through this platform.

Figma

Figma is our chosen tool for design purposes and ensuring alignment between the Design team and the Engineering team.

Zoom

We rely on Zoom for synchronous communication within our team.

Slack

Slack serves as our platform for asynchronous communication and collaboration.

1Password

Used to store team passwords in a vault

Phrase

To manage localization for the Driver App and other web applications.