There are many reasons a startup might need to onboard new software developers. Maybe the current team consists of a part-time freelancer, and the time has come to hire a full-time employee in-house. Maybe the current product was developed by a local agency, but the product is in need of updates.
Whatever the reason, onboarding new software developers is often a daunting task. It can be especially daunting if you don't have in-house developers or a CTO. The best case scenario is you lose some time because you have to get your new devs up to speed. The worst case scenario could result in production outages because an unfamiliar dev broke something.
If you find yourself having to onboard software developers, this guide can help you be prepared for the transition. Whether you're an experienced software engineer or a founder with limited technical knowledge, we think this article can help you.
Before You Onboard New Software Developers
If you have an existing team that you are transitioning away from, then your very first step of onboarding is to offboard your current team! And when we say offboard, we don't mean ghost your current team and revoke their access to all your systems. The best way to transition between teams is to maintain contact with your current team all the way up to when you fully onboard your new software development team. Let the current team know your planned timeline so they can work with you to ensure a smooth transition. This applies whether or not you are fully replacing your current team.
Document, Document, Document
The most important step in onboarding new software developers is to make sure your current team documents everything. The process can be daunting if you're unfamiliar with the specific technologies, so we'll provide a helpful checklist. Keep in mind, this is only a basic checklist. It does not include all the specific documentation you might need for different technologies.
DNS Info
DNS, or Domain Name System, is how your internet browser knows that google.com goes to the Google homepage, and mail.google.com goes to Gmail. It matches your domains and subdomains to the IP addresses for your servers. You should have your current team document DNS settings, and provide the DNS login info to the new software developers if you need them to make changes to DNS.
Hosting Info
Hosting refers to the service provider that actually sells you server space on their servers for you to use for your service or website. Nowadays it's unlikely that your current team is using their own physical servers, so most likely your hosting provider will be AWS, Google Cloud Platform, Azure, etc. It's crucial to get this information from your current team if you don't already have it.
But wait, what if your product is an iOS app and not a website or web app? Do you still have a hosting provider? Mobile apps often still use hosting to store files, images, or videos. For example, if you have an app that allows users to upload photos for other users to view, it's extremely likely that your product is hosting these images on a cloud server.
Code Repository
The code repository is the actual place the code for your product is stored. Hopefully the code repository isn't just located on your developer's computer, but rather in a cloud repository like GitHub or Bitbucket. Make sure you have ownership of the code repository so you are able to transfer the code to your new software developers later. GitHub and Bitbucket also provide version control, which can be helpful to your new software developers if there are existing bugs that need to be tracked down.
Server Setup
You'll want your developers to document the process of deploying code to the server, running the code, and any manual post-deployment steps that must be taken. The process of deploying code to each environment (development, staging, production, etc.) is generally different, and requires a sequence of steps that must be followed carefully.
Documenting this process will greatly reduce the time it takes to get your new team onboarded and mitigate the chance of something going wrong. If the deployment involves any CI/CD (Continuous Integration/Continuous Delivery) processes or automated test suites, then your new development team will need to be aware of these.
Third Party APIs/Services
Many software projects rely on at least one third party API or service. If your software uses a third party service, it's a good idea to document exactly what the service is used for and what versions your software is guaranteed to work for. For example, if your current developers use an older version of a third party library, your new developers will need to know whether or not they can update to a newer version or if your project is dependent on that particular version.
Making the Switch
Managing the relationship between two teams of developers can be tricky during the transition phase. The best way to ensure a smooth transition is to ensure you own all the accounts, code repositories, and servers. If you have full ownership of the project, then you don't have to ask your current developers to transfer anything to the new developers . You can also control when you remove your old development team from the project.
Make sure there's some overlapping time between your current development team and your new team. If you can retain your current team for even just a week, it can go a long way in ensuring your new development team is able to get up to speed. This way, your new team can ask questions in case the documentation wasn't thorough enough for every part of the project.
Again, if you are replacing your current development team completely, don't alienate them. You gain nothing from endangering your relationship with your team. You want to be on good terms with them so you can have an open line of communication.
That said, the number one way to ruin your relationship with your previous development team is by contacting them too much and after your agreed support period. No one wants to bugged for work they aren't being paid for, especially when you've replaced them with another team.
Do what you can while you have them, then work with your new team to resolve any further issues. Keep in mind that some bugs aren't discovered at first. So, if you find a bug weeks later that was caused by your old team, don't expect them to help.
Onboarding new software developers can be quite a daunting task with many potential risks. We hope that you are able to have a smooth transition by following our brief guide. Make sure to perform the pre-transition checklist before onboarding your new team, and you'll already be mitigating many possible issues. If you have any questions about the process or need advice on onboarding new software developers, contact us at [email protected].
(Cover Photo by Christina Morillo from Pexels)
