There is nothing quite like the heart sinking feeling other team members get when a developer announces they’ll be leaving a small team.
Mild panic sets in, and everybody looks to each other for reassurance. Yet that moment is the right time to switch mindsets to focused offboarding. Ensuring the remaining members are left in the best state possible to continue their great work.
Team size is critical here. One developer leaving a team of five often has a huge impact relative to a developer leaving a team of 20. Small teams need to run offboarding in a way that acknowledges this size frailty and mitigates the short and long term risks associated with developer churn.
In a small team it’s almost inevitable you will have some knowledge that only exists in the brain of one or two people. With the best will in the world, it’s unlikely your team is pair coding across all work—although that would be amazing—meaning that even with documentation, and handovers and knowledge sharing, you know that within your team some people have useful information that you wouldn’t want to lose when they move on.
This might consist of client relationships, codebase kludges or even whole products. When you’re being pragmatic, and facing the challenges that smaller teams face with capacity and prioritising, you’re always going to be left with some value in the head of a single person that you could really do with being shared.
You might occassionally laugh about what would happen if one of the team were kidnapped, or fell into a deep sleep for months. It’s a joke many small teams share over lunch or during a social, but one that doesn’t immediately lead to action, or panic. The imminent departure of a team member with warning however should have exactly that effect.
Here is how to plan for and action those events.
—
Planning for offboarding isn’t complex, but it does need prioritising. You’re about to lose an important and valuable store of information, and you’re goal is to share and document as much information that isn’t already shared with the wider team.
Start with the obvious things.
Tasks that they’re assigned to but won’t complete before they depart. Document them all. Consider their priority. Assign ownership of them to others. Do handovers of each where necissary.
List any clients that they’re the primary contact for. Decide on how the relationship works beyond their departure date. Tell each client about the change. Talk as a team in depth about the client, the relationship, the products or services and try to create a detailed landscape for the next person to use as the foundations for their new relationship.
Product information. If the departing team member has any products they’re solely responsible for, they need a detailed handover. The sharing of workarounds and edgecases. The infrastructure, work-in-progress and roadmap. What will be affected. What can carry on as normal. What the risks are.
Dev Ops. Any responsibilities which need reassigning? Any processes or procedures which need a new owner and a handover?
Culture shift. What does the departing team member bring to the team that will be lost? What concerns do other team members have about the change? What can be done to reassure, adjust and cater for the changes?
—
Prioritise offboarding over all else.
The person who is departing might be in the middle of a key project, or days away from finishing a complex new feature. It doesn’t matter. To not immediately turn to your offboarding plan will only result in huge pain and potential loss of revenue further down the line.
Depending on your relationships you may choose to tell clients and share the impact the change will have on the current plans. It may slow progress or mean the heartbeat of their projects will change. Warn early. Be transparent wherever possible.
—
Document your offboarding plan and review it often.
Offboarding isn’t a one-off. Depending on your business and plans for growth you’ll likely be offboarding at least once a year. The plan you create will be a great foundation for next time.
Use the plan as a way to minimise ongoing knowledge and relationship silos. Discuss it with all team members. Ask how they could simplify each section of the plan.
—
People move on for a variety of reasons. Don’t assume that not planning or talking about it will make it less likely.