How to transition from one vendor to another
Breaking up is hard to do — even with your software development vendor. Your current team might not be cutting it, but they still control your code, and your new team, no matter how eager they are, can’t jump in and take the reins literally overnight. No matter what prompted you to move on, like low-quality deliverables, cost overruns, or lack of interpersonal chemistry, you still have one thing you need to tend to, above all else: your product.
Vention has been in the software development business since 2002, and in that time, we’ve seen a few things when it comes to vendor transitions. We’ve seen the changeover go as smooth as silk, resulting in better performance and culture improvements, and heard of others that were trainwrecks, with delayed or even failed delivery of business-critical features and products.
Sure, vendor transitions are rife with technical challenges like figuring out access to systems and servers, getting your head around the existing codebase, and making excruciating decisions about whether to scrap existing code or fix it, but ultimately it’s more a people management challenge. All of it, from knowledge transfer and documentation to protecting your code, depends on how you guide and treat people on both teams.
Consider switching vendors? Give us a shout.
We’ve helped dozens of companies change teams quickly and efficiently. We can help yours, too.
Learn your lessons
The majority of software projects fail not because of technical or engineering issues, but because of poor communication, software development processes, morale, or budgeting (a.k.a. not spending money on expert devs). Take responsibility for ending the partnership rather than blaming your remote development team and assess where and how things went off the rails.
As is the case in any other part of life, figuring out what went wrong often demands taking a hard look in the mirror and recognizing that you simply didn’t have the time or inclination (or both) to support and listen to your developers, or maybe there were personality conflicts that could have been handled better, or maybe you missed the mark when it came to communicating your expectations or feedback. Then ask yourself, "How can I do better going forward? How can I be better?"
Any software development project is a two-way street. Think of any engagement that way and you’ll head off problems and derive far more value from your investment.
Don’t expect too much
If you think the team you’re breaking up with will happily stay for another few months of knowledge transfer sessions and assessments together with its replacement, don’t kid yourself: It won’t.
“Developers hate creating documentation,” says Dave Hecker, Vention West Coast CTO, who has had 25 years of experience orchestrating vendor transitions. “One in a hundred will thoroughly describe system architecture, technical debts, and use cases, so don’t expect the outgoing team to be overly enthusiastic about writing documentation for its successor.”
To avoid additional disruptions during the vendor transition process, ensure that your team documents new or changed process/product knowledge along the way. Appointing internal ‘knowledge owners’ for specific subject matters, from the very start of the engagement, and auditing the quality of documentation on a regular basis can do the trick.
Don’t second guess yourself
Always remember that if you’re not happy with your team, it’s probably not happy with you, either. Just as with personal relationships, it’s rare that one person initiates the split and the other is blindsided. If your team requires too much micromanagement, slacks off often, and does only the bare minimum, it’s an obvious sign of a disconnect in a professional relationship.
Remind yourself that ending the contract is the best course for everyone involved — and your vendor likely knows that, too. They’re not going to sabotage your code or boil your bunny. It’s more a question of money: If you pay good money for the knowledge transfer, it’ll be fine.
At the same time, if you’re hesitant about giving the new vendor full permissions in your systems right off the bat, consider implementing least privilege access so you restrict user access to only those assets required to do the job, reducing the overall risk or impact of cybersecurity attacks.
Be amicable
Let’s say your new vendor will take over the project in ten days. Your app is basically down until then, so you need your ex-engineers more than they need you, at least at the moment. The solution? Give them love.
Instead of saying, “I’m concerned that you might steal my code. I’ll lock you out,” send them a gift (an Xbox would work perfectly) — even if you’re angry at them. This is an excellent opportunity to end the partnership nicely, especially since you might need the team to handle issues and questions from your new software development vendor. (Practicing generosity might make you feel better, too.)
Trust your new team to handle the details
We get it: Your previous partnership has failed, and you’re probably not ready to trust your new development team — even if you have to. Keep in mind that your confidence in your new engineers is proportional to the chances of your software project’s success. Letting them drive the transition strategy will go a long way toward establishing a culture of trust and transparency, which will head off costly disruptions down the road.
Also, communicate all of the why’s behind high-level transition decisions, like establishing certain KPIs or incorporating specific functionalities into the new product roadmap, to the incoming team: This boosts your team’s morale and engagement, which, in turn, yields greater productivity and higher profits. Remember that they’re going through an onboarding process, which can be stressful enough, and your support always matters.
Resist the temptation to be a control freak. Maybe start by giving your development team some reasonable autonomy (for example, ask them to review the current tech stack). In half the cases, newcomers will be shocked over how “awful” the code is and might suggest rewriting the whole app (to be fair, that is necessary sometimes) — just let them voice their opinion and treat it as objectively as possible.
Your new software development team — not you — should lead the project transition. Otherwise, you risk getting distracted from core value-added activities like raising funds or managing go-to-market strategies (just the kind of distractions that can lead to startup failure).
“Push the new developers to go through the knowledge transfer quickly. It should never take months — a seven-day discovery is usually enough,” says Dave. “Try splitting up the team so that each dev is responsible for a different application portion. One engineer can dig into the code base, while others can take over the documentation, UI, or DevOps. This way, it won't be long until they fill all skill and experience gaps.”
