The People Group Engineering team aims to reduce as much manual work as possible. One of the areas we have done this, is everything related to the employment automation flow.
Everything on this page, assumes the team member is already present in Workday. To read more about how they get synced to Workday, you can read this handbook section.
Note: this section only discusses items in the onboarding where People Engineering was involved. You can read more about onboarding at GitLab on this handbook page
The onboarding issue creation is a semi-automated process. Meaning that it needs to be triggered by a People Connect team member to be started. A People Connect team member can make use of the onboarding Slack command to initiate the process.
The onboarding issue will be automatically assigned to the People Connect Team member who ran the command and the incoming team member's Manager.
The onboarding tasks that are applicable to all team members are listed in the
general onboarding.md file. It will be included by default in the onboarding issue.
The job then grabs various details of the incoming team member, like country of residence, entity through which they are hired, division, department, job title etc. For each of these details, it checks for the existence of a task file in the onboarding_tasks folder of the employment project. These tasks files are of the format country_<country name>.md, entity_<entity name>.md, division_<division name>.md, department_<department name>.md, role_<exact job title>.md, etc. If such a file is found, it includes contents of those files also in the onboarding issue.
Role templates don't take seniority into level. For example SDR 1, 2, or 3 would all receive the SDR template.
If you receive a question from a manager about why a template was not linked in an onboarding issue, be sure to check the naming convention of the template and ensure everything matches up in Workday with the entity, division, department, etc. If everything looks like it's matched up, reach out to the People Group Engineer for additional assistance.
Note: If a People Connect Team member needs to create the onboarding issue for interns, they can use the same Slack command.
This issue is added to the team member's epic.
If you want to read more about how employment issues are set up, please read this section.
This Job has currently been disabled, but may be brought back in the future.
A scheduled pipeline is configured to automatically send a message containing a list of all new team members who are joining GitLab in the following week. It includes details like name, email address, joining date, and their job title. The message also includes a link to a Sisense chart containing a detailed breakdown and overview of the hiring process over time.
While we create this message, we check if there are any team members that have
"missing data". When they do, the message, is sent to #peopleops-alerts. This
way, the People Connect Team member, can make sure the data is added and run the joiningannouncement Slack command.
When there is no missing data, the message is posted directly to #team-member-updates.
Currently, the pipeline is scheduled to be run at 08:00 AM UTC every Thursday.
We run a scheduled pipeline every day that invites team members starting the following day to the two main GitLab groups:
The invite email is send to their GitLab email address which they will get access to the next day.
Our team members are expected to update their BambooHR profile on their first day at GitLab. To be able to do that they need to have self-service access level enable on BambooHR. We run a scheduled pipeline every day that enables this for team members starting the following day.
In the event we failed to enable a particular team members account, a PEA can use the activateselfservice Slack command to re-trigger this automation for the team member.
This will attempt to enable the Self Service feature of their BambooHR profile.
This is the email that is sent to our team members on the morning of their first day of employment (based upon the onboarding date in the issue title). The email is cc'd to people-connect@domain.
Every day we run 3 scheduled pipelines. They are each set up for a specific region:
For the JAPAC pipeline, it will fetch the team members with a start date for the next day (timezones).
For the EMEA and Americas pipeline, it will fetch all the team members that have a start day equal to the current day (so who is starting today). The pipeline then filters out the ones for the region they need to send the email to. This all is to ensure we don't send out the email too late or too early. The region of the team member is determined from the region that is on their Workday profile. This is the first iteration, if we need to split it up by country, we can rework the current implementation.
We fetch some other data besides the region as well:
This data is used to populate the email that we then send to them. The email address used to send the email is onboarding@domain and is set with a reply-to: people-connect@domain as nobody monitors replies to onboarding@. The email address is strictly used for automation.
If for some reason the e-mail could not be sent, we have added functionality for a People Connect Team member to be able to manually send this by running the onboardingemail Slack command.
This triggers the following flow:
If changes are required to the onboarding email template, follow these steps to update them:
View HTML on the top left hand side of the website.This is the email that is sent on the first day of a new team member so they receive the code to get a discount at the swag store. The email is cc'd to people-connect@domain.
Every day at 9 AM UTC we run a scheduled pipeline. This pipeline will fetch all the eligible team members. An eligible team member means:
The email address used to send the email is onboarding@domain and is set with a reply-to: people-connect@domain as nobody
monitors replies to onboarding@domain. The email address is strictly used for automation.
To get access to the tools our team members need for their job, an Access Request (AR) issue needs to be created. To make sure our team members experience a good onboarding, we automated this process by creating the AR Role based entitlement issue with the bot.
Every day we run 3 scheduled pipelines. They are each set up for a specific region:
For the JAPAC pipeline, it will fetch the team members with a start date for the current day (timezones). For the EMEA and Americas pipeline, it will fetch all the team members that have a start day equal to the previous day (so who started yesterday). The pipeline then filters out the ones for the region they need to send the email to. This all is to ensure we don't create the issue too late or too early. The region of the team member is determined from the region that is on their Workday profile.
For all these members it will check if it is possible to create an Access Request issue. It will only work for the members with roles that have a set template in the role baseline access requests tasks directory.
The templates are created on a role level and can be created for the specialty level as well. For example
if you have a person with the role Security Engineer, Strategic Security. The code will look for two templates:
role_security_engineer.md and role_security_engineer_strategic_security.md. Note: you don't need to have both created,
but if there are two, the code will use both to create the issue, if there is just one, it will create the one it can find.
The issue will be created in the AR project.
The bot will announce in Slack (#peopleops-alerts) the list of people that we were able to create the AR. As well as the list of people (with their role) that we weren't able to create the AR for. This way we can connect with the teams so they can add a template for this role.
For those that we can not create an issue, the Employment bot will leave a comment on the onboarding issue. In this comment the manager is tagged to inform them and we ask them to create the issue and if needed to create a template for future hires.
Note: People Operations is not responsible for creating or maintaining the templates, each team is responsible for creating the templates for their roles. This is also explained in the README of the project.
Here's a video with the People Group Engineer going over the AR automation. They discuss how it works and how a template can be added.
Every day at 09AM UTC, we have a pipeline running that fetches all the team members that started yesterday and check if they can be synced to the team page. Currently the only required item to determine if we can sync them is that they need to have a GitLab username.
If we can't determine their GitLab username (from the issue or from their Workday profile) we will leave an issue note on the onboarding issue asking them to fill in their Workday profile correctly.
Every day at 09AM UTC, we have a pipeline running that syncs our new team members to the www-gitlab-com project, so that they show up on the team page.
Many teams have adopted the team page entries for building out custom partials within the handbook, any changes to this process should be sent in
#whats-happening-at-gitlabprior to get insights from other teams on their particular use cases.
We fetch all the new team members with a start date of the day before yesterday and check if they opted-in on
being synced to the team page. Opt-in happens by setting Export Name Location to Team Page to Yes on their Workday profile. This is a task on day one for the new team member.
If they selected yes, we grab some data (name, job title, start date, department and country) and format it,
so it can be added to the team page entry. If they did not opt-in, we still add an entry to the team page.
However that entry is anonymous. For every new team member, we commit a new file in the data/team_members directory.
We then create a merge request on www-gitlab-com project so it can be merged.
The merge request is assigned to the People Connect team and they set it to merge when the pipeline succeeds.
In the event we run into errors with the team page sync, we have some backup plans in place.
In case team members did not fill in the required data, we won't be able to sync them. A People Connect Team member
can later on sync them by running the teampageindividual Slack command.
This will spin up a pipeline and fetch the details. Note that if the team member was synced already, it will abort the sync.
If the entire group of team members was missed, in the event of a failed pipeline or another error, a People Connect Team member can re-run the sync by using the teampageweek Slack command.
This will trigger a new pipeline and fetch the new team members of the provided week and create a new merge request adding them to the Team page.
We have a daily pipeline that checks everyday who started 6 days ago. For those team members, we send a reminder that they have to complete the anti-harrassment training.
There's a scheduled pipeline that runs every day that checks for hires that started a week ago. For those hires we will look if the incoming team member is a people manager. Currently there's no exact field on Workday for us to check this. The way we do this is by by looking at their job title. If it starts with any of the following:
Team LeadManagerSenior ManagerDirectorSenior DirectorChiefVPVice PresidentWe also consider the person a people manager when the job title ends with:
Area Sales ManagerWe create the Interview Training and Becoming a Manager issues in the People Group Training project.
We run a scheduled pipeline every day that fetches our team members that are on their 15th day of employment at GitLab. We look on their onboarding issue if they have any compliance tasks open.
A compliance task is marked with the :red-circle icon. If they have any open tasks the onboarding bot will tag the user asking to finish the open tasks.
It is expected that onboarding issues be completed and closed within 30 days of
opening. To remind team members about this, we are using the due date
functionality in GitLab issues. When an onboarding issue is created, we
automatically calculate the due date by adding 31 days to their start date.
GitLab will send a reminder notification email to all the assignees of the issue
near the due date.
In addition to this due date, team members get an additional 30 days to complete and close the onboarding issue. In total, a team member gets around 60 days to complete their onboarding issue.
We have a scheduled pipeline to close the outdated issues (issues that have been open for more than 60 days). This pipeline will add a comment on the issue that it is being automatically closed and what the team members should do if they have onboarding tasks remaining.
Currently, the pipeline is scheduled to be run at 09:30 PM on every Friday. It will close all the onboarding issues created before 60 days from that date.
This is the email that is sent to our team members after 90 days of employment.
We also send their manager this email as well to notify them of the values check in.
Every day at 10 AM UTC we run a scheduled pipeline. This pipeline will fetch all the team members that are eligible to get this values check-in. For every eligible team member we send out two emails:
The email address used to send the email is peoplespecialists@domain and is set with a reply-to: people-connect@gitlab.com as nobody monitors replies to peoplespecialists@domain. The email address is strictly used for automation.