Decision-making process: Clarifying roles and responsibilities

In order to increase visibility and consistency of the decision making process within the groups within Create, this section aims at clarifying expectations and best practices.

Goals

• Respect ownership & process
• Transparent communication to others
• Encourage opinionated collaboration for efficiency

Values Reminder

These are values extracted from our current Values framework that have assisted in evolving and documenting the practice.

DRI table

Sources:

• Cross Functional Prioritization - PM:Features, EM:Maintenance and Bugs
• Severity DRI per bug type
• Priority DRI

Practice

Issues/Triage

Each decision taken around an issue will have a formal DRI (see DRI Table) that will always have the last word on said decision. Team members must always push the decision to the right DRI whether about Severity or Priority.

When someone other than the strict DRI has high confidence or strong suggestion on an outcome, can and should apply the changes to the issue, write a comment (outcome needs to be in a public comment, discussions may happen in internal notes) documenting the reasoning and ensuring the DRI is pinged at the same moment via @mention (and optionally via Slack, too). The DRI needs to give an explicit reaction through a comment or a clearly positive emoji reaction.

✅ Do: Leave a comment in an issue pinging the DRIs while at the same time triaging said issue by setting severity::*, priority::* and milestone.

❌ Don’t: Triage an issue by setting severity::*, priority::* and milestone without pinging the DRIs for each task.

Data as primary piece

On all forms of decision-making, from triaging to assessing rollouts, everyone on the team should strive to base the outcomes on data. This means gathering relevant metrics or research insights, analyzing trends, and using evidence to support our choices rather than relying solely on intuition or assumptions. By grounding our decisions in concrete information, we can make more objective assessments, reduce bias, and create a shared foundation for discussion that helps the team move forward with confidence and alignment.

Collaborating Across Teams on Issues

Issues may require input from another team or, upon investigation, be identified as another team’s responsibility to resolve.

When seeking input from another team: The DRI or assigned team member should @mention the relevant DRI from the other team in a comment and, if necessary, follow up via Slack to ensure visibility. Discussions and negotiations may happen within an internal note, guaranteeing that the outcome lands in a public note for visibility of customers.

When transferring responsibility to another team: The DRI should:

1. Update the issue labels to reflect the appropriate team
2. @mention the receiving team’s DRI in a comment explaining the rationale for reassignment
3. Notify the team via their Slack channel (optional)

For cross-team dependencies: If an issue impacts your team’s area of responsibility but requires implementation by another team, maintain periodic follow-up to track progress and understand the timeline for resolution.

Merge Requests

Code Review Guidelines need to be followed and any overrides need to be explicitly approved in the Merge Request by the Engineering Manager of the team of the author.

Launches of Feature Flag rollouts

Any decisions about launches or Feature Flag Rollouts need to be approved by both the Product Manager, Product Designer and Engineering Manager.

Applies to: internal team members, gitlab.com and defaulting (Self Managed/Dedicated).

Doesn’t apply to: turning on for specific team members for the purposes of testing and developing the feature.

Any other type of decision

Domain of expertise should apply by default.

Avoiding single-points-of-failure

Whenever a DRI is out-of-office, if the decision is time-sensitive or critical to customers, the team should do their best to contact the next person in the chain of command.

For non-critical or time-sensitive decisions, team members are encouraged to be proactive, make the decision tagging the DRI and ensuring they review it upon their return.

View page source - Edit this page - please contribute.