GitLab PM onboarding first 90 days what to expect 2026

GitLab PM Onboarding First 90 Days What to Expect 2026

TL;DR

The first 90 days as a Product Manager at GitLab are not about execution—they’re about calibration. You’ll spend the first 30 days listening, the next 30 aligning, and the final 30 proving judgment, not velocity. The real evaluation isn’t shipped features; it’s whether you’ve correctly interpreted GitLab’s asynchronous culture, written your first MRs in the handbook, and surfaced a prioritization call that survived RFC scrutiny. Most PMs underestimate how little they need to deliver and how much they need to absorb.

Who This Is For

This is for newly hired or soon-to-be-hired Product Managers at GitLab, particularly those transitioning from synchronous, meeting-heavy tech cultures. It’s not for ICs or engineering leads. If your offer starts in Q1 2026 and you’re pre-onboarding, your success hinges on understanding that GitLab doesn’t measure ramp-up by features shipped but by documentation produced, decisions written, and conflicts surfaced in the open. Your manager won’t tell you this—they expect you to infer it.

What does the first 30 days look like for a new PM at GitLab?

The first 30 days are a listening tour disguised as onboarding. You won’t have a product roadmap, sprint goals, or team deliverables. Your only KPI is visibility: how many handbook pages you’ve read, how many RFCs you’ve commented on, and how many retrospective summaries you’ve silently reviewed.

In Q2 2025, a new PM joined the DevOps Orchestration group and shipped a small workflow improvement by day 14. The hiring manager flagged it in the 30-day review: “You solved a problem no one documented. That’s the opposite of GitLab values.” The issue wasn’t the work—it was the assumption that speed mattered. GitLab’s culture rewards deliberate inaction when context is missing.

Not output, but input velocity defines early success. Not shipping, but sense-making. Not ownership, but stewardship. You’re not there to fix things—you’re there to understand why they’re broken in writing.

You’ll be assigned a buddy, not a mentor. The distinction matters: mentors advise, buddies correct your merge request formatting. You’ll attend zero stand-ups unless you create the agenda doc 48 hours in advance. Meetings are artifacts, not events.

By day 30, you must submit a self-assessment MR to the handbook, tagging your manager. It should contain:

5 observed process gaps (not problems—gaps between policy and practice)
3 proposed documentation updates
1 cross-functional dependency you now understand

No feature plans. No OKRs. Just synthesis. Fail this, and your 90-day review becomes a formality.

How does GitLab measure PM performance in the first 90 days?

GitLab measures PM performance in the first 90 days by written output, not shipped code or roadmap progress. Your contributions to the handbook, RFCs, and post-incident reviews are scored against clarity, consistency with values, and conflict transparency.

In a 2025 hiring committee debrief, a PM was recommended for termination at day 68 despite shipping two small UI improvements. The verdict: “All contributions were undocumented, no MRs opened, decisions made in DMs.” The engineering lead added: “We don’t know what they were thinking, so we assume it wasn’t aligned.”

Not activity, but auditability matters. Not initiative, but traceability. Not results, but process fidelity.

Your manager uses a lightweight rubric across three dimensions:

Documentation rigor: % of decisions captured in handbook or RFC
Conflict surfacing: number of disagreements you initiated in writing
Asynchronous fluency: average response latency under 24 hours on merge requests

Each is scored weekly. A score below 3/5 on any for two consecutive weeks triggers a performance plan.

You are not evaluated on user feedback, NPS, or feature adoption in the first 90 days. Those come later. Early performance is about whether you’re operating in the open. If your work only exists in your head or Slack DMs, it doesn’t exist.

What tools and workflows will I use daily as a GitLab PM?

You’ll use GitLab.com, Slack, and Zoom—nothing else. Not Figma, not Jira, not Notion. Product requirements live in Markdown files in group repositories. Roadmaps are GitLab issues with weight, epic links, and milestone assignments.

Your daily workflow starts with a saved issue search: “assignee:@me updated:>24h”. You respond to every item in writing, even if it’s “acknowledged, no action.” Silence is interpreted as disengagement.

Every decision above minor priority requires an RFC in the /product directory. You draft it, assign reviewers, and let comments accumulate for 72 hours before resolving. No meetings to discuss it—just edits and approvals.

In a Q3 2025 incident, a PM tried to unblock a frontend dependency via Zoom call. The engineering manager rejected the solution in writing: “Process bypassed. RFC required for cross-group changes.” The PM hadn’t broken rules—they’d just assumed speed was valued. It wasn’t.

Not tools, but workflow integrity defines competence. Not convenience, but consistency. Not collaboration, but codification.

You’ll write merge requests for everything: meeting notes, retrospective actions, even onboarding feedback. Your commit messages follow Conventional Commits. Your descriptions cite handbook sections. Your tags map to value streams.

Failure to use the toolchain as designed isn’t excused as “learning curve.” It’s seen as cultural misalignment.

How do I build credibility with engineers and designers in the first 60 days?

You build credibility at GitLab not by leading discussions, but by stepping back and letting others own the narrative. Engineers and designers trust PMs who amplify, not dominate.

In a 2024 team retrospective, a senior engineer wrote: “New PM kept proposing solutions in issue threads. We had to close 3 MRs because they duplicated existing efforts. We don’t need more ideas—we need fewer bad ones.” The PM was re-assigned within 45 days.

The correct path:

First, read every open issue in your group for the past 90 days
Identify recurring themes, not solutions
Post a synthesis doc titled “Patterns in CI/CD Feedback, Nov 2025 – Jan 2026”
Tag engineers: “Am I interpreting these correctly?”

Not problem-solving, but pattern-spotting. Not decision-making, but framing. Not ownership, but invitation.

Designers respond to documentation, not whiteboarding. In 2025, a PM scheduled a Miro session to align on UX flows. Only two attendees showed. The design lead commented: “We already have a design system. If updates are needed, file an issue.”

Credibility comes from restraint. From citing, not creating. From asking, not assuming.

By day 60, you should have:

3+ issues where you surfaced context but deferred solutioning
1+ design system contribution (even a typo fix)
2+ engineering RFCs where you requested clarification, not changes

No credit for being “helpful.” Only for being precise.

What cultural norms are non-negotiable for PMs at GitLab?

The non-negotiable cultural norms for PMs at GitLab are asynchronous default, written-first communication, and public-by-default documentation. If you violate these, no amount of product success will save your standing.

In a 2025 HC meeting, a PM shipped a top-priority feature two weeks early. The engineering director opposed promotion: “All key decisions were made in two private DM threads. We can’t replicate that behavior.” The case was closed: “Results don’t override values.”

Not delivery, but process adherence is mandatory. Not outcomes, but transparency. Not impact, but openness.

You must:

Write everything: meeting notes, decisions, disagreements
Default to public channels, not DMs
Use merge requests for feedback, not comments
Allow 72 hours for RFC review without escalation

If you schedule a last-minute Zoom to “unblock” a discussion, you’re signaling you don’t trust the system. That’s a cultural red flag.

One manager told their PM: “I don’t care if you’re right. I care that you’re visible.” At GitLab, invisible work is failed work.

The handbook isn’t a reference—it’s the product. If it’s wrong, you fix it. If it’s unclear, you rewrite it. Silence is complicity.

Preparation Checklist

Review the entire Product Department Handbook section, including archived RFCs from the past year
Set up your GitLab.com environment: 2FA, saved searches, notification preferences
Schedule a 1:1 with your manager to confirm your 30/60/90-day expectations doc
Identify and read all active epics in your group with milestone tags
Draft a template for your weekly update MR (to be submitted every Friday)
Work through a structured preparation system (the PM Interview Playbook covers GitLab’s written-first evaluation framework with real debrief examples)
Disable Slack desktop notifications—rely on email and GitLab issue alerts instead

Mistakes to Avoid

BAD: Scheduling a team kickoff meeting on day 3 to “align on vision.”

GOOD: Publishing a “Welcome & Listening Tour” MR in the group handbook, listing questions and inviting written responses over 10 days.

BAD: Proposing a new workflow in a Slack thread after observing a “bottleneck.”

GOOD: Filing an issue titled “Observed Delay in Merge Train Processing” with timestamps, screenshots, and a link to the relevant handbook section.

BAD: Sharing a draft roadmap in a Google Doc and asking for “quick feedback.”

GOOD: Creating an RFC in the /product repository with a clear problem statement, constraints, and options—including “do nothing.”

FAQ

What happens if I don’t submit a handbook MR by day 30?

Your 30-day review will note a critical gap in cultural alignment. Managers interpret missing documentation as either disengagement or misunderstanding of core values. No formal penalty exists, but escalation paths dry up. You’ll be assigned remedial onboarding, delaying real project ownership by 4–6 weeks.

Can I use external tools like Figma or Notion for early planning?

No. Any design or planning done outside GitLab.com or the handbook is invisible to the org and won’t be recognized. Use GitLab issues for wireframes, attach PNGs directly, and write alt-text. Notion docs shared in Slack are treated as unsanctioned artifacts.

How much time should I spend reading vs. doing in the first 60 days?

Aim for 70% reading, 20% writing, 10% doing. “Doing” means small, low-risk contributions: typo fixes, issue triage, RFC comments. Your primary job is sense-making, not execution. Engineers expect PMs to understand history before proposing change.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.