Help - my developer is running away!
Are about to lose an important developer? This paper provides guidance on how to perform a technical handover. This will ensure that your soon-to-leave developer will impart his or her valuable technical knowledge, and it will help you avoid the common traps and pitfalls that their departure can cause.
It is important to perform a technical handover as early as possible - don’t underestimate the time it will take. The transfer of software technical knowledge is a timeconsuming and complex task, so plan ahead, decide what’s important, schedule regular meetings and slowly get your remaining developers to take over the leaving developer’s tasks.
Why is a technical handover important?
The software you have developed is a unique asset. Your prized developer has invested a great deal of expertise and time into the software, and this investment needs to be protected. Without a technical handover, the departure of a critical developer can leave your development team unable to do their work. Implementing new features, bug fixes or maintenance could take significantly more time - and might not even be possible. A technical handover allows your remaining team to get up to speed and minimises disruption to development.
However, organising a good technical handover requires good planning.
Plan ahead to avoid conflict
Have an initial meeting as early as possible with your developers to plan the handover. Decide on a prioritised list of technical aspects that need to be covered in the handover process and how you’re going to carry out the process.
Often, it’s not just about knowledge: a developer will have many valuable contacts. It’s important to make sure these contacts are introduced to the remaining developers.
Make sure everyone learns how to use the developer's code
The leaving developer will have little time to tie up loose ends, so make it a priority to schedule regular and frequent meetings for the remaining developers to meet and absorb the right knowledge.
Catch up every so often
Arrange to meet as a group to discuss progress of the handover on a regular basis and plug any gaps in knowledge.
Determine the assets
What aspects need to be considered during the handover? Don't limit yourself to software. Be sure to include related aspects, like the code repository, website and wiki maintenance, and documentation.
Who gets what?
Decide which developer is best suited to inherit each aspect of your software from the departing developer. You need to question who has the most appropriate skill set. Is it best (and possible, given the time left) for the whole team to learn everything or will you have to subdivide the aspects across different developers?
Avoiding the pitfalls is important as writing the technical handover plan.
Are there any key technologies that your remaining team need to learn about? For example, if your software is developed within a development framework (e.g. Grails, Ruby on Rails, Spring, etc), it will take time to learn the framework as well as the technology it is used to develop.
Don’t just recycle old material
Don't waste your time covering aspects that your remaining team already know, or ones that can be discovered from existing materials (like tutorials, design documents, architectural overviews and the issue tracker).
Ask your departing developer for advice
Use this as an opportunity to extract the best ideas from your prized developer. They will have ideas on what needs to be improved, and how these improvements should be done.
Further information and useful resources
- A pdf of this briefing paper
- The STFC: an excellent synthesis of the topic and the Significant Properties of Software framework
- The Significant Properties of Software project - a JISC-funded study into what properties are needed to allow software to be systematically preserved