Moving developer teams in the middle of the project ๐จ๐ฝโ๐ป
๐ LESSON OF THE WEEK
How to move to a new development team in the middle of a project ๐จ๐ฝโ๐ป
A tech and development team is crucial when building a digital project from scratch. It is extremely important to find (or assemble a team of) the right people in order to realize your vision. After all, many of you are in industries where there are many alternatives (think of how many apps came along after Uber ๐). Tech products competing with one another are often differentiated by their quality.
So, it stands to reason that switching to a new development team smack bang ๐ฅ in the middle of a project is a bad idea...
But sometimes drastic times call for drastic measures! Especially when the quality of your product can determine the speed of customer uptake. No one wants to hear that the product failed to meet expectations because it was built by the wrong people.
This year, I spent nearly all of my time designing and building Mane Hook-Up, so I've become well-versed (unwillingly) in switching development teams. I made this decision during the rebuild and it was both painful and stressful. It was also necessary and ultimately the best decision I made. It was much worse to think about switching teams than to actually go through the process of switching. The main reasons were my fear and apprehension about any more delays. But, it was actually a relief as the new development team was much more considerate and had higher standards for delivery (more on that later).
My main goal is to make sure other Founders donโt make the same mistakes I did. It took me far longer than it should have to get out of a situation that didn't serve me or my product. So, this is for either those looking for a development team or those struggling with their current team and in need of some help taking the plunge and finding a better option.
LESSON 1๏ธโฃ: Acknowledge the red flags and decide itโs time to move on ๐ฉ: When youโre building a high-performance tech product, thereโs no time to ignore red flags. However, when budgets are tight and youโre feeling the pressure of being a one-person team, it's easy to overlook these things.
Trust me, Iโve been there. It took me the best part of six months (yes, six whole months ๐ ) to accept that this project wouldnโt work with the development team that I had roped in. And, to add insult to injury, there were a number of red flags in the first month of our collaboration. Still, I soldiered on, determined that my knowledge and many strong words with the account manager would get me to the other side.
Oh, how wrong I wasโฆ
As the red flags started to stack up, I was forced to recognize that I needed to find another team. Itโs impossible to list everything that happened (because no one has that much time), but here are just a few things I encountered, that you should be wary of:
The first iteration was a complete mess ๐ฉ: The developers promised to share an initial version of Mane Hook-Up about 4x weeks after the kick-off. However, I had to persistently pursue this. In the end, when I received the test link, it was a complete mess. Iโm talking Frankensteinโs monster meets Freddie Kruger, and I left no stone unturned when lighting a fire underneath the entire team. The fact that they were happy to share this work with me was the biggest red flag. People who care and take pride in their work don't want to share something of poor quality with a new client, and they certainly don't want to overpromise and underdeliver.
Deadline commitments were constantly missed and costs raised ๐ฉ: This team was not good at forecasting timelines ๐ถ. Despite having received the work and having time to analyse it, with each extension came a new volume of "unexpected" work. A project that was quoted at 3x months in length, became almost three times as long.
Poor communication ๐ฉ: I understand that working with people across time zones means responses can take hours. If thereโs a 5โ8-hour window of overlap, Iโll use that for catching up and sharing updates. With this particular team, I would hear nothing for days. It was frustrating and slowed down everything. I complained several times, but they would go back to old habits only after a couple of days. ๐คท๐พโโ๏ธ
They evidently had no testing process ๐ฉ: Each time I sent a bug list, new bugs were found and many of the problems remained unsolved. It was apparent that, despite documenting everything in Excel and Google docs, there was a lack of care and attention to detail when making changes. Bugs are normal and unavoidable. However, in this case, I had to work overtime to compensate for their lack of due diligence.
And the straw that broke the camel's back ๐ซ, they held my site hostage ๐ฉ: When the website was finally deployed to my server, I needed some time to complete the last bug check. Originally, I was supposed to pay once I reviewed the entire site, but the dev team took matters into their own hands. Two days after deployment, the developers jumped back in and removed it, asking for immediate payment. Considering we were eight months deep into a project that they should have delivered in three, you can imagine this didnโt go down well.
Even while going through all of these frustrations, fear was the main reason that I struggled to move on. I was already time-poor, which made the idea of moving to a new team nerve-wracking: I was afraid it would cause more confusion, prolong the project, or create technical problems. But what it ultimately boiled down to was delivery. There was no way I could trust the initial team of developers to deliver the quality (or respect) necessary to make my vision a reality, and that was far scarier than moving to another team.
Itโs important to remember that while development projects come with challenges, they shouldnโt cause anxiety or stress. Your work environment has a direct impact on how you feel. You should set a very clear boundary that determines when youโre willing to move on. And if you reach it, take the leap.
Key takeaway: Fear can cause more harm than good, especially when making decisions that have a long-term impact. When your digital product is the core of your service, you have to be willing to take calculated risks. Ignoring red flags for fear of what might be, isntโ helpful, itโs hurtful.
FYI: Steps 2, 3 and 4 will go a long way to prevent you from choosing the wrong development team to begin with!
LESSON 2๏ธโฃ: Understand what you need from the new dev team: Like a bad relationship, after youโve experienced everything that you donโt want ๐ , itโs time to get a view of what you really need to be set up for success.
Knowing what you need is the most important thing. In the beginning, I took this for granted and it led to me working with the wrong people. Even though working with the first team of developers wasn't exactly a breeze, I take full responsibility for my decision to work with them. My mistake was focussing on finding someone who had created similar platforms (e.g. they had created a booking system of sorts) that I neglected to consider other things like solid communication and transparency. Having a negative experience like this is frustrating in the moment, but it also allows you to use hindsight to do better. Imagine all of the areas of the project you wish had been smoother or more effective. This will help you understand what you need from a new team of developers.
If youโre not sure what to take into consideration when speaking to dev teams, here are a few questions worth asking:
How transparent and honest are they being? ๐ค โ great developers are ambitious but brutally honest. When you receive quotes and proposals for your project, you can determine who has fair expectations and filter out those who are selling pipe dreams. One of the most important things you need is trust, and that stems from how honest and upfront they are.
Do they care about building a long-term relationship? ๐ค๐ฟ โ The majority of development teams are concerned about building a solid relationship with business owners and founders. This alone indicates that they care about the quality of the work they deliver.
Are they asking enough questions? ๐๐พโโ๏ธ โ no matter how skilled your development team may be, nobody can look at your designs and know how they function. To understand what theyโve signed up for, they have to ask a lot of questions. The answers to those questions will also help them determine the timeline and cost for the project accurately.
Do the costs add up? ๐ฐ โ finding an offshore dev team often allows you to save some money, but the costs should still be reasonable. If it looks and sounds like the offer is too good to be true, they may be underestimating how much work it requires. Or, they could be trying to suck you in with a good deal and might rack the costs up when itโs too late to back out. Either way, itโs not a good look!
Key takeaway: Take your time and speak to several developers to understand what the average costs and timelines are for a project like yours. You won't be able to improve the quality of your team if you rush with this process. So give yourself the time and space to get a lay for the land before moving onto the next stage: shortlisting.
LESSON 3๏ธโฃ: Do your due diligence when shortlisting teams: So, youโve shortlisted a couple of teams (great work ๐๐พ). Now itโs time to do your due diligence by asking all the right questions. A good way to find out how well a development team works is to speak to some of their clients. In this case, you should speak to clients who have products that are similar to yours (e.g. eCommerce sites or SaaS platforms) since you can ask specific technical questions to evaluate their skill set.
How easy/difficult was it to communicate with the team? โ this will give you an idea of how efficiently they work across time zones, how quickly (or slowly) they respond to messages, and whether constructive feedback is well-received.
How would you rate the quality of their work? / Would you hire them again? โ The answer to this question will definitely tell you who you should and should not want to work with. If they wouldnโt hire them again, its a big โ.
What was the post-launch support like? / How long was the contingency window? โ Rebuilds and launches are prone to teething issues, so it's always a good idea to know how reliable a development team is when it comes to resolving bugs and other technical errors. Plus, you need to know how long the support window is open immediately after the release. Iโd say 15-30 days is a pretty fair window.
Did you get a fixed price for the project? / Were they honest about their fees? โ Usually, fixed-price projects will work in your favour since the development team will be responsible for overrunning or underestimating how long a project will take. If the client youโre speaking to was charged an hourly rate, itโs definitely worth asking if they believe the team was honest and transparent about the hours spent on the project.
If, for whatever reason, a team wonโt allow you to speak to their clients directly, thatโs a huge ๐ฉ. Thereโs no reason that at least one of their old clients wouldnโt advocate for them unless the experience was pretty bad. You should speak with at least two of their clients, since this will give you a better idea of how each team typically performs, bringing you closer to a decision.
And, if youโre still torn, here are some other things you can do:
Look for them on freelance sites like Upwork to check reviews โญ โ websites that help dev teams to find new business often feature reviews. Upwork is usually the best bet!
Contact a client listed on their website ๐ฑโ๐ป โ even if a team isnโt willing to give you their client details, you can always contact them off your own back. LinkedIn or the Contact Us page of a company website are the best places to start.
Check company review platforms like Glassdoor ๐๏ธ โ I found my first dev teams company on Glassdoor and (surprise, surprise) they had a tonne of poor reviews. Many employees complained that they took on more projects than the team could handle. Had I taken the time to read these reviews beforehand, I would definitely have dodged a bullet.
To sum up, you can get insights into how dev teams work from multiple sources before you sign the dotted line and hand a project over.
Key takeaway: People are often great at selling the best version of themselves, while covering up their worst work. What you really want to know is what other people think of them, so doing some online stalking and speaking to a few of their clients is worthwhile. Doing your due diligence now will save a lot of time further down the line and can help you avoid technical mayhem.
LESSON 4๏ธโฃ: Get a second opinion from someone more experienced: This one is for all of the non-technical founders out there. If youโre looking for a dev team and have no way to test their technical knowledge, speak to someone who can cover your blind spots. Whether theyโre your friend or an ex-colleague, make sure they join you on the calls with the dev teams so they can be grilled by a technical lead who knows their stuff. This will ultimately stop anyone from pulling the wool over your eyes and provide you with a sense of security.
Youโll have the confidence you need to make the right decision if you gain inputs from someone with technical knowledge
Key takeaway: Itโs impossible to do everything yourself, especially as a non-technical founder building a tech product. Donโt be afraid to reach out and ask the people in your network for help when making really important decisions.
LESSON 5๏ธโฃ: Lay the foundations for a smooth transition: Youโve acknowledged the problem, began your search for a new dev team and found a much better matchโฆ now itโs time to shift the project over to your dream team.
You want to achieve three things: 1) set your new dev team up for success by giving them an insight into whatโs been done, 2) protect yourself by making sure you have ownership of your code and 3) close the project in a way that is unlikely to create drama and headache. And hereโs how you can accomplish all that:
Ask your current team to upload the existing code into a GitHub repo ๐จ๐ฝโ๐ป: This ensures that you have a copy of the existing code and protects you from losing any work. Additionally, you can get the new dev team to review the code before the switch to make sure everything is in order. You should also include documentation in there; your new team will appreciate it.
Tell your current team that the project will be cut short โ๏ธ: it's unlikely that this will end well without an explanation. It's a great chance to air any grievances you may have if the problems werenโt clear. You donโt need to give them a grilling at this stage (theyโre already losing a customer), you just need to provide a satisfactory reason for cutting ties.
Give them a deadline to wrap existing work up โฐ: You should give your current team a week to complete existing work before your new team takes over.
Clarify what youโre paying for ๐ฐ: This could be problematic if youโve been working on a project with a fixed price. You should have a breakdown of the costs for each phase or set of deliverables. Use that as a guide to agree on what the current development team has achieved and what youโll be paying for.
Get your new development team to review everything before giving the final sign off ๐: Now is the time to ask your new development team to quality control what the old team has delivered. While you may not want to ask the old team to spend more time fixing things, it gives your new team a clear view of the work that needs to be done.
Delete their credentials from your account and change passwords โ: Finally, secure your site by removing the old development teamโs credentials and changing any passwords that they had access to.
Wrapping up a project before itโs been completed can feel a bit uncomfortable. If thereโs friction or the old team drags their heels, prepare to walk away regardless of whether they've resolved the loose ends. As long as the bulk of your work is in your Github repo, the rest is history. You have what you need: peace of mind and freedom.
Key takeaway: This stage is not about giving your old dev team a grilling; itโs about getting what you need from the process and ending the project as amicably as possible. Channel your energy into providing your new dev team with as much information and insight as possible. Focus on setting the new team up for success and the rest will follow.
๐งย Was this email forwarded to you? Sign up below to get the next one sent to you.
๐งฐ FOUNDERS TOOLBOX
Landing pages made easy with Convertkit
Convert Kit is a really simple landing page builder that can help you to build email lists and automations with ease. If youโre producing downloadable content and want to drop leads into automation, this is for you. Iโve used a few landing page tools and Convert Kit is one of the few that you can use for free and the paid plans start from as little as $9 a month (for up to 300 subscribers). Great value for money and it delivers.
Help Becoming a Founder to grow by sharing it with a fellow founder or friendย ๐ฅ ๐ฅ
๐คย TWEET TIPS
Coming up next timeโฆ
And thatโs a wrap for this week. Here are some of the things that are coming up next!
Building a team that delivers
Forming partnerships with like-minded brands ๐ค๐พ
Overcoming system overload
Creating the story before you start fundraising