Moving developer teams in the middle of the project 👨🏽‍💻

Sep 28, 2021

📔 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 🔥 🔥

Share Becoming a Founder