offboarding.rst 22.8 KB
Newer Older
Boris Budini's avatar
Boris Budini committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463
.. note::
  **This page was uploaded from GitLab's Handbook**

Voluntary Terminations
----------------------

A voluntary termination occurs when a team member informs his or her
manager of a resignation.

If you are a current team member and you are thinking about resigning
from GitLab, we encourage you to speak with your manager, People Ops, or
another trusted team member to discuss your reasons for wanting to
leave. At GitLab we want to ensure that all issues team members are
facing are discussed and resolved to result in a great work environment.

If resignation is the only solution after you have discussed your
concerns, then please follow these procedures.

Procedures
~~~~~~~~~~

1. Team members are requested to provide an agreed upon notice of their
   intention to separate from the company to allow a reasonable amount
   of time to transfer ongoing workloads.
2. The team member should provide a written resignation letter or email
   notification to their manager.
3. Upon receipt of the resignation, the manager will notify the People
   Operations Business Partner (POBP) by sending a copy of the
   resignation email/letter. A discussion with the manager and POBP
   should also happen if needed to determine what lead up to the
   resignation.
4. POBP will forward the resignation email to the people operations
   email inbox. If the team member has a contract with a co-employer,
   people operations should forward the email to the contact at the
   co-employer.
5. The People Operations Generalist (or another member of the People
   Operations Team) will organize the offboarding, depending on the
   location of the team member it may mean that another member of the
   people operations team handles the offboarding. This can be either
   the People Operations Specialist, People Operations Analyst or the
   Talent Operations Specialist. Collectively known as "People Ops" for
   the purposes of the following points:
6. The POBP will post a message in the #terms confidential channel in
   Slack and provide the name and last day of the individual. The
   Payroll and Payments Lead should be ``@``.
7. After the POBP and Manager have reviewed the circumstances of the
   resignation, the team member may take the opportunity before the end
   of their notice period to share their decision to leave during a
   Company Call or in Slack
8. After People Operations is made aware of the upcoming resignation an
   acknowledgement letter or email (email only for contractors or GitLab
   Inc team members) confirming last day, the name of the POBP, and
   details of the `exit survey <#exit-survey>`__. An `example
   email <https://docs.google.com/document/d/1rZvczqEuyyFDAzjheiF4LpcLuvj9fFd6maPOSDwkYpQ/edit>`__
   is available to use for this.
9. If the individual has a statutory holiday allowance, the holiday
   taken should be confirmed with the manager and team member via email
   and then filed in BambooHR. Once that has been done an
   acknowledgement letter can be prepared. This will depend on the
   location and employment status of the team member. Examples of these
   can be found here:

-  `GitLab Ltd (UK) Resignation
   Acknowledgement <https://docs.google.com/document/d/1zV1qnZmjQaNZ3QUjrLOtod-FbboNCPmYdqCLIAc7aos/edit>`__
-  `GitLab BV (Netherlands) Resignation
   Acknowledgement <https://docs.google.com/document/d/1-9hCL2Xs5po4lZ19L2vrcmGxQIYRD-Emyci3F63kt0c/edit>`__

1. For GitLab UK team members, payroll can pay up to and including the
   5th day of the following month. For example: If someone's last day is
   February 2nd, the team member can receive their final pay for this in
   January's payroll.
2. Once the acknowledgement email or letter is sent, People Ops will
   send the exit survey to the team member to complete.
3. People Ops will create an `offboarding
   issue <https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/offboarding.md>`__
   on or before the last day.

Exit Survey
~~~~~~~~~~~

The exit survey provides team members with the opportunity to freely
express views about working at GitLab. People Operations will send a
`CultureAmp <https://www.cultureamp.com/>`__ survey. If the team member
would like to discuss their responses they can do so with the POBP.

GitLab Alumni Program
~~~~~~~~~~~~~~~~~~~~~

All voluntary terminations will be added to a Slack Channel
``gitlab-alumni``. The purpose of this channel is to network with team
members who have voluntarily left the company to preserve the
relationships built while at GitLab. The channel is voluntary to all
former and current team members.

GitLab, the company, monitors the channel and can remove people from it
at their sole discretion.

Involuntary Terminations
------------------------

Involuntary termination of any team member is never easy. We've created
some guidelines and information to make this process as humane as we
can. Beyond the points outlined below, make sure to refer to our
guidelines on `underperformance </handbook/underperformance>`__, as well
as the `offboarding
issue <https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/offboarding.md>`__.

Announcing Terminations
-----------------------

We strive to maintain personal information regarding all team members
private, this includes information regarding an team members voluntary
or involuntary departure from GitLab. However, a manager with the
consent and approval of the departing team member can share more details
with the GitLab team regarding the decision to leave GitLab.

For a voluntary departure a team member may have chosen to leave for
many different reasons, career development, promotion, a new role or
career path, dislike remote work, etc. For example, a team member may
tell their manager that they really miss being in an office environment
and remote work is not suitable for their personality. Based on that
decision they have taken another opportunity that allows them to go to
an office.

If the departing team member gives their manager permission to share
that information then the manager will share while making the departure
announcement on the team call. We want all GitLab team members to be
engaged, happy and fullfilled in their work and if remote work, the
requirements of the job or the role it self are not fullfilling we wish
our team members the best of luck in their next endeavor.

Regarding involuntary terminations, certain information can also be
shared with the GitLab team regarding the departure. Some team members
do not thrive or enjoy the work that they were hired to do. For example
after starting at GitLab a team member quickly learns they have no
desire or interest to learn Git or work with Git. This doesn't make them
a bad person, it just means they don't have the interest for the role
and based on that the decision was made to exit the company. Again, we
want all team members to enjoy and thrive in their work and that may or
may not be at GitLab.

If the departing employee approves the manager can share that
information when the departure is announced. Simply after starting the
team member realized this was not a good fit and working with their
manager decided to leave. A note to managers, you should always agree
with the departing team member on what will be shared and never share
something that you would not want the departing team member to hear
about.

In some instances there will be no further clarification on why a team
member has departed, if there are concerns you can address those with
your manager. Different levels of transparency will exist based on
maintaining respectful treatment for all departures. Having team members
leave may be a learning opportunity for some, but should not be a point
of gossip for anyone. Managers will need to balance the opportunity for
learning with the expectation of privacy and consult their People
Business Partner should they have questions.

Transparency is one of our values. In the case of terminations
transparency `can be painfully specific, calling out an employee’s
flaws, while inviting more questions and
gossip <https://outline.com/PTGkER>`__. We opt to share the feedback
only with peers and reports of the person since we balance transparency
with our value of collaboration and negative is 1-1.

Overall process
~~~~~~~~~~~~~~~

Ideally, the manager and the team member have walked through the
guidelines on `underperformance </handbook/underperformance>`__ before
reaching this point.

1. Manager: Reach out to the appropriate People Operations Business
   Partner (POBP) for assistance. POBP will ask about what the
   performance issues have been, how they have been attempted to be
   addressed, and will then prepare for the termination.
2. If the team member is employed with a co-employer, that co-employer
   should be consulted as they can provide advice on the appropriate
   procedure to follow.
3. POBP: Notify the Director of Legal Affairs, Director of Security, the
   CCO and payroll of the termination. This can be done via the
   confidential #terms channel but depending on the situation it may be
   necessary to discuss this via direct message or video call.

-  Payroll should be notified due to final payment regulations based on
   each state or country.

1.  POBP: With manager and/or CCO determine if a `separation and release
    of claims
    agreement <#Separation-and-Release-of-Claims-Agreements>`__ is
    appropriate. If so, have it prepared prior to the call.
2.  Manager and POBP: 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. Another
    member of the People Operations Team should also be added to this
    channel as they will be responsible for handling the offboarding
    Issue tasks during the call. This can be the People Operations
    Generalist, People Operations Specialist, People Operations Analyst,
    Junior Talent Co-ordinator or Talent Operations Specialist.
    Collectively known as "People Ops" for the purposes of the tasks
    listed below.
3.  Manager and POBP: Decide who will handle which part of the
    conversation, and if desired, practice it.
4.  Manager and POBP: If the team member who is being terminated is a
    people manager a communication plan for the team regarding the
    departure should be in place before the termination proceeds. The
    plan should include identification of an interim leader if possible,
    scheduled meeting with interim leader, a scheduled team call to
    announce the departure and the interim leadership, and then an
    announcement on the company call. Informing the team and answering
    questions should be the top priority. No announcement should be made
    on a company call until a team call has been completed. In most
    cases a team call can occur the same day of the termination, if
    necessary the termination can be announced on the company call the
    following day.
5.  Manager and POBP: 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
    issue <https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/offboarding.md>`__
    for the full list of actions). Do not create the offboarding issue
    until *after* the call, since even confidential issues are still
    visible to anyone in the team.
6.  Manager: Set up a call with the team member in question. Make a
    separate private calendar event to invite the POBP.
7.  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 POBP to
    continue. The Manager will make it clear that the decision is final,
    but will also explain what led to this decision and will point to
    the process that was followed to reach this decision. POBP will also
    make it clear that the decision is final, but also will 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.
8.  POBP: Make sure to communicate the `practical
    points <#offboarding-points>`__ from the termination memo outlined
    below.
9.  People Ops: Create the `offboarding
    issue <https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/offboarding.md>`__
    and complete all relevant tasks.
10. People Ops: If an employee, review if any time off needs to be paid
    on the last paycheck by looking in BambooHR under Time Off.
11. People Ops: If applicable, sign the team member up for a
    `Mentat <https://thementat.com/>`__ subscription. Credentials,
    licenses, and pricing are in the People Ops 1Password vault.
12. People Ops: If appropriate (default is that it is appropriate), send
    a `termination memo <#termination-memo>`__.

Points to cover during the offboarding call, with sample wording
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

{: #offboarding-points}

The following points need to be covered for any team member:

1. Final Pay: "Your final check (or invoice period) is for the pay
   period of X and includes X days of pay”.
2. Company Property: “Please return all property as explained in the
   handbook, also please delete GitLab’s email connection from your
   phone”.
3. 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”.
4. Confidentiality and Non-Disclosure: “We know you are a professional,
   please keep in mind the agreement you signed when you were hired”.
5. If you would like GitLab to share your personal email with the rest
   of the company, please send an email to People Ops or a farewell
   message that can be forwarded on your behalf.

The following points need to be covered for US-based employees:

1. COBRA: “Your benefits will cease on last day of the month you are
   eligible for Consolidated Omnibus Budget Reconciliation Act
   (“COBRA”), the carrier (Lumity) has been notified and the carrier
   will send out the paperwork to your home address on file”.
2. 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”.
3. 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 People Ops”.
4. Unemployment insurance: "It is up to your state's labor agency (in
   CA: EDD) to decide if you are eligible for unemployment insurance”.
5. Please remember to keep GitLab 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 <https://docs.google.com/document/d/11Uk8p4VJrLnDD5IAtbTwswPUUEnmeEOazS1kJMhOu70/edit?usp=sharing>`__,
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.

Separation and Release of Claims Agreements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If appropriate (currently only in the case of US based employees, and to
be determined by conversation with the manager, CEO, and People Ops)
prepare a Separation and Release of Claims Agreement following the steps
outlined here. All of these steps are done by People Ops unless
specified differently.

1. Prepare the
   `agreement <https://docs.google.com/document/d/17Dim1GC_LV0XF2DRzYNVRFrKlNE80fuXxAjP-jou8Yw/edit?usp=sharing>`__.
2. Have the legal team review the agreement.
3. Additional notes:
4. Separation pay is not paid until the ex-team member signs the
   document and the revocation period has passed.
5. Make sure you understand the rules for over 40.
6. You must use language in your exit meeting that is in no way forceful
   of the ex-team member to sign the agreement. Use phrasing such as “if
   you choose to sign”; “you have a right to have legal council review
   this document before you sign”, etc.

Departures are unpleasant
-------------------------

As explained briefly in the `offboarding
issue <https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/offboarding.md>`__,
GitLab does not provide any context around why people are leaving when
they do. However as mentioned in the
`procedures </handbook/offboarding/#procedures>`__, for voluntary
terminations, the team member can share their reasons for leaving if
they wish. If they choose not to then we say: "As of today, X is no
longer with GitLab. Out of respect for their privacy I can't go into
details. If you have questions about tasks or projects that need to be
picked up, please let me know."

If someone is let go involuntarily, this generally cannot be shared
since it affects the individual's privacy and job performance is
intentionally kept `between an individual and their
manager </handbook/general-guidelines/#not-public>`__. Given the
expectations and responsibility that come with a VP and above position,
when there is an involuntary termination for one of these positions,
additional context for the personnel change will be provided to the
organization. If you are not close to an employee's termination, it may
seem unnecessarily swift. Please remember that these decisions are never
made without following a process to come to a positive resolution first
- we need to protect the interests of the individual as well as the
company, and terminations are a last resort. While we are used to
Transparency by default according to our company values, we are limited
in what we can share about private employee issues. Please discuss any
concerns you have about another employee's termination with your
manager.

Silence is unpleasant. It's unpleasant because we are human, which means
that we are generally curious and genuinely interested in the well-being
of our team members.

Is it *more* unpleasant in a remote setting? Probably not. When people
are all in the same office building, they can "kinda sorta" know what
may be coming because of the grapevine, the water cooler, and so on.
When the news hits it might be less of a shock - only because of
unprofessional behavior in the first place. But at larger companies with
multiple office buildings, departures will tend to come as more of a
surprise and with less context (at least to the people in other
buildings).

Turnover Data
-------------

GitLab's `turnover
data <https://docs.google.com/a/gitlab.com/spreadsheets/d/1yk_tlu-Qy3j4VbaB8Yt4wMc5Gocxri9cp7F57DVWyYM/edit?usp=sharing>`__
is only viewable internally. This data is updated on a monthly basis by
People Operations.

Offboarding Issue
-----------------

Before starting an offboarding issue, make sure that the team member's
resignation or termination has been discussed and cleared with *at
least* the member of the executive team to whom the team member
(in)directly reports.

When it is time for offboarding, [create a new **confidential**
issue]https://gitlab.com/gitlab-com/people-ops/employment/issues/new)
for former team member using the ``offboarding``
`template <https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/offboarding.md>`__
using the
`dropdown <https://docs.gitlab.com/ee/user/project/description_templates.html#using-the-templates>`__,
and edit it for applicability to the individual. Please `update the
checklist <https://gitlab.com/gitlab-com/people-ops/employment/edit/master/.gitlab/issue_templates/offboarding.md>`__
as more steps arise.

Managing the Offboarding Tasks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Returning property to GitLab
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

{: #returning-property}

As part of offboarding, any GitLab property valued above 1,000 USD needs
to be returned to GitLab. One exception to this rule is that the team
member can opt to purchase their laptop at a depreciated market price
which will be provided by Finance upon request.

For items being returned, GitLab will pay for the shipping either by
People Ops sending a FedEx shipping slip or it can be returned by
another mutually agreed method. If property is not returned, GitLab
reserves the right to use a creditor company to help retrieve the
property. Please see `asset
tracking </handbook/finance/asset-tracking/>`__ for more information.

FedEx info for the team member
''''''''''''''''''''''''''''''

Pull up the departing contributors home address. Find a Fedex location
close to them. Then follow the template below.

"Hi [Name of team member]

The closest Fedex to you is located on [full street address, city,
state, zip code]. Driving or walking directions can be found here:
[enter link from “mapping home location to the Fedex location”]

Once there you can use Fedex boxes that you need and do the following
actions:

1. Package the equipment in the box
2. Send package to GitLab in San Francisco
3. Mark on the invoice "Bill Recipient"
4. Our Fedex number is: [find the number in Secretarial Vault in
   1Password]
5. Provide People Ops the tracking number via email

Please let People Ops know if you have any questions.

Expensify
^^^^^^^^^

To remove someone from Expensify Log in to
`Expensify <https://www.expensify.com/signin>`__ and go to "Settings" in
the left sidebar. Select the right policy based upon the entity that
employs the team member. Select "People" in the left menu. Select the
individual's name and click "Remove". If the person has a company credit
card assigned to them please notify Finance before un-assigning it.

Evaluation
~~~~~~~~~~

1. How could this outcome have been avoided?
2. Were there early signs that were missed?
3. In retrospect, what questions should have been asked to bring
   awareness and ownership to performance issues? For example, "How
   would you compare yourself relative to your peers?" People are
   surprisingly honest here.