How to Switch Dev Teams (Without Losing Your Code)
How to Switch Dev Teams (Without Losing Your Code)
A year ago you decided you needed to create some custom code. It might have been a new startup idea that you had been nursing for months, or perhaps it was a new initiative at your company, but now it is just a mess.
The external dev team you hired is just not cutting it. Missed deadlines, empty promises, bad communication, or just outright jerkiness (or all of the above). Regardless of the reason, all you know now is that you are ready to move on.
The burning question is: How? These are purveyors of black magic. You have no idea what they are doing in their dark caves and bright monitors so how do you fire them? What damage can they do? What do I need to do first?!
*panic*
First…breathe… we are here to help.
Second… wait… don’t fire them quite yet.
That second point is really important because the brutal truth is that your dev team has all of the keys to the castle and if you don’t prepare yourself, you could be in a world of hurt.
For those of you who don’t know me, my team and I build custom software for folks such as yourself. Sometimes this requires us to displace an existing dev team and take over their code. Over the years we have done this many times and have come up with a process to help people just like you through this difficult task.
Step 1: Put your game face on.
If you are to the point where you need to fire your dev team, the first thing you need to do is mentally prepare yourself for the worst. Now, in my experience, this transition process is usually very smooth and non-contentious, but when switching teams it is always best to prepare as though they are going to fight you every step of the way.
Bottom line: If the outgoing team wants to be difficult and you don’t prepare, then they can absolutely own you because they have all the leverage (passwords, code, databases, keys, etc). A little prep can make this much easier.
Step 2: Check your contract
Who owns the IP? Who owns the code? Was it work for hire? All of these should be answered in your contract. If it isn’t specified then you very well could need a lawyer, but lets not get ahead of ourselves. Lets break this down a bit… no law degree required.
Who owns the IP?
The intellectual property is the ownership of the idea itself. If your contract does not specifically state that you, in fact, own the idea, then firing the team could get really ugly because they can make the claim that they own at least part of the idea because they helped you come up with the implementation.
Who owns the code?
Ok, so you own the IP, that means you own the code right? Not necessarily. Often devs will assume that even though they don’t own the idea they own their work (i.e. the code). This means that if you try to fire them they could push back and say that they are taking their “ball” with them… how much is that idea worth now eh?
Was the contract “work for hire”?
This is a fancy way of answering the two questions above. Ideally your contract with them will specify that they are just doing you a service (“work for hire”) and own the code/idea as much as your lawn guy owns the grass he mows.
If your contract with the existing team doesn’t mention these things specifically are you screwed? Probably not. As I mentioned before, most dev teams just wanna write code and make some money. They don’t want to own your idea or put you out of business. Most transitions go smoothly; however, if they do put up a fight, then the best thing you can do is have a frank and honest discussion. They don’t want to hire a lawyer anymore than you do, so just sit down, talk, listen, and you can probably come to an agreeable solution.
Step 3: Get your code
Ok, you have read your contract and know where you stand… what’s next? You need a copy of all of the sorcery they have been building for you.
Before you even mention or threaten firing the current team you need to make sure you have a copy of all of your code and access to your servers.
I cannot stress this enough. Without access to the code and servers you have nothing. This is especially true if the team is overseas. If they decide to just disappear one day in a fit of nerd rage you have very little recourse. Again… a bit of prep work goes a long way.
So… code. All devs worth their salt use something called a repository to save, backup, and version their code. It is probably github, or potentially bitbucket, or something more obscure, but it is somewhere and you need access to it.
Word of warning… if you start asking for access to the code out of the blue the team’s will know something funky is going on. Ideally you should get access to your code at the beginning of the project, but if that isn’t the case (it usually isn’t), just simply state that you have been reading some articles and they recommend that you have a copy of your code in case the team gets hit by a bus or something. It is 100% true (it is a good idea) and completely plausible. It won’t completely allay their fears but it will keep them from pushing any big red buttons.
Once you have access to the code, download it and store it somewhere private. This way if they go nuclear you have a recent version to hand to the new team.
Step 4: Get to your servers
This goes hand in hand with step 3. You probably have a database and a server somewhere and you need access to it. Again, in an ideal world, all of the accounts would be setup and managed by you from the very beginning, but very, very few clients request this so you are in good company.
The database/server probably lives in the cloud… probably in Amazon’s AWS service, Microsoft’s Azure, or something like Heroku (which is a fancy toolkit built on AWS) or Digital Ocean. It is trivial to get added as an admin to these accounts so don’t let the team blow smoke.
Same warning here… just like code access, this will raise some flags. The same explanation as before will work here too. In fact, I would ask for both at the same time and use that bit of elegant wording up there one time rather than twice.
If the database/server lives on a physical server that is managed by the devs for some reason (what year is it again?), then insist on getting a backup of the database at the very least… again for your records. Even if you end up keeping the team, if you are using a physical server, then you should have a copy of the data sent to an offsite location on a daily basis.
Step 5: Find your new dev
Before you let Team One go, you need to find Team Two. How to find a great dev team is a series of articles all by itself (*wink*), but it is always better to have the replacements ready to step in case Team One starts dropping grenades on the servers.
Team Two: Find them, vet them, hire them, give them the copy of the recent code you downloaded, and pay them a few hours to get the lay of the land. These will be some of the best dollars you ever spend. If your new team has seen the code and understands the basics of how it is built, then they can ask the right questions when the time comes and can step in much faster if Team One goes bonkers.
Step 6: Time to fire your dev
Ok… finally… all the prep work is done. You are ready to let Team One know that their services are no longer required. If this has been a long term relationship it is completely understandable if emotions run high. It is also normal behavior for stupid stuff to get said, threats to be made, and a bunch of ugliness to occur during this emotional conversation. If this happens, just stand firm and politely tell them you will talk to them later.
This is important because if you stay in a charged situation and push forward, the odds of them lighting fires on their way out the door goes way up. If you let things simmer down, they will probably realize that this has been a long time coming and might even be relieved a bit that this is happening.
With all of that said… it is also completely expected that Team One is totally cool and not surprised at all. What is funny is that when this happens it is often the client who gets upset… they don’t understand why the dev isn’t more emotional, more engaged. Bottom line is that it doesn’t matter. If the dev is cool then this whole process gets a lot easier.
Step 7: Bring in the big guns
So Team One has successfully gone through all the stages of grief and they are ready to be replaced. In an ideal world you will pay Team One a few hours to bring Team Two up to speed (no, they shouldn’t do this for free). This will save you a good chunk of change. Development, by its very nature, is a cerebral exercise. Devs make countless decisions to build their software and the more they can “download” the method behind the madness to the new team the better it is for you.
I did mention that is an ideal world right? In the real world, the number of times we have taken over a project and the original dev actually enough time to have an easy transition is exactly zero. Usually they talk a good game about transitioning and they will meet for an hour or two, but, most likely, they will lose interest quickly and stop returning emails.
This isn’t the end of the world. Team Two are professionals and will know how to take care of the situation, but you will need to be patient with them.
Moving Forward
Taking over an existing codebase is incredibly difficult and it takes a lot of time. Customer requests are going to be slower for a while, new features will slow down to a crawl, and absolutely none of this means that your new team is incompetent.
It happens to all dev teams too, including us. Over the years we have had a few passive aggressive emails and super aggressive phone calls (Ed Note: Past clients, not our current ones. Our current clients are all wonderful). We assured them with the same sweet words we are telling you now. Taking over someone else’s code takes time and frustration is often part of the package. If you, as the client, can avoid taking it out on your new team, they will greatly appreciate it. Remember, taking the time to do right will be much better for your project than finding Team Three.
So there you have it. Your custom script for how to replace your existing dev team. I, for one, am sorry that this article has to be written, but poor devs are all too common and it is always better to be prepared.
Remember. Just breathe.
How to Switch Dev Teams (Without Losing Your Code)
How to Switch Dev Teams (Without Losing Your Code)
A year ago you decided you needed to create some custom code. It might have been a new startup idea that you had been nursing for months, or perhaps it was a new initiative at your company, but now it is just a mess.
The external dev team you hired is just not cutting it. Missed deadlines, empty promises, bad communication, or just outright jerkiness (or all of the above). Regardless of the reason, all you know now is that you are ready to move on.
The burning question is: How? These are purveyors of black magic. You have no idea what they are doing in their dark caves and bright monitors so how do you fire them? What damage can they do? What do I need to do first?!
*panic*
First…breathe… we are here to help.
Second… wait… don’t fire them quite yet.
That second point is really important because the brutal truth is that your dev team has all of the keys to the castle and if you don’t prepare yourself, you could be in a world of hurt.
For those of you who don’t know me, my team and I build custom software for folks such as yourself. Sometimes this requires us to displace an existing dev team and take over their code. Over the years we have done this many times and have come up with a process to help people just like you through this difficult task.
Step 1: Put your game face on.
If you are to the point where you need to fire your dev team, the first thing you need to do is mentally prepare yourself for the worst. Now, in my experience, this transition process is usually very smooth and non-contentious, but when switching teams it is always best to prepare as though they are going to fight you every step of the way.
Bottom line: If the outgoing team wants to be difficult and you don’t prepare, then they can absolutely own you because they have all the leverage (passwords, code, databases, keys, etc). A little prep can make this much easier.
Step 2: Check your contract
Who owns the IP? Who owns the code? Was it work for hire? All of these should be answered in your contract. If it isn’t specified then you very well could need a lawyer, but lets not get ahead of ourselves. Lets break this down a bit… no law degree required.
Who owns the IP?
The intellectual property is the ownership of the idea itself. If your contract does not specifically state that you, in fact, own the idea, then firing the team could get really ugly because they can make the claim that they own at least part of the idea because they helped you come up with the implementation.
Who owns the code?
Ok, so you own the IP, that means you own the code right? Not necessarily. Often devs will assume that even though they don’t own the idea they own their work (i.e. the code). This means that if you try to fire them they could push back and say that they are taking their “ball” with them… how much is that idea worth now eh?
Was the contract “work for hire”?
This is a fancy way of answering the two questions above. Ideally your contract with them will specify that they are just doing you a service (“work for hire”) and own the code/idea as much as your lawn guy owns the grass he mows.
If your contract with the existing team doesn’t mention these things specifically are you screwed? Probably not. As I mentioned before, most dev teams just wanna write code and make some money. They don’t want to own your idea or put you out of business. Most transitions go smoothly; however, if they do put up a fight, then the best thing you can do is have a frank and honest discussion. They don’t want to hire a lawyer anymore than you do, so just sit down, talk, listen, and you can probably come to an agreeable solution.
Step 3: Get your code
Ok, you have read your contract and know where you stand… what’s next? You need a copy of all of the sorcery they have been building for you.
Before you even mention or threaten firing the current team you need to make sure you have a copy of all of your code and access to your servers.
I cannot stress this enough. Without access to the code and servers you have nothing. This is especially true if the team is overseas. If they decide to just disappear one day in a fit of nerd rage you have very little recourse. Again… a bit of prep work goes a long way.
So… code. All devs worth their salt use something called a repository to save, backup, and version their code. It is probably github, or potentially bitbucket, or something more obscure, but it is somewhere and you need access to it.
Word of warning… if you start asking for access to the code out of the blue the team’s will know something funky is going on. Ideally you should get access to your code at the beginning of the project, but if that isn’t the case (it usually isn’t), just simply state that you have been reading some articles and they recommend that you have a copy of your code in case the team gets hit by a bus or something. It is 100% true (it is a good idea) and completely plausible. It won’t completely allay their fears but it will keep them from pushing any big red buttons.
Once you have access to the code, download it and store it somewhere private. This way if they go nuclear you have a recent version to hand to the new team.
Step 4: Get to your servers
This goes hand in hand with step 3. You probably have a database and a server somewhere and you need access to it. Again, in an ideal world, all of the accounts would be setup and managed by you from the very beginning, but very, very few clients request this so you are in good company.
The database/server probably lives in the cloud… probably in Amazon’s AWS service, Microsoft’s Azure, or something like Heroku (which is a fancy toolkit built on AWS) or Digital Ocean. It is trivial to get added as an admin to these accounts so don’t let the team blow smoke.
Same warning here… just like code access, this will raise some flags. The same explanation as before will work here too. In fact, I would ask for both at the same time and use that bit of elegant wording up there one time rather than twice.
If the database/server lives on a physical server that is managed by the devs for some reason (what year is it again?), then insist on getting a backup of the database at the very least… again for your records. Even if you end up keeping the team, if you are using a physical server, then you should have a copy of the data sent to an offsite location on a daily basis.
Step 5: Find your new dev
Before you let Team One go, you need to find Team Two. How to find a great dev team is a series of articles all by itself (*wink*), but it is always better to have the replacements ready to step in case Team One starts dropping grenades on the servers.
Team Two: Find them, vet them, hire them, give them the copy of the recent code you downloaded, and pay them a few hours to get the lay of the land. These will be some of the best dollars you ever spend. If your new team has seen the code and understands the basics of how it is built, then they can ask the right questions when the time comes and can step in much faster if Team One goes bonkers.
Step 6: Time to fire your dev
Ok… finally… all the prep work is done. You are ready to let Team One know that their services are no longer required. If this has been a long term relationship it is completely understandable if emotions run high. It is also normal behavior for stupid stuff to get said, threats to be made, and a bunch of ugliness to occur during this emotional conversation. If this happens, just stand firm and politely tell them you will talk to them later.
This is important because if you stay in a charged situation and push forward, the odds of them lighting fires on their way out the door goes way up. If you let things simmer down, they will probably realize that this has been a long time coming and might even be relieved a bit that this is happening.
With all of that said… it is also completely expected that Team One is totally cool and not surprised at all. What is funny is that when this happens it is often the client who gets upset… they don’t understand why the dev isn’t more emotional, more engaged. Bottom line is that it doesn’t matter. If the dev is cool then this whole process gets a lot easier.
Step 7: Bring in the big guns
So Team One has successfully gone through all the stages of grief and they are ready to be replaced. In an ideal world you will pay Team One a few hours to bring Team Two up to speed (no, they shouldn’t do this for free). This will save you a good chunk of change. Development, by its very nature, is a cerebral exercise. Devs make countless decisions to build their software and the more they can “download” the method behind the madness to the new team the better it is for you.
I did mention that is an ideal world right? In the real world, the number of times we have taken over a project and the original dev actually enough time to have an easy transition is exactly zero. Usually they talk a good game about transitioning and they will meet for an hour or two, but, most likely, they will lose interest quickly and stop returning emails.
This isn’t the end of the world. Team Two are professionals and will know how to take care of the situation, but you will need to be patient with them.
Moving Forward
Taking over an existing codebase is incredibly difficult and it takes a lot of time. Customer requests are going to be slower for a while, new features will slow down to a crawl, and absolutely none of this means that your new team is incompetent.
It happens to all dev teams too, including us. Over the years we have had a few passive aggressive emails and super aggressive phone calls (Ed Note: Past clients, not our current ones. Our current clients are all wonderful). We assured them with the same sweet words we are telling you now. Taking over someone else’s code takes time and frustration is often part of the package. If you, as the client, can avoid taking it out on your new team, they will greatly appreciate it. Remember, taking the time to do right will be much better for your project than finding Team Three.
So there you have it. Your custom script for how to replace your existing dev team. I, for one, am sorry that this article has to be written, but poor devs are all too common and it is always better to be prepared.
Remember. Just breathe.
Our superpower is custom software development that gets it done.
