- A People Operations Specialist opens the onboarding issue at least four days before the start date and assigns the manager, who has their own pre-start tasks. S01
- Choosing the buddy is the manager’s first pre-start task. The ideal buddy has been at GitLab over three months, works in the same department, shares a similar time zone and is available for the first two weeks. S02
- A welcome call runs every two weeks at three different times to cover time zones, so future hires can ask questions a week or two before they start. S01
Back to the libraryEmployer handbook
Onboarding Atlas · Company research
GitLab
Remote and distributed
RemoteEngineeringCompany inductionRole learningOrdinary collaboration
Public research summary, not an official company process
This page reports only what was observed in the cited public sources. It does not imply endorsement, and something absent from those sources may still exist inside the company.
Summary
What the sources describe
GitLab is an all-remote company that publishes its onboarding process in its public handbook. Each new team member works through a GitLab issue that acts as a shared checklist for the hire, their manager and supporting teams, and gets a buddy chosen by their manager.
- The buddy welcomes the hire on a call on the first day, ideally late in the day so the hire has read the onboarding issue and has questions ready. S02
- The issue has a section every team member completes, due in 30 days, followed by department- and role-specific tasks. S01
- The handbook recommends at least two full weeks of general onboarding, with team-specific training starting in week three. S01
- An access request is generated on day two when a template exists for the role; IT owns access requests. S01
- Buddies schedule at least two follow-up calls in the week after the start date and at least one more during the first month, and arrange a backup if they will be away. S02
- Every checklist item must be ticked, either as done or as not applicable. A monthly audit chases open issues, and a bot closes any still open after 60 days. S01
- When someone moves to a new team, managers are encouraged to assign a career mobility buddy as well. S02
Not found in these sources
Absence here does not mean GitLab lacks it; the reviewed sources simply do not say.
- How readiness is judged beyond completing the checklist
- How onboarding outcomes are measured beyond the onboarding survey
- How the process differs by country or employment type
WeekOne adaptation
What to borrow, and confirm locally
- Keep one checklist with a section per owner (hire, manager, IT, HR) instead of separate lists that drift apart.
- Let people mark items “not applicable” rather than deleting them, so the record shows what was considered.
- Write down buddy criteria (tenure, team, time-zone overlap, availability) and name a backup before day one.
These are our suggestions, not GitLab’s practice. Do not copy company-specific dates, tools or rules without checking they fit your organisation.
Related WeekOne blueprints
Sources and provenance
Read the evidence in context
S01Checked 2026-09-25
GitLab Onboarding
GitLab · Public handbook · Undated / living
Onboarding runs as a GitLab issue opened at least 4 days before the start date, with a 30-day due date and role-specific sections.
Limits: Living handbook page that changes often; describes intended process, not measured outcomes.
Open sourceS02Checked 2026-09-25
GitLab Onboarding Buddies
GitLab · Public handbook · Undated / living
Manager assigns a buddy before day one; buddy calls on day one and holds at least two follow-up calls in week two.
Limits: Selection criteria are stated as ideals the handbook says cannot always be met.
Open sourceNot found in a document is not proof the organization has no such process. All task schedules, completion rules and blueprints here are original proposed adaptations. Never infer legal duties, actual policies, licensed tools or production permissions.
Your document, your decisions