Carlos Ramirez III
Carlos is a professional software engineer specializing in the Ruby on Rails framework. He has worked with US tech companies for years.
Expertise
Experience
15 years
Many product owners don’t have a technical background and thus often find themselves unprepared and scrambling when it comes to bringing on a new development team. This often results in hindered progress, wasted time, and frustration for everyone involved. If this sounds like it could be you, either now or in the future, then you should be somewhat concerned.
In this blog post, Toptal Freelance Software Engineer Carlos Ramirez III will walk you through the various steps of a typical transition process in project management so you can prepare for this eventuality and make the transition as smooth as possible.
Many product owners don’t have a technical background and thus often find themselves unprepared and scrambling when it comes to bringing on a new development team. This often results in hindered progress, wasted time, and frustration for everyone involved. If this sounds like it could be you, either now or in the future, then you should be somewhat concerned.
In this blog post, Toptal Freelance Software Engineer Carlos Ramirez III will walk you through the various steps of a typical transition process in project management so you can prepare for this eventuality and make the transition as smooth as possible.
Carlos is a professional software engineer specializing in the Ruby on Rails framework. He has worked with US tech companies for years.
15 years
It is common for a software product to transition from one development team to another during its lifetime. Different stages of the product may call for a different type of development team: a consultancy to build the initial version, a solo freelance developer to maintain it, an in-house team to bring it to scale, or a professional designer to add some “pop”.
Despite how often this occurs, many non-technical founders and product owners find themselves unprepared and scrambling when the time comes to bring on the next team. This often results in an inability for the new team to make fast progress, wasted time, and frustration for everyone involved.
If this sounds like it could be you, either now or in the future, then you should be somewhat concerned. Luckily, we are going to walk through the steps you can take to prepare for this eventuality and make the transition as smooth as possible.
In this article, I will provide you with a checklist of items that will help you prepare for such a change. You will be getting to know your product on a more intimate level and gaining more control over all the various services and technologies that go into making it, which will empower you to onboard a new team with confidence and relative ease.
But what if you’re not replacing the whole team? Should you bother reading this?
Even if some of the previous team remains on board, they might not have all the answers and information needed for a smooth transition. Although they can provide continuity and aid in the process of transferring knowledge from the old team to the new, relying on incumbent team members is no substitute for the product owner taking charge and facilitating the transfer. In addition, failing to take charge might cause friction between old and new team members, or burden old team members with unnecessary tasks, forcing them to waste too much time communicating with new team members and resolving various issues.
Still, if some team members are staying on board, they can be an invaluable asset in your transition efforts. Consult with them, keep them in the loop and try to leverage their experience without inundating them with too many transition-related tasks. Do not expect them to do all the heavy lifting! That’s your job.
So without further ado, let’s dive in!
Freelance developers are often asked to jump into an existing codebase that they’ve never seen before. This is especially true regarding Toptal software engineers. Our goal is always to get up to speed as quickly as possible so we can start having a positive impact for our clients.
Having access to clear, thorough documentation about the project can dramatically accelerate the onboarding process, and help developers avoid pitfalls that can impede forward progress.
Good documentation needs to cover at least the following topics:
Documentation should be written by a developer who has first-hand experience setting up the application and contributing to the codebase.
Before any transition occurs, request that the previous development team facilitates the transfer of knowledge by creating a resource that touches on the topics above!
If writing is not their strong suit, ask them to record one or more screencasts demonstrating the development environment setup, deployment, etc. Today there are even tools such as Vagrant and Docker which allow whole development environments to be packaged up and distributed to others. In essence, instead of giving someone directions on how to build a hammer, give them the hammer itself.
The litmus test for how comprehensive and effective a project’s documentation is is how quickly a new developer can get his or her development environment setup and running your application.
Having great documentation does not excuse you from needing to know the basics of your own product’s technology. As the owner of a software product, it is your responsibility to understand your application as best you can, even if you aren’t very technical.
The following questions are common, and you should be expected to know the answers without having to look them up:
Today’s software development process utilizes a plethora of third-party services and tools. Whether you know it or not, your application is no exception.
During the course of development, your previous team may have signed up on your behalf, or even used their own accounts to get access to the services that were needed. Transitioning to a new team means that you must take ownership and be in control of every single one of the services and tools that your application relies on so that you can grant access to your new team without needing to go through a middleman or chase down the original developers.
The following is a list of the various external tools or services that your application might make use of:
Ask your outgoing development team which ones are applicable. For any services which are owned by the development team, ask them to transfer ownership to you. If that’s not possible, then ask them to help you create a new account of your own and ensure that the application uses your account instead of theirs. This should not require anything more than changing some configuration settings for your application.
Needless to say, make sure that every development contract protects your interests from day one and assures a smooth transition, no matter what.
With a solid understanding of the ecosystem of your application and ownership over all the various tools and services your application uses, you are now able to provide full access to the incoming team or individual.
Most services will allow you to add a collaborator to your account and grant them a particular level of access. It’s okay to be conservative here. many founders, especially solo entrepreneurs, prefer to give their developers full administrator access to their services and have them handle everything. This has the negative side-effect of keeping you out of the loop, which as we’ve learned, can make it harder to transition in the future.
Should you give your developers full administrator privileges? It’s your call, and most people don’t have a problem with this approach. However, you always need to plan ahead and make sure your decision does not negatively affect a new development team. Failing to do so in the early stages of the project can have annoying consequences in the future.
Now that you’ve got all your bases covered, you’ll need to manage the handoff from one team to the next. Here are some basic tips for dealing with both the incoming and the outgoing team.
Any transition in life can be scary, bringing the uncertainty of whether or not it will work out, fear of the unknown, and so on. Transitioning to a new development team is no different, but you can and should take steps to make it easier. In most cases, it just requires a bit of long-term planning.
Having a greater technical and non-technical understanding of your software product, the development process, and all the things that went into the process will help make any transition from one team to the next as seamless and painless as possible.
Best of all, your new team will respect and thank you for being on top of your game! You are likely to save them time and effort, which also means you will save money. In addition, the sooner the new team realizes insist on high professional standards, the better. Chances are they will continue implementing these practices once they take over the project, making the next transition smooth as well.
So let’s review the key points that should precede any transfer of ownership of your software product:
Located in San Rafael, CA, United States
Member since December 6, 2014
Carlos is a professional software engineer specializing in the Ruby on Rails framework. He has worked with US tech companies for years.
15 years
World-class articles, delivered weekly.
World-class articles, delivered weekly.
Join the Toptal® community.