If you are a business owner looking to save money and get your project back on track by replacing your engineering team or outstaffing with a new team, don’t miss these five key steps for a more seamless and less anxiety ridden transition.
As the CEO of a software development agency in San Francisco, I have been responsible for providing outstaffing solutions for multiple companies looking to replace or augment their engineering teams with dedicated software developers. As such, I’ve seen my share of projects in different states of transition and have witnessed first-hand how switching to a fresh and more passionate group of new engineers can make a huge (and profitable) difference for businesses whose projects have stalled or who need immediate engineering or design help.
For example, one SaaS client we work with decided to shift operations from an in-house engineering team to our outstaffed agency, and within months, we were able to cut their development costs by 20 percent as well as dramatically improve their web application’s performance and user experience. At the same time, we optimized their hosting and server costs which their previous team had neglected, and they saved almost $100k in the first year.
If you have slowly come to the realization that you need to replace your engineers or transition from an in-house team to an outstaffed one, don’t miss this essential step-by-step guide to protecting your product, successfully transferring knowledge, keeping the peace to avoid any unwanted fallout or ill will, and avoiding losing as much time and money as possible.
Step 1: Establish Admin Access to ALL Accounts
As the company or product owner, you should ALWAYS maintain the highest level admin access and primary contact info on all your accounts be it cloud services, hosting, project management platforms, code repo’s, domains, you name it. You should be the one to invite your engineers to the tools and apps the team uses, not the other way around.
If you lack the expertise you need to manage accounts for the more technical programs, first sign up with your email address, and then share your login so your tech team can create sub-accounts; once they have, change your master password and regain control of your account. If any of the existing accounts are already under your developers’ credentials, send out a company-wide request to transfer administrator privileges to a master login that you manage.
Not only will this give you more control over your project, accounts, and environments, but it prevents a disgruntled engineer from holding your assets hostage and makes it easier for you to cut them off if needed. This is a first step to locking down all accounts and access and is a must first step.
Step 2: Collect Essential Documentation
A seasoned engineering team that is stepping in to take over will most likely want to review any documentation before conducting a review of all the project’s code to date. You may not know what project documentation does or does not exist, and in some cases, your outgoing engineering team will be your sole resource for aggregating all of it. This quick checklist can help:
Pro Tip: Establish a documentation routine (or have a business analyst set one up) in which engineers aggregate and save as much of this documentation and information as possible within the first month of finishing a project (or even better as they are going along, even though this is much tougher). Keep it organized and stored in a repository like Confluence (an Atlassian product) or even Google Docs (but, make sure you are the owner) so you have it at your fingertips when you onboard new team members.
Step 3: Facilitate Knowledge Transfer Between Teams
Step 4: Allow the New Team to Conduct a Code Review
As Linux creator, Linus Torvalds, once said, “Talk is cheap. Show me the code.” A sweeping code review will help your new engineering team familiarize themselves with your product’s codebase as well as gather insight into its structure, consistency, and bugginess. If you are a non-technical person, it can also help you gain an understanding of how well your code was written. Unlike a code review between programmers that is routinely done to validate a chunk of code prior to testing, this type of code review will serve more as an audit of your entire product, where engineers take a look under the hood and see what work needs to be done.
Depending on the thoroughness of the documentation, your new team will most likely appreciate someone who can walk them through the code, both the back-end and front-end, and explain why certain choices were made, whether it’s regarding the flow, style, architecture, etc.
Step 5: Protect Your Company
Remember, your current engineers hold the proverbial “keys to the kingdom,” and they play an important role in helping your project successfully transition to new developers. Don’t mislead or anger them before you gather all the documentation and materials you need to soften the ground for a new tech team. It is critical that you do not burn the bridge while you are standing in the middle of it.
And don’t be surprised if the group of engineers you are letting go is not happy about their departure or the idea of helping educate their replacements. A disgruntled team might not have your project’s best interests at heart, so it is necessary to protect yourself and your intellectual property. From the start, you want to make sure that you have non-disclosure agreements (NDA) in place to make proprietary information and company trade secrets confidential. If you do not have existing NDA’s in place, try and get them signed retroactively.
Moving Past Failure
It’s important to note that a handful of factors may be at play when a project fails. Sometimes engineers simply don’t have the technical competency a project requires or they don’t feel a sense of ownership and commitment to the product. Other times, trust issues between developers and major stakeholders or a lack of process can be the straw that breaks the camel’s back. Even when it’s clear that things aren’t working, it can still feel overwhelming to think about looking for a new team and making the transition.
In my company’s experience with handling these types of delicate situations for clients, we have found that starting with a game plan that protects your business and goals is the best place to start. In truth, bringing on a new engineering team may be your answer to not just moving past a project failure but improving your business as a whole. In addition to auditing code, fixing vulnerabilities, and even refactoring or completely rewriting legacy products, a new team may offer help in the areas of creating proper deployment protocols, updating business requirements, and assembling documentation. Even small advancements across these areas can have a big impact not just on your product but on your company culture and overall team morale.
