A senior developer on a custom software project resigns on a Tuesday. She holds the deployment scripts, the client's trust and a memory of why the payment module works the way it does. The delivery head accepts the resignation, thanks her, and returns to his client call. Three weeks later, with four days left, someone asks who will do the release.
Notice periods are the one chance to move knowledge out of a person's head. This guide gives a delivery head a plan that starts on day one and ends with a clean exit.
The first week
The first conversation sets the tone. Thank the person, confirm the last working date as per their contract, and ask them to help plan the handover. Do not start with access removal or suspicion. A person who feels respected will usually share more.
- 1
Confirm the dates and the owner
Record the last working day as per the contract. Name the delivery lead who owns the handover and a backup.
- 2
List what the leaver alone knows
Ask the leaver, the team and the client contact. Include scripts, environments, credentials, decisions, customer quirks and recurring tasks.
- 3
Name a successor for each item
One person per area, not a committee. If no one fits, flag the gap now and plan a hire or a training task.
- 4
Agree what the client is told and when
The account owner decides, following the contract. Tell the client early enough to avoid surprise.
- 5
Set weekly handover checkpoints
A short meeting each week with the leaver, the successor and the delivery lead to review progress against the list.
Capture by doing
Documents help but they are rarely enough. People write what they remember and miss what they do by habit. The strongest method is a shadow and reverse shadow: the successor watches the leaver do a task, then does it while the leaver watches. Use this for deployments, hot fixes, data loads and client status calls.
- Record a short screen video of each recurring task with voice notes.
- Ask the successor to write the steps while following them for the first time.
- Keep a list of questions the successor asked, since these point to gaps.
- Note the decisions behind any odd code or setting, with links to tickets or emails.
What the handover document should hold
Project, client contact and engagement rhythm.
Code repositories, branches, build and release steps.
Environments, test data, devices and how to reset them.
Accounts and credentials: list them, transfer through the proper process, never share a personal login.
Open tickets, known defects and risks with the latest status.
Recurring tasks with frequency and effort.
Decisions and the reason behind them.
People to contact inside the firm and at the client.
Successor name and date they ran each task alone.Access and security
Reduce access in steps that match the handover. Remove rights the person no longer needs, move shared accounts to the successor and rotate shared secrets on the last day. Keep a short log of what changed and when. Do this respectfully and tell the leaver what you are doing and why. It is a routine and not an accusation.
Keep the leaver engaged
A person on notice may feel left out. They lose project meetings, status updates and sometimes respect. A good handover needs their goodwill, so keep them in the loop. Give them a clear role: trainer of the successor, owner of the handover list, and a person to be consulted on tricky decisions. Thank them in front of the team at the end.
Do not load a leaver with new work that nobody can finish. Do not exclude them from the team chat on day two. Small signs of respect show up later in the quality of the notes they leave behind, and in the way other staff view the firm.
When the notice period is short or ends early
Sometimes the notice is shorter than the plan. Your policy, the contract and any agreement between both sides decide what can be done. Whatever the length, put the most critical items first: releases in the next month, credentials and client commitments. A pared-down plan on one page beats a long one nobody reads.
If the leaver is placed on a shorter period or asked to leave early, treat the knowledge list as urgent and use calls and recorded sessions. Any change to the agreed period should be recorded in writing.
Communicate with the team and the client
The team will have questions about workload and what the exit means. Share the plan, the successor and any changes to deadlines. For the client, a short message works well: who is leaving, when, who takes over, and how overlap will run. Custom software clients often care most about continuity, as the custom software companies page explains.
After the last day
Hold a short review a few weeks later. Ask what was missed, which questions the successor still asks and whether the process helped. Also hold an exit conversation with the leaver on their reasons, since the pattern across exits is useful. The exit and offboarding process page describes how we help firms set this up. For the wider context of leaving rates after reviews, read the post on attrition after appraisal season, and for planned moves inside the firm the first-year training post shows how to build depth in the team.
