Don't wait until someone is leaving a project to figure out all the things that need to be done before they're gone.
| Resource information | Details |
|---|---|
| Article Title | Technology Moving Positions & Offboarding for Resigning or Retiring Employees |
| Authors | Texas Woman's University |
| Focus | Offboarding, Exiting |
What happens when someone on a project, specifically a technical contributor, leaves? Even in the best of situations, there is not enough time to get everything done if your project isn't already prepared for any such departure with an offboarding plan.
There are many good resources on the web for understanding the importance of offboarding. Atlassian details the "What" and "Why" in their Understanding the Offboarding Process article. StrongDM proposes an excellent check-list with All Offboard! The 2025 Tech Staff Offboarding Checklist.
These articles cover the important tasks like exit interviews, recovering physical assets, removing access to internal accounts and resources, etc. But what are the less practiced offboarding steps specific to software contributors? The referenced article above from Texas Woman's University starts with an essential observation: The first step to a successful offboarding process is a well-planned onboarding process.
The day a person starts on a project is the best time to identify what parts of the code base they are responsible for, where its documentation resides, where the tests are, and how they are run. While TWU's article covers the transfer of access to important documents or emails, the same applies to functionality ownership and expertise within the source code of a software project. In the spirit of starting the offboarding process early, the software team should regularly review these roles and add to them the secondary or backup people for each area.
If someone leaves the project (or is unavailable for a significant period), having that list can ensure that functionality is not abandoned and avoid contributing to technical debt. Tools to support this currently exist. Both Github and Gitlab support a CODEOWNERS file where people or teams of people are identified and automatically added as reviewers for pull or merge requests.
Early identification of who inherits the code and responsibilities of a person leaving a project is just one of the many things an onboarding and offboarding process or checklist needs to identify. In this reviewer's opinion, it is an often overlooked and very important step highlighted in the TWU article.
