Your software developer is quitting: now what?

July 8, 2022

Matraex builds custom software applications for clients – and we often takeover (read “rescue”) projects started by other developers. I wrote this article to help business owners and software founders address an issue that they are often not prepared to address. When a software founder comes up with a software idea – often times they go looking for a developer to help them implement it. When they start the project – they rarely put any thought into how to set the project up so that it is “easier” to handle things when that developer quits one day. Most of the time the founder puts full trust and faith in the developer to set everything up. And now that the developer is leaving, the world seems to be falling apart. We have had dozens of clients looking to restart a project that stalled after their developer left. Often times those projects are disorganized and difficult to reconstruct. In some cases they can not be saved. This article is an attempt to help clients gather the project so that it can be restarted with confidence.

So the truth is out! The developer that knows everything about your project is not going to be around to finish it.

You may have cursed a bit under your breath and tried to quickly maneuver to keep them on board – however, you are reading this article because you now know it is up to you to confirm you have possession of your project. It is up to you to take control of the software so you can direct it and secure the future of it. Here is how you do it.

First of all, don’t freak out, a calm and professional response to the news is the best way to encourage a smooth transfer of all project assets and assistance identifying ‘forgotten’ assets.
Second, create a shared ‘offboarding’ document and / or folder where you can coordinate the process of collecting information about your project.
Request information from your developer – Let them know that the most important part of their offboarding is to help you understand the project – so you can help the next person take it over.
Confirm that you have the information you are looking for – it can be tempting to just assume you have it, but by taking the time to verify it, you will identify things that are missed and save headaches later.

Don’t Freak Out

Why is this a step? Because we have found that some of our past clients needed this reminder. Too often we hear of hasty hire or poorly orchestrated offboarding while the manager spends time realizing that the project was not going to be done the way they had previously assumed. Often, the decision will be made to try to ‘get it all done’ in the next two weeks. They drive the developer to spend every moment of their last two weeks getting writing code. This should not be the first priority! The first priority should be to ensure that the possession of the project is fully in the control of your company and the company can continue development of the project in the future.

One of the reasons that we see managers ‘Freak Out’ at this stage is because they have not previously recognized that they should have set their project up in a way that made sure that the project was already in the possession of the company. Ultimately, any project that was going to be owned by your company had to be in company possession anyway, right? So this is a good thing – we are going through the process of putting your project in your control – so your project will survive this ‘developer change’ and any ‘developer changes’ in the future.

Your systematic and practical approach to offboarding your current developer will result in a strong understanding of your project and an improved ability to select the ideal replacement when you restart your project. The possession you end up with will give you the confidence to restart and finish the project in the future.

Create a shared offboarding folder

Create a shared folder where you can work with your developer over the next days and weeks to collect information about your projects. You will want to create the area yourself and setup the structure to have the information you want.

I use Google Documents because the ability to collaborate is better than any other tool, but what is important is that it works for you and your developer and you are able to see each other’s work. Create several documents and give your developer access so they can make changes where you can see them. I recommend that you create the following documents at a minimum – be sure that each of the folders has permissions which allow your developer to make changes:

Document: Offboarding Checklist / Instructions
Document: Offboard TeamMemberName – MM/DD/YYYY – Projects / Assets / Credentials
Folder: Project Asset Uploads
Folder: Recordings

I have created an example (with some sample entries)

Request the following from your developer:

Fill out the offboarding document with credentials and links to each project and project source
List all code repositories and transfer ownership to me
Provide me with access to your workstation
Record a video of you working through opening, making a simple development change and then deploying
Record a video showing the workstation and development environment and configuration
Record a video explaining for each project what your next steps and recommendations would be

Confirm possession and control of your code

Understand and confirm your understanding of all project assets
Test credentials and confirm owner level access to all project assets
Confirm project source links and documentation, add notes and request updates
Review recordings and request additional recordings.
Time permitting: Request a review / audit of code / transfer confirmation from a third party

Note: The lists above are presented to identify areas that should not be missed – as time permits this article will be expanded to provide detail on each of these. Until the article is expanded please feel free to email michael@matraex.com with questions – I will answer and expanded this article at the same time.