This is a specialty within the Product Designer job family, not a separate job family. CQ designers carry the full foundation of the Product Designer role and add the specialized work of quality across the shipped product: identifying design failures, fixing what they can, tracing problems to their root cause, and addressing those causes so the same problems stop recurring.
The motion is find, fix, and prevent. CQ designers work across the entire GitLab product. Their job is not to own a surface but to move across all of them, spotting where the experience breaks and doing something about it.
Fixing an instance is the entry point, not the goal. The real work is understanding why it shipped that way and changing the conditions that allowed it. That can mean creating a merge request to update documentation, proposing a change to an automated process, or opening an issue to start a cross-functional conversation. The path depends on the scope of the problem. CQ designers know which path to take and have the relationships to move things forward regardless.
Because root causes often live in how engineering and design work together, Craft Quotient designers maintain active working relationships with engineering partners across the product. Influence here is not incidental. It is part of the job.
## Base Requirements For All Roles
- Ability to use GitLab.
- Several years of professional experience in product design, with a strong track record of quality-focused work across complex product surfaces.
- Demonstrated ability to identify design failures in shipped product, distinguish symptoms from causes, and develop solutions that address the underlying problem rather than the visible instance.
- Enough technical fluency to participate in engineering conversations about root cause, propose changes to documentation or automated processes, and create or review merge requests when the fix warrants it.
- Experience building working relationships with engineering partners and using those relationships to move design recommendations forward without a formal mandate to do so.
- Strong communication skills across design and engineering audiences. Craft Quotient designers make quality arguments to people who think in code as often as to people who think in pixels.
- Comfort working across many product areas simultaneously without a dedicated product manager or engineering counterpart. The work does not wait for a trio to form.
- Alignment with GitLab's values and a demonstrated commitment to working in accordance with them.
- Strong bias for action and ability to develop daily priorities to achieve goals (manager of one).
- Proficiency in the English language, both written and verbal, sufficient for success in a remote and largely asynchronous work environment.
- Working knowledge of GitLab workflows (issues, epics, merge requests, CI/CD) and comfort operating within a GitLab-first environment.
## Levels
The Craft Quotient specialty has four designations. Staff owns the execution. Principal owns the systemic quality work. Distinguished sets the intellectual standard. Lead owns how the practice operates.
### Staff Product Designer, Craft Quotient
A Staff CQ designer is the execution foundation of the practice. They move across the GitLab product with a trained eye for where the experience fails users, address what they can directly, and trace problems to their root cause. They bring the rigor of someone who is not just fixing what is broken but asking why it broke.
#### Responsibilities
-**Quality identification:** Move across the GitLab product with a trained eye for where the experience fails users. Distinguish between isolated instances and symptoms of a deeper problem. Document findings with enough specificity that the root cause is legible to engineering and design partners.
-**Direct remediation:** Fix problems that are within reach. That can mean creating a merge request to update documentation, proposing a change to an automated check, or producing a design solution for a product group to implement. Match the approach to the scope of the problem.
-**Root cause analysis:** Do not stop at the fix. Trace each problem to its origin and develop a clear account of what allowed it to ship. That account is the input to preventing recurrence.
-**Cross-functional relationships:** Build and maintain working relationships with engineering partners across the product. Use those relationships to move recommendations forward, open conversations, and participate in the process of resolution rather than handing off a report.
-**Research collaboration:** Build a working relationship with Experience Research partners. CQ findings and research findings are different signals pointing at the same product. Knowing when to connect them makes both stronger.
-**Quality signal:** Document findings in a way that feeds the practice's shared quality signal. Individual findings are more valuable when they accumulate into a pattern someone can act on.
-**Knowledge sharing:** Participate in knowledge sharing sessions and contribute to resources that help designers across Upstream Studios make direct contributions to the product.
-**Upstream contribution:** Bring findings and patterns to Design Strategy's shared working sessions. Quality problems that surface at the instance level often have implications for the whole team's work.
#### Requirements
A Staff CQ designer is expected to meet the base requirements and execute their responsibilities with the independence and technical engagement needed to move a finding from identification through resolution without waiting for someone else to own the next step.
### Principal Product Designer, Craft Quotient
A Principal CQ designer owns the systemic quality work. They carry a portfolio of quality problems that are larger in scope, span multiple product areas, or require cross-functional alignment to resolve. Their focus is on patterns and prevention, not just instances. They contribute to how the practice works but do not own it.
#### Responsibilities
-**Systemic quality leadership:** Lead quality work that is larger in scope or more organizationally complex. This includes patterns that span multiple product areas, root causes that live in shared engineering processes, and problems that require cross-functional alignment to address.
-**Pattern identification:** See across individual findings and name the patterns that connect them. A Principal CQ designer is not just identifying problems; they are developing the diagnostic language that helps others see them too.
-**Preventive criteria:** Translate root cause analysis into criteria, guidance, or process changes that prevent the pattern from recurring. That might mean contributing to Pajamas, updating engineering documentation, or proposing changes to how design and engineering review work before it ships.
-**Engineering influence:** Build the relationships and credibility needed to influence how engineering teams work on specific quality problems. Some root causes live in automation, in review processes, or in how requirements are handed off. Addressing those requires trust earned over time.
-**Research collaboration:** Work with Experience Research partners to connect CQ findings with user research signal. Know when the two should inform each other and broker those conversations.
-**Quality signal contribution:** Contribute findings to the practice's shared quality signal in a way that accumulates into a clear picture of systemic gaps, not just a list of closed issues.
-**Knowledge sharing:** Actively participate in knowledge sharing with designers across Upstream Studios. A Principal CQ designer has developed enough expertise in direct product contribution to be a credible resource for others.
#### Requirements
A Principal CQ designer is expected to meet the base requirements and execute their responsibilities while raising the quality bar across the product and building the systemic conditions that make recurring problems less likely.
A Distinguished CQ designer represents the highest level of individual contribution in the practice. Their quality work operates at a scope and depth that shapes how GitLab thinks about product quality as a company. They are not running the practice. They are setting the intellectual standard the practice aspires to.
#### Responsibilities
-**Company-level quality strategy:** Define where the product's most consequential quality gaps are and make the case for addressing them at the executive level. Where Lead builds the relationships that make the practice move, Distinguished builds the argument that makes the investment worthwhile.
-**Engineering partnership at scale:** Partner with engineering leadership to influence how teams ship, not just what they fix. At the Distinguished level, the engineering relationship is in service of the work, not the practice. The goal is influencing how specific quality problems get addressed at a depth no other level can reach.
-**Quality thinking:** Help the broader design and engineering org understand how to think about quality, not just how to fix problems. A Distinguished designer's perspective on what makes something a systemic failure versus an isolated instance is worth sharing. Make it accessible.
-**Discipline definition:** Define what excellence looks like across the Craft Quotient specialty at every level of the ladder. The Distinguished level holds the intellectual standard for the entire practice.
-**Industry presence:** Contribute to thinking about design quality at the industry level through writing, speaking, or participation in relevant communities. The approach CQ takes to root cause analysis and preventive quality work is not common. A Distinguished designer helps the field understand what it makes possible.
#### Requirements
A Distinguished CQ designer is expected to meet the base requirements and execute their responsibilities while defining what quality means for GitLab and raising the intellectual ceiling of the practice through the depth and consequence of their individual work.
### Lead Product Designer, Craft Quotient
The Lead is responsible for how Craft Quotient operates as a practice. The orientation is different from the other IC levels. The Lead sets the methodology, owns the engineering relationships at a practice level, develops the ICs, and represents CQ to Design Strategy leadership. Their focus is on making the practice effective, not on accumulating the most findings.
#### Responsibilities
-**Practice methodology:** Define how CQ identifies, prioritizes, and addresses quality problems across the product. Set the bar for what root cause analysis looks like and how findings are communicated to engineering and design partners. The methodology is the practice's most durable output.
-**Engineering relationships at scale:** Own the engineering relationships that make CQ's influence possible. At the Lead level, those relationships are not in service of a specific fix; they are the infrastructure that allows the practice to move anything. Build them before they are needed.
-**Quality signal:** Own the quality signal the practice produces and ensure it reaches design and engineering leadership in a form they can act on. The signal is only useful if it drives decisions, not just awareness.
-**Product quality horizon:** Track where the product is heading and where quality problems are likely to emerge before they reach users. The Lead should be positioned ahead of quality failures, not only behind them.
-**Research partnership:** Build the structural relationship between CQ and Experience Research so that quality findings and user insight inform each other consistently. At the Lead level, that relationship is an organizational asset, not a personal one.
-**Knowledge sharing infrastructure:** Build the resources, guidance, and culture that make direct product contribution a capability across the broader design org. The goal is making it normal for designers to fix what they find, not keeping that capability inside the practice.
-**Practice representation:** Represent Craft Quotient in Design Strategy leadership conversations. When decisions are being made about where to invest, what to prioritize, or how the broader org works, the Lead ensures CQ's perspective and findings are present and specific.
#### Requirements
A Lead CQ designer is expected to meet the base requirements and demonstrate the practice ownership, engineering credibility, and people development capability needed to make Craft Quotient effective as a function, not just productive as a collection of individuals.
## Performance Indicators
- Number and severity of quality issues identified, addressed, and closed across the product
- Depth and accuracy of root cause analysis, as assessed by design and engineering partners
- Evidence that preventive criteria or process changes have reduced recurrence of identified patterns
- Strength of working relationships with engineering partners, including their reported confidence in CQ as a collaborative function
- Quality and reach of the quality signal produced, including whether it is informing decisions at the design and engineering leadership level
- Evidence of collaboration with Experience Research, including how consistently CQ findings and research signal are informing each other
- Adoption of direct contribution skills across the broader design org, including participation in knowledge sharing sessions and resources
- Practice maturity over time, including how consistently the team moves from instance to pattern to prevention
- Designer-reported confidence in quality identification methods, root cause analysis, and cross-functional influence
Candidates for this position can expect the hiring process to follow the order below, although it can change depending on calendar availability. Please keep in mind that candidates can be declined from the position at any stage of the process.
### Screening Call
Selected candidates will be invited to schedule a 30-minute screening call with a member of our hiring team. In this call, we will discuss your experience with quality-focused design work, understand what draws you to Design Strategy and the CQ practice, talk through your approach to identifying root causes and moving recommendations through engineering, discuss your compensation expectations and reasons for wanting to join GitLab, and answer any questions you have.
### Interview Process
1.**Interview with a peer (1 hour):** This conversation focuses on how you approach quality work: how you distinguish an instance from a pattern, how you trace a problem to its root cause, and how you decide which path to take when moving a recommendation forward. Come prepared to walk through a specific quality problem you identified and addressed, including your analysis, what you did, and what changed as a result. Candidates for the Lead role should also be prepared to discuss how they have set up systems, built cross-functional relationships, and developed other designers.
1.**Interview with the Hiring Manager (1 hour):** This interview explores your approach to working across a large product without a dedicated team structure, your experience building relationships with engineering partners, and how you have influenced how teams work rather than just what they fix.
1.**Interview with an Engineering partner (30 minutes):** This conversation assesses how you build credibility with engineering and how you have navigated the process of moving a design recommendation into an engineering resolution. The interviewer will want to understand how you communicate across the design and engineering boundary and what you have learned about what makes that collaboration effective.
1.**Interview with the Chief Design Officer (50 minutes):** This conversation focuses on your understanding of what Design Strategy is trying to do and what you would bring to the CQ practice. The interviewer will want to understand how you think about quality at a systemic level and where you see the most consequential opportunities to raise the bar.
