Public Issue Tracker; please use confidential issues for topics that should only be visible to GitLabbers at GitLab)
You can also send an email to the People Operations group (see the "GitLab Email Forwarding" google doc for the alias), or ping an individual member of the People Operations team, as listed on our Team page.
Chat channel; please use the #peopleops chat channel for questions that don't seem appropriate to use the issue tracker or the internal email address for.
In general, the People Operations team and processes are here as a service to the rest of the team; helping make your life easier so that you can focus on your work and contributions to GitLab. On that note, please don't hesitate to reach out with questions! In the case of a conflict between the company and a team member, People Operations works "on behalf of" the company.
The team directory is in BambooHR, and is accessible to all GitLabbers. This is your one-stop directory for phone numbers and addresses (in case you want to send your team mate an awesome card!).
Please make sure that your own information stays up to date, and reach out to People Ops if you need any help in doing so.
Please make sure that your address and phone information are written in such a way that your team mates can reach you from a different country. So, for example, include +[country code] in front of your phone number.
Letter of Employmnet and Reference Request Policy
If you need a letter from GitLab verifying your employment/contractor status, please send the request to People Ops citing what information is needed. We will provide most recent title, dates of employment, and salary information. We will also verify, but not provide National Identification Numbers. People Ops will send you the letter once it is completed. In addition, if the request comes from a third party, People Ops will always verify that the information is appropriate to share. If you are a US Employee you can follow these instructions for an automated verification through TriNet.
GitLabbers are not authorized by the company to speak on its behalf to complete reference requests for GitLabbers no longer working for GitLab. If a team member would like to give a personal reference based on their experience with the former team member, it must be preceded by a statement that the reference is not speaking on behalf of the company. To reinforce this fact, personal references should never be on company letterhead and telephone references should never be on company time.
For the NL office, we use a postbox address listed in the "GitLab BV address" note in the Shared vault on 1Password. We use addpost to scan our mail and send it along to a physical address upon request. The scans are sent via email to the email alias listed in the "GitLab Email Forwarding" google doc.
For the UK office, there is a Ltd registered address located in the "GitLab Ltd (UK) Address" note in the Shared vault on 1Password
Employees of our Dutch entity (GitLab B.V.) will get their salary wired on the 25th of every month, and can see their pay slip in their personal portal on HR Savvy's system towards the end of the month.
Employees of our US entity (GitLab Inc.) have payroll processed semi-monthly through TriNet, and they can access their pay slips through the TriNet portal.
Contractors to GitLab (either entity) should send their invoices for services rendered to email@example.com
For 'fixed fee' contracts, it is OK to send the invoice before the time period that it covers is over. For example, an invoice covering the period of March 1-31 can be sent on March 25.
All invoices are internally reviewed, approved, and then payment is processed. This is usually a fast process, but be aware that it can incur delays around vacations. In principal, payments go out once per week on Fridays.
An invoice template can be found as a Google sheet named "Invoice Template" (also listed on the finance page )
In keeping with our values of freedom, efficiency, transparency, kindness, and boring solutions, we have crafted the following protocol around sick leave for all GitLabbers.
If you or a loved one is ill, we want you to take care of yourself or your loved one(s). To facilitate this, you should take sick leave when you need it. Sick leave is meant to be used when you are ill, or to care for family members including your parent(s), child(ren), spouse, registered domestic partner, grandparent(s), grandchild(ren), and sibling(s).
You do need to report when you take sick leave, either by emailing your manager and People Ops, or by using the "Request time off" function in BambooHR. This way, it can be tracked in BambooHR and related payroll systems.
If you need sick leave for more than 8 consecutive calendar days, notify your manager and People Ops to accommodate an extended leave request. What can (or must) be accommodated varies from location to location: GitLab will comply with the applicable laws in your specific location.
Upon request, you should be able to provide proper documentation of the reason for your sick leave (doctor's note).
Details for specific groups of GitLabbers
Employees of GitLab Inc. who receive a pay stub from TriNet will see sick time accrue on their pay stub at the rate of 0.0346 hrs per hour worked (3 hours of sick leave per semi-monthly pay-period) for a maximum accrual and carry-over of 72 hours per year. GitLab's policy is more generous than this, in the sense that you can take off non-accrued sick time as written above (a negative balance may show on your pay stub). Sick time does not get paid out in case of termination, nor does it reduce your final paycheck in case of a negative balance. Related to the topic of extended leave requests, see information about short term disability through TriNet / your state.
Employees of GitLab B.V. have further rights and responsibilities regarding sick time based on Dutch law, as written into their employment contracts.
Hiring Significant Other or Family Members
GitLab is committed to a policy of employment and advancement based on qualifications and merit and does not discriminate in favor of or in opposition to the employment of significant others or relatives. Due to the potential for perceived or actual conflicts, such as favoritism or personal conflicts from outside the work environment, which can be carried into the daily working relationship, GitLab will hire or consider other employment actions concerning significant others and/or relatives of persons currently employed or contracted only if: a) candidates for employment will not be working directly for or supervising a significant other or relative, and b) candidates for employment will not occupy a position in the same line of authority in which employees can initiate or participate in decisions involving a direct benefit to the significant other or relative. Such decisions include hiring, retention, transfer, promotion, wages, and leave requests.
This policy applies to all current employees and candidates for employment.
If you change your address, you should let GitLab know the new address within a month. The best way to do this is by logging in to BambooHR and changing your address under the Personal tab. This triggers a message to the BambooHR admin to review the change and "accept" it.
PeopleOps will check that any necessary changes to payroll and benefits administration are processed in time.
If your relocation is to a different metro area, then to stay aligned with our compensation principles and per the standard contract agreements, you should obtain written agreement first (from your manager). It is the company's discretion to offer you a contract in your new location. In almost all situations the compensation will change, for an idea about the impact please see our move calculator. People Ops will process any changes that are agreed on, and file the email in BambooHR.
At GitLab, we encourage team members to take control of their own career ladders and career advancement. In all processes of title changes, the team member will speak with their manager about the change. Come prepared with an explanation of how you believe you meet the proposed level and can satisfy the business need.
As a manager, please follow the following processes, and do not make promises to the team member before the approvals are completed.
To promote one of your direct reports, a manager should follow the following steps:
Promotions are to be based on meeting the criteria of the role the individual is to be promoted in to (i.e. promote based on performance, not based on potential). If the criteria for promotion are not adequately described on the relevant job description page, then work on that first.
Manager must obtain agreement from their own manager(s), all the way through the chain of command to the CEO.
Promotions should also include a review of compensation and stock options. Managers should feel free to consult with People Operations on these topics; and of course always adhere to the Global Compensation Calculator. Don't send the promotion-proposal to the CEO until this part is included.
Once written agreement is reached on the promotion and changes (if any) in compensation, the manager informs the individual.
Once the individual has been informed, the manager informs People Operations with the promotion notice (i.e. reasons and related title and comp changes). People Operations processes the changes in relevant administrative systems.
Promotions are then announced by the manager on the team call; where the manager describes how the individual met the promotion criteria and includes a link to the merge request where the individuals title is updated on the team page.
If some amount of onboarding in the new role, or offboarding from the old role is required (for example a change in access levels to infrastructure systems; switch in groups and email aliases, etc.) make an associated issue on the GitLab Organization issue tracker to list and track progress on those topics.
To demote one of your direct reports, a manager should follow the following steps:
The manager should discuss any performance issues or possible demotions with the People Ops Business Partner in their scheduled meetings.
To initiate the process, the manager must obtain agreement from two levels of management.
Proposed changes to a current job description or a new job description should be delivered with request for approval by the second level manager and the People Ops Business Partner.
Demotions should also include a review of compensation and stock options. Managers should feel free to consult with People Operations on these topics; and of course always adhere to the Global Compensation Calculator.
Once written agreement is reached on the demotion and changes (if any) in compensation, send the agreement to the CEO for final approval.
Once approved, the manager informs the individual. Please cc People Ops once the individual has been informed, to processes the changes in the relevant administrative systems.
Changes in title are announced on the team call.
The manager will initiate any necessary onboarding or offboarding.
If you are interested in a position, regardless of level, outside your department or general career progression, you can apply for a transfer.
If you are interested in a transfer, first discuss this with your manager so that everyone is aware of the situation.
Transfers must go through the application process for the new position by applying on the Jobs page. The team member will go through the entire interview process outlined on the job description. Any questions about the role or the process? Please reach out to People Ops to discuss.
People Ops will ensure that, if applicable, the position has been posted for at least five business days before an offer is made.
A new contract will be sent out following the hiring process.
If the team member is transferred, the new manager will announce on the team call and begin any additional onboarding or offboarding necessary.
Internal Department Transfers
If you are interested in another position within your department and the hiring manager is also your manager, then the interview process is not necessary.
Present your proposition to your manager.
The manager will asses the function requirements; each level should be defined in the job description.
If approved, your manager will need to obtain approval from their manager, through the chain of command to the CEO.
Compensation and stock options will be reevaluated to ensure it adheres to the compensation calculator. Don't send the proposal to the CEO until this part is included.
If the team member is transferred, the manager will announce on the team call and begin any additional onboarding or offboarding necessary.
Administrative details of benefits for US-based employees
You are eligible to participate in GitLab’s 401k as of the 1st of the month after your hire date.
You will receive a notification on your homepage in TriNet Passport once eligible, if you follow the prompts it will take you to the Transamerica website https://www.ta-retirement.com/ or skip logging in to TriNet Passport and go directly to https://www.ta-retirement.com/ after the 1st of the month after your hire date.
Once on the home page of https://www.ta-retirement.com/ go to "First Time User Register Here".
You will be prompted for the following information
Social Security Number
Date of Birth
Once inside the portal you may elect your annual/pay-period contributions, and Investments.
Our company and office phone lines are handled via RingCentral. The login credentials are in the Secretarial vault on 1Password. To add a number to the call handling & forwarding rules:
From the Admin Portal, click on the Users button (menu on left), select the user for which you want to make changes (for door handling, pick extension 101).
A menu appears to the right of the selected user; pick "Call Handling & Forwarding" and review the current settings which show all the people and numbers that are alerted when the listed User's number is dialed.
Add the new forwarding number (along with a name for the number), and click Save.
Mental Health Awareness
At GitLab we strive to create a Stigma-Free Workplace. In accordance with the National Mental Health Association and the National Council for Behavioral Health we would like to:
Educate employees about the signs and symptoms of mental health disorders.
Encourage employees to talk about stress, workload, family commitments, and other issues.
Communicate that mental illnesses are real, common, and treatable.
Discourage stigmatizing language, including hurtful labels such as “crazy,” “loony” or “nuts.”
Help employees transition back to work after they take leave.
Consult with your employee assistance program.
What are we doing to get there?
Per an open issue, People Operations will be developing training for managers on this topic.
GitLab would also like to encourage GitLabbers to take their time off to properly take care of themselves. We encourage the team to go to yoga, take a long lunch, or anything else in their day to day life that assists in their mental and emotional well-being.
In addition to our current EAP programs available for employees, we encourage GitLabbers to take a look at (Working Through It)(http://www.workplacestrategiesformentalhealth.com/wti/Home.aspx) for insight into reclaiming well-being at work, off work, and return to work.
We believe that our values and culture lends itself to being able to discuss mental health open and honestly without being stigmatized, but let's work together to make it even more inclusive.
For example, Finding the right words:
"How can we help you do your job?"
"You’re not your usual self."
"Do you want to talk about it?"
"It's always OK to ask for help."
"It’s hard for me to understand exactly what you’re going through, but I can see that it’s distressing for you."
Any questions or concerns? Please feel free to speak with anyone in People Ops!
Dutch work permits
Some of our GitLabbers in the Netherlands have a "werkvergunning" or work permit under the highly skilled migrants category of the Immigration and Naturalization Service (IND).
GitLab is a recognized organization ("erkend referrent") with the IND, and Savvy provides support with respect to applying for new visas / permits or extending existing ones.
Work permits must be renewed at the end of each contract period, but at minimum once every 5 years.
At the time of applying for permit renewal, the application must satisfy various criteria including an age-dependent minimum salary requirement (with a step at age 30). This requirement should be taken into consideration when issuing a new contract, since the contract can be made valid for just a year or for an indefinite period; thus triggering more or less frequent re-applications for work permit extensions.
Paperwork people may need to obtain mortgage in the Netherlands
When your employment contract is for a fixed period of time (e.g. 12 months) you'll need a "werkgeversverklaring". This document describes your salary and states that your employer expects to continue to employ you after the contract expires (assuming the performance of the employee doesn't degrade). This document has to be filled in by hand, preferably using blue ink, and must be signed and stamped. If there is no stamp (as is the case for GitLab) an extra letter (also signed) must be supplied that states the employer has no stamp. While the language of these documents doesn't matter, the use of Dutch is preferred.
Employees also have to provide a copy of a payslip that clearly states not only their monthly salary but also their annual salary. These numbers must match the numbers on the "werkgeversverklaring" down to the decimals. Mortgage providers may also require you to provide information about your financial status, usually in the form of a report/screenshot of your total financial status (including any savings you have). The requirements for this seem to vary a bit between mortgage providers.
Involuntary termination of any team member is never easy. We've created some guidelines and information to make this process as painless and easy as possible for everyone involved. Beyond the points outlined below, make sure to refer to our guidelines on underperformance, as well as the offboarding checklist.
Ideally, the manager and the team member have walked through the guidelines on underperformance before reaching this point.
Manager: reach out to People Operations for assistance. People Ops will ask about what the performance issues have been, how they have been attempted to be addressed, and will then prepare for the termination.
Manager and People Ops: discuss best mode of communicating the bad news to the team member. This discussion can happen via a private chat-channel, but it is best to be done via a video hangout. Set up a private chat-channel in any case, since this is also useful to have during the eventual call with the affected team member.
Manager and People Ops: Decide who will handle which part of the conversation, and if desired, practice it. It is strongly advised to have someone from People Ops on the call when the bad news is delivered.
Manager and People Ops: Decide what offboarding actions need to be taken before the call (e.g. revoke admin permissions), or during the call (e.g. revoke Slack and Gmail access), and which ones can wait until later (see the offboarding checklist). Make sure someone with the necessary admin privileges is on hand (in the private chat-channel) to assist with those sensitive offboarding steps that should occur relatively quickly. Do not create the offboarding issue until after the call, since even confidential issues are still visible to anyone in the team.
Manager: Set up a call with the team member in question. Make a separate private calendar event to invite the People Ops representative.
On the call: deliver the bad news up-front, do not beat around the bush and prolong the inevitable pain for everyone involved. A sample leading sentence can be "Thanks for joining the call ___ . Unfortunately, the reason I wanted to speak with you, is because we have decided that we have to let you go and end your employment / contract with GitLab." At this point, hand over the call to People Ops to continue. People Ops explains what led to this decision and points to the process that was followed to reach this decision. People Ops to make it clear that the decision is final, but also to genuinely listen to their side of the story since there may be useful lessons in what they say for the rest of the team e.g. regarding hiring and vetting practices.
People Ops: Make sure to communicate the practical points from the termination memo outlined below.
Points to cover during the offboarding call, with sample wording
The following points need to be covered for any team member:
Final Pay: "your final check (or invoice period) is for the pay period of X and includes X days of pay”.
Company Property: “please return all property as explained in the handbook, also please delete GitLab’s email connection from your phone”.
Business Expenses: “please create your final expense report to Expensify (for employees), OR, please file any outstanding expenses with your final invoice (for contractors), so these can be reimbursed to you in a timely manner”.
Confidentiality and Non-Disclosure: “we know you are a professional, please keep in mind the agreement you signed when you were hired”.
The following points need to be covered for US-based employees:
COBRA: “your benefits will cease on last day of the month you are eligible for Consolidated Omnibus Budget Reconciliation Act (“COBRA”), the carrier (TriNet) has been notified and the carrier will send out the paperwork to your home address on file”.
PPACA: "You may also be eligible under the Patient Protection and Affordable Care Act (“PPACA”) for subsidized health care options via the marketplace. If you are interested it is important that you sign up with the market place well before the 15th of the month to have coverage for the following month”.
HIPAA: " under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), if you need a certificate of credible coverage please download it from your current carrier's online portal or request it from TriNet”.
Unemployment insurance: "it is up to your state's labor agency (in CA: EDD) to decide if you are eligible for unemployment insurance”.
Please remember to keep TriNet informed if you move I want to be sure your W-2 gets to you at the end of the year. You may also contact X at GitLab (provide phone number and email address) with any other questions that you may have" (consider inviting them to contact you at anytime for any reason)
Sample termination memo
If appropriate (to be determined by conversation with the manager, CEO, and people ops), use the following termination memo, which is provided here as an openly viewable Google Doc, but of course needs to be personalized and tailored to each individual's situation. As written, it is applicable to US-based employees only.