Fulfillment Sub-department

1. You are here:
2. Engineering
3. Development Department
4. Fulfillment Sub-department

Maintained by:

On this page

• Vision
• Mission
• Direction
• Team members
  • Fulfillment Sub-department People Leaders
  • Fulfillment:Purchase BE Team
  • Fulfillment:Purchase FE Team
  • Fulfillment:Provision Team
  • Fulfillment:Utilization BE Team
  • Fulfillment:Utilization FE Team
  • Fulfillment:Fulfillment Platform Team
• Stable counterparts
  • Fulfillment Product Management
  • Fulfillment Quality Engineering
  • Fulfillment UX
  • Fulfillment Security
  • Enterprise Applications
  • Sales Ops
  • Enterprise Sales
  • Commercial Sales
  • Channel Sales
  • Billing and Accounts Receivable
  • Customer Success
  • Support Engineering
• Project management process
  • SAFE
  • Planning
  • Intake Request
  • Prioritization
    • Self-Service Purchase team dashboard
    • Cross-functional Backlog
    • Merged Merge Request Types
    • Billing and Subscription Management team dashboard
    • Cross-functional Backlog
    • Merged Merge Request Types
    • Provision team dashboard
    • Cross-functional Backlog
    • Merged Merge Request Types
    • Utilization team dashboard
    • Cross-functional Backlog
    • Merged Merge Request Types
    • Fulfillment Platform team dashboard
    • Cross-functional Backlog
    • Merged Merge Request Types
  • Estimation
  • Picking something to work on
  • Workflow
  • Approving and merging the work
  • Weekly async issue updates
  • Demos
  • Quality
  • Testing
  • Deployment
    • Revenue impacting changes
    • CustomersDot
    • Escalation process
    • Feature freeze
  • Incident management
    • Investigation
    • Declaring incidents
    • Grafana dashboards
  • Customer escalations
  • Retrospectives
    • Monthly retrospectives
      • Retrospective Contributions
      • Asynchronous Retrospective Synchronous Discussion
    • Iteration retrospectives
  • Project Cadence
• Working Groups and Cross-Functional Initiatives
• Fulfillment Social
  • Slack channel
  • Social calls
  • Team days
• Onboarding
• Performance indicators
• Maintainer ratios
  • CustomersDot
• Knowledge sharing
• Managers and direct reports
• Common links

Vision

A high performing team who provide our customers with a world-class buyer experience through the products we build. Our team strives to build an experience that is delightful, performant, trustworthy, and reliable.

Mission

Fulfillment focuses on improving our capabilities and metrics in the following areas:

• Fulfillment: Direction, Group Responsibilities, Fulfillment Development Team
• Purchase: Direction, Group Responsibilities, Backend Team, Frontend Team
• Provision: Direction, Group Responsibilities, Fullstack Team
• Utilization: Direction, Group Responsibilities, Team
• Fulfillment Platform: Direction, Group Responsibilities, Team

Direction

In addition to the Fulfillment Product Direction, the Fulfillment Development Sub-department strives to:

• Increase the reliability and availability of our Fulfillment infrastructure
• Make foundational technical improvements to the architecture and data models of the Fulfillment systems
• Improve the developer experience of Fulfillment engineers through better tooling and documentation

Team members

Fulfillment Sub-department People Leaders

Fulfillment:Purchase BE Team

Fulfillment:Purchase FE Team

Fulfillment:Provision Team

Fulfillment:Utilization BE Team

Fulfillment:Utilization FE Team

Fulfillment:Fulfillment Platform Team

Stable counterparts

Fulfillment Product Management

Fulfillment Quality Engineering

Fulfillment UX

Technical Writing

Fulfillment Security

Enterprise Applications

Sales Ops

Enterprise Sales

Commercial Sales

Channel Sales

Billing and Accounts Receivable

Customer Success

Support Engineering

Project management process

• In accordance with our GitLab values
• Transparently: nearly everything is public, we record/livestream meetings whenever possible
• We get a chance to work on the things we want to work on
• Everyone can contribute; no silos

SAFE

Working in SAFE manner at GitLab is everyone's responsibility. We along with our stable counterparts in Sales and Billing contribute to an area of the product that potentially could encounter sensitive or financial information, and could have an effect on the business as a whole. Therefore, it's important for Fulfillment team members to ensure that the SAFE epics, issues, videos, MRs, and other artifacts we produce are kept confidential.

On occasion, it may be prudent to include language like the following to the description of public issues where potentially SAFE discussions are happening.

This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Similarly, not all information should be included in the public handbook. Instead, use the private internal handbook for this SAFE information.

Please reference this documentation about promising features in future versions for more information.

Planning

We plan in monthly cycles in accordance with our Product Development Timeline. Release scope for an upcoming release should be finalized by the 1st.

On or around the 26th: Product meets with Engineering Managers for a preliminary issue review. Issues are tagged with a milestone and are estimated initially.

Planning Issues

• Purchase
• Provision
• Utilization

Intake Request

To request work to be added to the Fulfillment Roadmap, please open an issue by following this link and tag one of the Fulfillment Product Managers.

A Fulillment Product Manager will be assigned to review the request and start evaluating the scope and impact. This may take some time depending on team capacity. Once evaluated, the PM will:

1. Create a new Epic, capturing relevant details from the intake issue.
2. Add this new Epic to the Fulfillment roadmap.
3. Update the intake issue description with a link to the new epic.
4. Close the intake issue.

We strictly adhere to this Intake Request process to ensure we capture the full details of a request before actioning on it. Once our Product Managers receive this request, we'll work with the requestor to ensure we have a full understanding of the problem and requirements. After this, we will prioritize your request.

Prioritization

We follow the same prioritization guidelines as the rest of the Product team where security, data-loss, availability, and regression all come before feature work. Issues tend to flow from having no milestone, to being added to the backlog, to a directional milestone (e.g. Next 3-4 releases), and are finally assigned a specific milestone.

Each milestone typically follows the following allocation:

To prioritize the initiatives on our Roadmap, we follow the process detailed in Fulfillment's roadmap initatives prioritization. Initiatives are then stack-ranked to determine their priority on our Roadmap.

Self-Service Purchase team dashboard

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.

Merged Merge Request Types

(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.

Billing and Subscription Management team dashboard

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.

Merged Merge Request Types

(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.

Provision team dashboard

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.

Merged Merge Request Types

(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.

Utilization team dashboard

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.

Merged Merge Request Types

(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.

Fulfillment Platform team dashboard

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.

Merged Merge Request Types

(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.

Estimation

Before work can begin on an issue, we should estimate it first after a preliminary investigation. This is normally done in the monthly planning meeting.

In planning and estimation, we value velocity over predictability. The main goal of our planning and estimation is to focus on the MVC, uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. In general departments at GitLab aim for [70% predictability] but in the Fulfillment sub-department we aim for 80% predictability since our work is typically cross-functional and we need to be in lockstep with other departments.

• If an issue has many unknowns where it's unclear if it's a 1 or a 5, we will be cautious and estimate high (5).
• If an issue has many unknowns, we can break it into two issues. The first issue is for research, also referred to as a Spike, where we de-risk the unknowns and explore potential solutions. The second issue is for the implementation.
• If an initial estimate is incorrect and needs to be adjusted, we revise the estimate immediately and inform the Product Manager. The Product Manager and team will decide if a milestone commitment needs to be adjusted.

Estimation Template

The following is a guiding mental framework for engineers to consider when contributing to estimates on issues.

### Refinement / Weighting

**Ready for Development**: Yes/No

<!--
Yes/No

Is this issue sufficiently small enough, or could it be broken into smaller issues? If so, recommend how the issue could be broken up.

Is the issue clear and easy to understand?
-->

**Weight:** X

**Reasoning:**

<!--
Add some initial thoughts on how you might breakdown this issue. A bulleted list is fine.

This will likely require the code changes similar to the following:

- replace the hexdriver with a sonic screwdriver
- rewrite backups to magnetic tape
- send up semaphore flags to warn others

Links to previous example. Discussions on prior art. Notice examples of the simplicity/complexity in the proposed designs.
-->


**Iteration MR/Issues Count:** Y

Are there any opportunities to split the issue into smaller issues?
<!--
- 1 MR to update the driver worker
- 1 MR to update docs regarding mag tape backups

Let me draw your attention to the potential caveats.
-->

**Testing considerations:**
<!--
- Ensure that rotation speed of sonic screwdriver doesn't exceed rotational limits
-->

**Documentation required:** Y/N
<!--
- Do we need to add or change documentation for the issue?
-->

Picking something to work on

Engineers can find and open the milestone board for Fulfillment and begin working first on those with the deliverable label.

It's possible for engineers to pick any of the remaining issues for the milestone once the deliverables are done. If the engineer has no preference, they can choose the next available issue from the top.

Workflow

We generally follow the Product Development Flow:

1. workflow::problem validation - needs clarity on the problem to solve
2. workflow::design - needs a clear proposal (and mockups for any visual aspects)
3. workflow::solution validation - designs need to be evaluated by customers, and/or other GitLab team members for usability and feasibility
4. workflow::planning breakdown - needs a Weight estimate
5. workflow::scheduling - needs a milestone assignment
6. workflow::ready for development
7. workflow::in dev
8. workflow::in review
9. workflow::verification - code is in production and pending verification by the DRI engineer

Generally speaking, issues are in one of two states:

• Discovery/refinement: we're still answering questions that prevent us from starting development,
• Implementation: an issue is waiting for an engineer to work on it, or is actively being built.

Basecamp thinks about these stages in relation to the climb and descent of a hill.

While individual groups are free to use as many stages in the Product Development Flow workflow as they find useful, we should be somewhat prescriptive on how issues transition from discovery/refinement to implementation.

Quad-planning workflow

The SETs helps facilitate the quad-planning process. This is the participation of Product Management, Development, UX, and the Quality team which aims to bring test planning as a topic before the development of any feature.

We follow the Quad Planning process defined here.

Quad Planning Dashboard showcases the total Planned issues for Quad Planning vs the actual ones for each milestone.

Approving and merging the work

We have approval rules enabled, so every MR that targets staging or master needs at least one approval (different from the author/committer). MRs require the following:

• at least 2 different reviewers (typical)
• at least 1 approval
• a maintainer's review and merge

In addition to the approval rules, MRs may require additional reviews as suggested by the Danger bot:

1. Modifications to the DB require database reviewer and maintainer approval
2. Security-related issues (such as changes to authentication) require a Security review
3. Changes to the SFDC APIs require review by the Sales team
4. Changes to the Zuora APIs require review by the EntApps team

Weekly async issue updates

Every Friday, each engineer is expected to provide a quick async issue update by commenting on their assigned issues using the following template:

<!---
Please be sure to update the workflow labels of your issue to one of the following (that best describes the status)"
- ~"workflow::In dev"
- ~"workflow::In review"
- ~"workflow::verification"
- ~"workflow::blocked"
-->
### Async issue update

1. Please provide a quick summary of the current status (one sentence)
    -
1. How confident are you that this will make it to the current milestone?
    - [ ] Not confident
    - [ ] Slightly confident
    - [ ] Very confident
1. Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
    - [ ] Yes
    - [ ] No
1. Were expectations met from a previous update? If not, please explain why.
    - [ ] Yes
    - [ ] No, ___
1. Are the related issues up to date? Please link any missing issues in the epic that could be linked to this issue
    - [ ] Yes
    - [ ] No

We do this to encourage our team to be more async in collaboration and to allow the community and other team members to know the progress of issues that we are actively working on.

Demos

Some work can take a few milestones to complete. Together with regular async issue updates, it is useful to set demos. Advantages are:

• shorten the feedback cycle
• increase visibility of the work
• improve communication of work and progress

Note that providing demos and recordings is already encouraged to ease the review process in MRs.

For this purpose, a YouTube playlist has been created: Fulfillment Demos (some content is internal only). To upload your demos, you can follow the process described here. Once the video is created, link it to the Fulfillment Demos playlist. Consider adding the following info in the description:

• A link to the Epic/Issue
• A link to the MR (if any)
• The name and link to profile of who uploaded it (optional)

Here's an example (internal only)

Quality

GitLab's Quality is everyone's responsibility. The SETs embedded within Fulfillment section follow the Quality Engineering Departments's principles primarily to ensure that everyone is aware of product quality.

Testing

The CustomersDot has different types of tests running:

1. Linting and rubocop jobs
2. Unit tests (specs, these could be of many types, such as controller specs)
3. Integration tests (specs, mocking external calls)
4. Frontend tests
5. E2E integration tests via Watir

We also have a flag VCR that mocks external calls to Zuora by default. We have a daily pipeline that runs at 9AM UTC with the flag set so the API calls hit the Zuora sandbox and we are notified of any failure (due to potential API changes).

Any test failure is notified to #s_fulfillment_status including a link to the pipeline. Pipeline failures will prevent deployments to staging and production.

Deployment

Revenue impacting changes

Fulfillment is unique in Engineering because our changes can directly impact revenue. Changes which impact revenue or are otherwise high risk may require broader scrutiny including input from teams outside of Fulfillment. PM is the DRI on these decisions, taking input from stakeholders including Sales, Enterprise Applications, Marketing, Finance, and Customer Support.

We aspire to be as iterative as possible including even when a change potentially poses high risk.

Below are examples of changes that can be high risk because they can require coordination across many teams:

• Pricing changes
• Billing changes
• Launching a new paid feature
• Deprecating an existing paid feature
• Changes to terms of service and related contract changes
• Changes to the way the consumption of resources is calculated or displayed (e.g., user counts, CI minutes)

Below are changes that can often be low risk:

• Backend enhancements that are not yet used by the frontend
• Frontend and backend Enhancements that are behind a feature flag
• Frontend enhancements that are not behind a feature flag, but are labeled as "beta" or "experimental"

The following processes should be followed for high-risk changes:

• Update feature documentation of the new/updated behavior and share with relevant stakeholders
• Use confidential issues for these changes
• Release changes under a feature flag so this can be enabled on the release date
• Create a rollout issue for the release date and make sure all parties are informed about the process. Example
• Consider enabling this to a subset of customers so changes can be tested iteratively
• Use the regular MR process even if the issue is confidential until confidential MRs are improved (1, 2)

CustomersDot

We use CD (Continuous Deployment) for CustomersDot and a MR goes through the following stages once it gets merged into the staging branch:

If something goes wrong at the Verification stage, we could create an issue with the label production::blocker, which will prevent deployment to production. The issue cannot be confidential.

For MRs with significant changes, we should consider using feature flags or create an issue with the production::blocker label to pause deployment and a allow for longer testing.

Escalation process

In most cases an MR should follow the standard process of review, maintainer review, merge, and deployment as outlined above. When production is broken:

1. First determine whether the Rapid Engineering Response process can be followed. This will depend on availability and how critical the situation is.
2. The three hour wait between Staging and Production auto deploy can be bypassed with a manual deployment by a Maintainer.
3. When there are no project maintainers available (CustomersDot) an additional GitLab Team Member with Maintainer access can be asked to assist.

In these cases please ensure:

1. There is an issue describing the reasons for the escalation, as per the Rapid Engineering Response. Consider '@'mentioning the relevant Growth/Fulfillment teams.
2. The change is announced on the #s_fulfillment channel.

Feature freeze

The feature freeze for Fulfillment occurs at the same time as the rest of the company, normally around the 18th.

(*) feature freeze may vary according to the auto-deploy document.

Any issues not merged on the current milestone post feature freeze, will need to be moved to the next one (priority may also change for those).

Incident management

On going Fulfillment Platform work will provide greater observability to all of the Fulfillment systems. In the meantime, however, we have some tools like CustomersDot health that post to #s_fulfillment_status in Slack. On occasion, there are reports of systemic critical trouble like a liveliness probe check failure, invalid SSL certificate, or other application errors. Look to the following sub-sections below for ways that you can contribute to error resolution.

See this handbook page for more information on GitLab Monitoring and Incident Management.

Investigation

• You can visit our health-check instance here. You can find the login credentials in the Subscription portal vault in 1Password. You will see services for both CustomersDot production and staging.
• Exceptions for CustomersDot are captured in Sentry.
• You can query logs in Kibana / Elasticsearch. Use this link to read more on using kibana at GitLab)
• Grafana has some triage dashboards that are generally applicable for GitLab, but do not contain specific observability metrics for Fulfillment systems until the InfraDev work is complete.
• Blackbox probes reporting production availability alerts are reported to #production in Slack

Declaring incidents

Raising an incident is always an option if you need immediate attention on a blocking problem.

Examples of blocking problems include:

• Expired certificate causing interrupted service with staging or test environments
• ??

Critical problems like a production outage should be raised quickly. You can check #incident_management before raising an incident.

• CustomersDot outage
• Failed CustomersDot deploy
• ??

Grafana dashboards

These dashboards are designed to give an insight, to everyone working in a feature category, into how our code operates at GitLab.com scale.

• Provision
• Purchase
• Utilization

Customer escalations

If there is a licensing issue (from support or sales) that requires escalation to product management or engineering, please create an issue via the process documented on the support handbook page under Assistance with License Issue. Please do this instead of escalating in Slack or other methods.

Fulfillment leaders in product management and engineering will subscribe to the License Issue High ARR label so they can be aware of them when they are created. This can be done in via a label search and then clicking on 'subscribe' for the `License Issue High ARR' label.

The Program Manager, Cloud Licensing (currently Wayne Haber) will be primarily responsible for making the e-group aware in #e-group of licensing issues that may have a high ARR impact. The backup for the Program Manager, Cloud Licensing will be the Group Product Manager, Fulfillment (currently Jerome Ng).

Retrospectives

Monthly retrospectives

After the 8th, the Fulfillment team conducts an asynchronous retrospective. You can find current and past retrospectives for Fulfillment in https://gitlab.com/gl-retrospectives/fulfillment/issues/.

Retrospective Contributions

Everyone is encouraged to participate in asynchronous retrospective issues. This is a safe space for team member feedback. You are welcome, however, to bring your comments and concerns to the synchronous retrospective discussion or share them with your manager or other department leadership as well. We follow this guidance to produce an efficient and safe retrospective.

Some things to keep in mind:

• Items shared do not have to be monumental successes or failures. Consider including even small items in the “what went well” and “what didn't go so well” sections of the retrospective issue.
• Use a team specific thread to share items that may be feel less relevant to the entire department.
• Pull from the "wins" or "challenges" team sync agenda items for inspiration.
• Find the limits of your computer, and keep the current retrospective issue open throughout the milestone.

Asynchronous Retrospective Synchronous Discussion

Approximately one week after the commentary period closes (on the 26th of the following month) for the async retrospective, we host a synchronous meeting to discuss next steps, action items, and improvements to our processes. This meeting can be facilitated by EMs and ICs alike. We attempt to be timezone inclusive by scheduling the meeting on a rotation between times that are APAC, AMER, and EMEA friendly. This meeting is recorded and shared for the benefit of everyone in Fulfillment.

Iteration retrospectives

There are several resources at GitLab for improving our iteration capability:

• engineering iteration documentation
• product iteration documentation
• self-guided iteration training issue
• iteration office hours
• milestone retrospectives
• iteration retrospectives

Agile software development practices uses the phrase Iteration Retrospective to describe what we perform during our Milestone Retrospective. While the Milestone Retrospective is essential in understanding how we can improve, it does have a broad focus across multiple teams. It's a safe space where everyone can contribute through reflection on what we can continue, what we can correct, and what we can improve.

An Iteration Retrospective, in the GitLab values sense that we're using here, is more focused on a specific example (or few examples) of a successful or unsuccessful iteration attempt. That is, an Issue, Epic, or merge request that we can examine deeply to understand what we can do differently in the future to be more iterative and efficient. These retrospectives will provide a growth opportunity to work on developing an iterative mindset - build it, then build it better.

Each group should perform their own Iteration Retrospective, but share as transparently as possible to help fellow teammates and other teams learn from your investigation.

Frequency

Iteration Retrospectives should be conducted quarterly.

Preparation

Engineering Manager(s) or Other team members should review current or previous milestones to find a good, challenging candidate issue for the Iteration Retrospective. Choose one (or two if related) from the suggestions, then create a retrospective issue.

Review these rules for an effective retrospective.

Participation

Everyone can and should contribute asynchronously to the discussion. Present your ideas on alternative methods or mechanisms to break down the problem stated in chosen issue for review. If the problem breakdown was fine, suggestions about process or other refinements are also welcome.

Don't belabor the point, participation should be timeboxed to 1 week. A 1 week due date quick action is available in the template below.

Consider handbook updates, process changes, and bubbling up information from your conclusions after this retrospective.

Template (optional)

Iteration is one of six GitLab Values, but also really difficult. By focusing how we have iterated well in the past and how we have not will help us iterate faster. Please contribute the following [Iteration Retrospective](#link-to-handbook-page).

## Summary

<!--
Include a brief summary of the issue. Consider including key outcomes, significant changes, and impact.
-->

`Summary of the Issue`

## Details

<!--
Complete the following details when creating the issue.
-->

- Did the team meet the iteration goals? Why or why not?
- How many MRs were created to complete the Iteration?
- What were the Days to Merge for the MRs related to the this issue?
- Are there successes or opportunities for improvement with respect to collaboration with peers or stable counterparts?
- Could the original issue have been broken down into smaller components?
- Could the MR(s) have been broken down into smaller components?

## Tasks

**Read**

- [Iteration Value](https://about.gitlab.com/handbook/values/#iteration)
- [Engineering Iteration](https://about.gitlab.com/handbook/engineering/workflow/iteration/)
- [Why iteration helps increase the merge request rate](https://about.gitlab.com/blog/2020/05/06/observations-on-how-to-iterate-faster/)

**Watch**

- [Interview about iteration in engineering with Christopher and Sid](https://www.youtube.com/watch?v=tPTweQlBS54)
- [Iteration Office Hours with CEO](https://www.youtube.com/watch?v=liI2RKqh-KA)


**Contribute**

In the threads below consider the following:

- Why was it (un)successful? If successful, how did it meet the definition of an [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc)?
- How did the example not meet the definition of an [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc)? In what ways could you have iterated differently? List specific examples.
- Identify areas of improvement for the team that can be incorporated into our processes and workflows.

Follow [these rules](https://about.gitlab.com/handbook/engineering/management/group-retrospectives/) for an effective retrospective.

Check your name off the completed list when all tasks are complete.

**Completed**

<!--
When creating this issue replace the person placeholders with teamembers and select stable counterparts as you see fit.
-->

- [ ] Person
- [ ] Person
- [ ] Person
- [ ] Person

**Next Steps**

- [ ] Engineering Manager to update your team's handbook page with ideas and improvements you've incorporated to improve iteration.

## Thread Prompts

<!--
Use these prompts or similar to start conversation threads.
-->

1. What aspects of the Issue/Epic and resulting MR(s) were very good/bad examples of Iteration and why?
1. Does anyone have alternative ideas for how this work could have been broken down?
1. Is there anything that we can change in our processes or the way we work that could improve our iteration as a team?


/due in 1 week
/label ~"Iteration Retrospective"

Project Cadence

This table lists recurring activities that are part of our Project Management Process. Having a well defined cadence makes it simple for our team to understand what activities are happening and when they happen. The listed activities closely follows our company cadence. Use this spreadsheet to edit this markdown table.

Working Groups and Cross-Functional Initiatives

This table lists recurring activities that are part of working groups and cross-functional initiatives. Use this spreadsheet to edit this markdown table.

Fulfillment Social

We like to staying connected and up-to-date with our team outside of our daily work.

Slack channel

We use the private #s_fulfillment_social channel to chat and socialize.

Social calls

We hold optional synchronous social meetings weekly where we chat about anything outside work. These meetings happen each Wednesday alternating between 10:00am UTC (EMEA) and 4:00pm (AMER). Check the Fulfillment Google calendar for more information.

Team days

Every quarter, we set aside our work and host a virtual get-together to socialize with our fellow teammates. Our upcoming and past team days and listed in the Fulfillment Meta Project using the Team Day label.

Onboarding

To be added

Performance indicators

See the Fulfillment Section Performance Indicators as well as the Centralized Engineering Dashboards.

Maintainer ratios

CustomersDot

We attempt to have an ideal Engineer to Maintainer Ratio of 1:1 for both backend and frontend effort for our primary application, CustomersDot. The active list of maintainers can be found on the Engineering Projects page.

Some considerations that differ from other maintainer ratios:

1. Fulfillment maintainer ratios are Maintainers vs Reviewers
2. GitLab maintainer ratios are Maintainers vs Maintainers + Reviewers
3. GitLab maintainer ratios do not count full-stack engineers properly (Fulfillment one does)

Knowledge sharing

• Generating test licenses, adding them to GitLab, and then finding and removing them from the GitLab database
  • Document with notes
  • Recording
• New Integration with Sentry
  • Document with notes
  • Recording
• Intro to FE GraphQL at GitLab with Vue Apollo
  • Slides
  • Recording
• CustomersDot Resource Video Library
• Zuora University Select Topics
• Confidential Issue Git Pre-push Hook to prevent any accidental push to any non-Gitlab Security remote whenever a developer works on a confidential issue. Reference: How to customize Git Hooks.

Managers and direct reports

This table lists recurring activities between managers and their reports. Most of these activities are also listed on our Leadership and People Group pages. Use this spreadsheet to edit this markdown table.

Common links

• Product Vision
• Fulfillment section
• All open Fulfillment epics
• Issue Tracker
• Slack channel #s_fulfillment
• Daily standup channel #s_fulfillment_daily
• Team calendar
• Fulfillment technical debt status