The Acquisition, Conversion, and Backend Telemetry Groups are part of the Growth section. The Acquisition Group is responsible for promoting the value of GitLab and accelerating site visitors transition to happy valued users of our product. The Conversion Group is responsible for continually improving the user experience when interacting with locked features, limits and trials. The Telemetry Group is responsible for the collection and analysis of data to improve GitLab's product which includes being the primary caretaker of the versions app.
I have a question. Who do I ask? Questions should start by @ mentioning the Product Manager for the Acquisition group, the Conversion group, the Telemetry group or by creating an issue in our Workflow board.
The following people are permanent members of the Acquisition, Conversion, and Backend Telemetry Group:
|Jerome Ng||Backend Engineering Manager, Growth:Acquisition and Conversion and Telemetry|
|Alina Mihaila||Backend Engineer, Telemetry|
|Alex Buijs||Senior Fullstack Engineer, Growth:Acquisition|
|Nicolas Dular||Senior Fullstack Engineer, Growth:Acquisition|
|Alper Akgun||Senior Fullstack Engineer, Growth:Conversion|
|Dallas Reedy||Fullstack Engineer, Growth:Conversion|
Our team follows the Product Development Flow which defines a continuous workflow for delivering product value.
We use workflow boards to track issue progress throughout a milestone cycle. Workflow boards should be viewed at the highest group level for visibility into all nested projects in a group.
There are three groups we use:
|Acquisition Workflow||Acquisition Workflow||Acquisition Workflow||-|
|Conversion Workflow||-||Conversion Workflow||-|
|Telemetry Workflow||-||Telemetry Workflow||-|
We use milestone boards for high level planning and roadmapping across several milestones.
|Acquisition Milestones||Acquisition Milestones||Acquisition Milestones|
|Conversion Milestones||-||Conversion Milestones|
|Telemetry Milestones||-||Telemetry Milestones|
Planning a milestone is a collaborative effort between Product, Engineering, and UX.
We utilize a milestone planning issue to keep our team organized during the planning phase. Here is an example milestone planning issue. A milestone planning issue consists of:
The following tasks need to be completed for planning a milestone:
~milestone::p1/p2/p3/p4labels to issues
Deliverablelabel until the sum of tagged issue weights equals the milestone capacity.
Our milestone capacity tells us how many issue weights we can expect to complete in a given milestone. This is calculated by taking the sum of issue weights completed in the last milestone prorated by holidays. If there is a large variation in the estimated capacity of the last milestone and the one before it, we will use an average estimated capacity of the last few milestones. Here is an example of how we calculate capacity:
In this example, the current milestone capacity is 31 weights.
A milestone commitment is a list of issues our team aims to complete in the milestone. After issues are broken down, estimated, and prioritized, we begin tagging issues with the current milestone until the sum of the tagged issue weights equals our team's milestone capacity. All issues in a milestone commitment should also have the
To help our team be efficient, we explicitly define how our team uses issues.
We aim to create issues in the same project as where the future merge request will live. For example, if an experiment is being run in the Customers application, both the issue and MR should be created in the Customers project.
We emphasize creating the issue in the right project to avoid having to close and move issues later in the development process. If the location of the future merge request cannot be determined, we will create the issue in our catch-all growth team-tasks project.
We aim to maintain a 1:1 ratio between issues and merge requests. For example, if one issue requires two merge requests, we will split the issue into two issues. We aim for a 1:1 ratio as we believe it emphasizes keeping MRs small, it makes estimation on issues straight forward, and it provides more visibility into an issue's progress.
We have two types of issues we work with:
Parent issues are GitLab issues that are used to group several child issues together. These issues are typically focused on product and the high level overviews of a feature or experiment.
Our groups have decided to use Parent Issues instead of epics due to some of the limitations with epics (not being able to add labels, add milestones, assign team members, or link issues across projects). Here are guidelines we follow when using parent issues:
Child issues are small broken down issues of Parent Issues. These issues are typically focused on engineering implementation or design work.
We use issue labels to keep us organized. Every issue has a set of required labels that the issue must be tagged with. Every issue also has a set of optional labels that are used as needed.
~"workflow::ready for development,
~"workflow::In dev, etc.
MR labels can mirror issue labels (which is automatically done when created from an issue), but only certain labels are required for correctly measuring throughput.
Prioritization is a collaboration between Product, UX, Data, and Engineering. To help our group prioritize issues within a milestone, we utilize the milestone priority labels:
The work done by our engineering teams mainly fall into two categories: PM Initiatives and Engineering Initiatives.
PM Initiatives: This work is primarily related to driving value for our customers. This work is typically outlined by the product manager in the milestone planning issue.
Engineering Initiatives: This work is primarily related to driving value for internal teams. Some examples of this work are bug fixes, follow-up issues, refactoring, career development work, or anything an engineer thinks is important enough to be worked on.
Engineers should aim to prioritize PM Initiatives to accomplish each milestone, however, they can also work on Engineering Initiatives during any down time or by carving out dedicated time during capacity planning. We should aim to carve out dedicated time for Engineering Initaitives that take one or more full working days. To carve out time, simply add a comment to the milestone planning issue. Here's an example of carving out time for Performance training.
We always push ourselves to be iterative and make the minimal viable change. Defining the minimal viable change takes practice.
The image above illustrates how we iterate. The goal is to build something quick and functional. Our first iteration gets us from A to B even though it doesn't have all the bells and whistles. A skateboard is not as fast as a car, but it is fully functional. Each subsequent iteration provides the user with more speed, more control, and a better aesthetic.
Building a skateboard is low complexity and can be assembled in a day. Building a car is high complexity and takes thousands of parts and a much longer assembly time. Start with the skateboard first, iterate to the scooter next, then continue iterating and eventually you can build a car.
A common misconception of iteration is that there is no waste. Using the example above, the parts of a skateboard can be reused in a scooter, however, they cannot be reused in a car. Iteration often requires us to throw away code to make way for a better product.
Technical debt: It's common to discover technical debt during development of a new feature. In the spirit of "minimum viable change," the resolution of technical debt can be deferred to a follow-up issue.
We have daily asynchronous standups using status hero's Slack integration. The purpose of these standups are to allow team members to have visibility into what everyone else is doing, allow a platform for asking for and offering help, and provide a starting point for some social conversations.
Three questions are asked at each standup:
Each group holds synchronus meetings at least once a week to gain additional clarity and alignment on our async discussions.
The agenda for each meeting is structured around the Product Development Flow.
workflow::ready for development,
One of our main engineering metrics is throughput which is the total number of MRs that are completed and in production in a given period of time. We use throughput to encourage small MRs and to practice our values of iteration. Read more about why we adoped this model.
We aim for 10 MRs per engineer per month which is tracked using our throughput metrics dashboard.